Agile software development steps are usually described as a repeating loop: sprint planning, daily standups, a sprint review, and a retrospective, running continuously against an open backlog. That description is written for an in-house product team with no fixed budget ceiling. A commissioned project still runs through sprints, but the backlog is bounded by what was actually scoped and quoted at the start. This guide covers the loop as it actually runs inside that kind of engagement.
Agile Software Development Steps, Listed
The standard loop: sprint planning through retrospective. The agile software development process steps most guides describe run in a cycle: plan a sprint, build against it, review the working increment, then hold a retrospective before planning the next one. For an in-house team with a continuously groomed backlog, that cycle can run indefinitely, adding and reordering work as priorities shift.
What changes when the backlog has a ceiling? A commissioned project runs the same cycle, but the backlog isn't open-ended. It's bounded by what was scoped and quoted before the first sprint started. That single difference changes how a new idea gets handled, how velocity gets tracked, and what "done" actually means, which is the agile development process most vendor and course content skips entirely, since it's written for a team that owns its own backlog indefinitely.
Agile Doesn't Guarantee Success, It Changes the Odds
The Standish Group's CHAOS research (the 2020 "Beyond Infinity" report) found agile projects succeeding several times more often than waterfall projects, with waterfall carrying a far higher outright failure rate. The exact ratio varies by year and by who is citing it, and the Standish Group's methodology has drawn independent academic criticism, so treat the multiple directionally rather than as a precise figure. What holds up regardless of the exact number: a "challenged" outcome- late, over budget, or reduced in scope- stays the single most common result for agile projects too, especially larger ones.
That's the argument for a bounded backlog specifically. Agile as a process improves the odds of a good outcome. It doesn't remove the risk of a challenged one. What actually protects a commissioned project from that outcome is a backlog that was scoped and quoted before work started, so scope creep has to pass through a change conversation instead of sliding into the next sprint unnoticed.
An open backlog and a bounded one fail in different ways when something goes wrong. An in-house team with a challenged sprint absorbs the cost internally and reprioritizes next week. A commissioned project with the same challenged sprint has a client watching a delivery date and an invoice. That's not a reason to avoid agile for commissioned work; it's a reason the backlog boundary matters more here than it does for a product team building for itself.
The Loop, Step by Step
Sprint planning: choosing the next working increment from a bounded backlog. Sprint planning selects a slice of the agreed scope to build next. In an open backlog, that slice can shift to whatever the team decides is highest priority this week. In a scoped engagement, sprint planning is choosing the order to deliver already-agreed work, not deciding what the work is.
The sprint: building, with automated testing and continuous integration running throughout. During the sprint, automated testing and continuous integration run continuously rather than as a final gate, so a broken build surfaces the same day it happens, not weeks later during a rushed pre-release scramble.
Sprint review: a working increment shown, not a status report. A sprint review demonstrates working software, screens that respond, data that saves, a report that generates, not a slide describing progress. Anyone can describe progress. A working increment is the only proof that a sprint actually delivered something.
Retrospective: adjusting the process itself, not just the backlog. A retrospective looks at how the team worked, communication gaps, a task that took longer than estimated, a review step that got skipped, and adjusts that for the next sprint. It's separate from backlog grooming, which decides what gets built next; a retrospective decides how the team builds it.
What happens when a genuinely new idea shows up mid-project? In an open backlog, a new idea gets added and reprioritized into an upcoming sprint. In a scoped engagement, a genuinely new idea, not a clarification of something already agreed, gets raised as a change conversation: priced, scheduled, and agreed before it enters a sprint. That's not bureaucracy for its own sake. It's what keeps the delivery date the client was quoted from quietly slipping every time a good idea shows up. The distinction that matters here is between a new idea and a clarification: a question that resolves ambiguity in something already scoped belongs in the current sprint, while a feature nobody scoped or quoted belongs in a change conversation, and mixing the two up is usually where a bounded backlog quietly turns back into an open one.
A Continuous In-House Backlog vs. a Scoped, Quoted Engagement, Side by Side
Here's what actually differs between the two.
Backlog
In-house product team: Open-ended, continuously reprioritized
Scoped, quoted engagement: Bounded by what was scoped at the start
A new idea mid-project
In-house product team: Added to the backlog, reprioritized next sprint
Scoped, quoted engagement: Raised as a change conversation, priced and scheduled separately
Velocity tracking
In-house product team: Tracked indefinitely across many sprints
Scoped, quoted engagement: Tracked within the agreed engagement to protect the delivery date
Definition of "done"
In-house product team: Set by the product team alone
Scoped, quoted engagement: Agreed with the client as part of acceptance
Where Burhani Fits
Our application development work runs on a fixed-price-after-discovery basis, or as a dedicated-team model for longer engagements, rather than as an open-ended backlog. "The Stages of a Software Project" covers the wider stage list this loop sits inside; this post covers just the sprint cycle itself, once a project is already in the build stage. This fits a client who wants working software reviewed as it's built. It's not a fit for a backlog that's expected to grow indefinitely without a corresponding change in scope and cost.
FAQs on Agile Software Development Steps
What are the steps in agile software development?
The core loop is sprint planning, building with automated testing and continuous integration, a sprint review of working software, and a retrospective. Inside a commissioned project, that loop runs against a backlog bounded by what was scoped and quoted at the start, not an open-ended list.
What is the difference between agile and the standard SDLC?
The standard SDLC lists sequential phases: requirements, design, build, test, deploy. Agile compresses design, build, and test into short, repeating sprints instead of one long pass. A commissioned agile project still needs the SDLC's commercial steps, scope, quote, acceptance, wrapped around the sprint loop.
What is a sprint in agile development?
A sprint is a fixed time window, commonly one to four weeks, in which a team plans, builds, tests, and reviews a defined slice of work. Each sprint ends with a working increment, something that actually runs, not a partial feature or a status update.
What happens if a new requirement comes up mid-sprint?
In a scoped engagement, a genuinely new requirement gets raised as a change conversation rather than folded into the current sprint. It gets priced and scheduled separately, so it doesn't quietly extend the agreed budget or push back the delivery date without both sides agreeing to that first.
Does agile mean a project has no fixed budget?
No. Agile describes how the work gets built, in short, reviewed loops, not how it gets paid for. A commissioned agile project can still run on a fixed price or a bounded budget; the backlog inside that budget is what stays flexible, not the ceiling around it.
The Bottom Line
Agile changes the odds of a good outcome. It doesn't remove the need for a bounded scope, and a "challenged" result, late, over budget, or cut down mid-project, stays common even on agile projects that skip that discipline. A backlog that was scoped and quoted before the first sprint is what actually protects a commissioned project from that outcome.
Talk to our team about the project's scope and how change requests should be handled if they come up.
