Agile SDLC: the phases, the models, and how the cycle actually runs

SDLC stands for the software development life cycle: the sequence of phases a product moves through from idea to retirement. The term predates agile by decades, and the phases themselves have barely changed since the 1970s. What changed is the shape of the journey through them. The traditional model walks the phases once, in order, with a gate between each. The agile model runs all of them in every iteration, two to four weeks at a time.

That one structural change explains almost everything people attribute to agile: earlier feedback, cheaper course correction, working product from the first month, and the discomfort of never having a final, signed-off plan. It also explains why the debate is not really agile versus the phases, since agile keeps them all, but about how often you are willing to cycle through them.

This guide walks the six phases as they run inside an agile cycle, compares the mainstream models from Scrum to SAFe, and gives the selection logic we use when we set up delivery for client teams. It pairs with our direct comparison of agile versus waterfall, which goes deeper on the choice between the two, and with our step-by-step process guide, which follows one project through the cycle end to end.

What "agile SDLC" actually means

Strictly speaking, agile is a set of values from the 2001 Agile Manifesto, and the SDLC is a phase structure. "Agile SDLC" is the practical fusion the industry settled on: keep the phases, because they describe real work that cannot be skipped, but run them iteratively and incrementally. Iteratively means repeating the cycle; incrementally means each repetition ships a usable slice of the product rather than a document about it.

The clearest way to see the difference is to follow one requirement. In a sequential cycle, a requirement written in month one is designed in month three, coded in month six, tested in month nine and seen by a user in month twelve, by which time the market that produced it has moved. In an agile cycle, the same requirement enters a sprint backlog, is designed, built and tested inside a two-week iteration, and is in front of users before the month ends. The feedback then reshapes the next iteration's requirements, which is the loop doing its job.

One vocabulary note, because it causes real confusion in procurement conversations: agile is not a synonym for Scrum. Scrum is one way to organize the agile cycle, the most popular one, but Kanban, XP and the scaled frameworks are equally agile. When a vendor says "we work agile," the useful follow-up is "which model, and what does your cycle look like?"

Five terms this article uses precisely

SDLC

The software development life cycle: the phase structure from planning through maintenance. Model-neutral; both waterfall and agile are ways of traversing it.

Iteration (sprint)

One timeboxed pass through all phases, typically one to four weeks. Scrum calls it a sprint; the concept is older than Scrum.

Increment

The working, potentially shippable product slice an iteration produces. The unit of progress in agile, replacing the signed-off document.

Backlog

The ordered list of requirements awaiting a cycle. Reordering the backlog is how agile absorbs change without replanning everything.

Definition of done

The agreed checklist an increment must pass, usually including tests and review. It is the quality gate that keeps speed honest.

The words below get used loosely in most writing on this topic. Fixing their meaning up front makes the rest of the article shorter.

The six phases, as they run inside an agile cycle

The phases below are the classical set. What follows for each is not the textbook definition but what the phase becomes when it runs every two weeks instead of once.

Planning becomes two layers: a product roadmap revisited quarterly, and sprint planning that commits the team to a small, concrete goal. Requirements analysis becomes backlog refinement: user stories with acceptance criteria, written just in time, in enough detail for the next cycle only. Design splits the same way, with a light architectural runway maintained ahead of the team and detailed design done inside the sprint for the stories at hand.

Implementation is where agile is most demanding, not least. Because the code integrates continuously, the phase depends on version control discipline, automated builds and code review as a routine rather than an event. Testing moves from a phase at the end to a property of every day: unit tests written with the code, automation running on every merge, and exploratory testing inside the sprint. Deployment and maintenance merge into a release rhythm, with increments shipped at sprint boundaries or continuously, and production feedback flowing straight back into the backlog.

The agile cycle, phase by phase

1. PlanDay 1

   Sprint goal, story selection, capacity check against the roadmap.

   Done when A sprint backlog the team believes fits the timebox.

2. AnalyzeContinuous, peaks day 1-2

   Refine stories to ready: acceptance criteria, edge cases, dependencies.

   Done when Stories meet the definition of ready before work starts.

3. DesignDays 2-4, then as needed

   Detailed design for this sprint's stories; architecture runway for the next.

   Done when Approach agreed in review, not in a signed document.

4. BuildDays 2-9

   Code in small merges, reviewed and integrated daily against the main branch.

   Done when All stories code-complete with tests, nothing hoarded locally.

5. TestEvery day, gate on day 9-10

   Automated suites on every merge; exploratory and acceptance testing in-sprint.

   Done when Definition of done met; escaped-defect list empty or triaged.

6. Release and learnDay 10

   Ship the increment, demo to stakeholders, retrospective on the process.

   Done when Increment in users' hands; backlog reordered by what was learned.

Spans describe one two-week sprint. The same structure stretches to one-week or four-week cycles without changing shape.

How the agile cycle differs from the traditional one

The traditional, sequential model, usually called waterfall, is not a strawman. It is a coherent way to build when requirements genuinely cannot change: each phase completes fully, produces a signed artifact, and hands off to the next. Its economics follow from that shape. Because integration and acceptance happen once, at the end, the cost of discovering a wrong assumption grows with every month between the assumption and the discovery.

The agile cycle inverts that risk curve. A wrong assumption survives at most one iteration before a demo or a production metric exposes it. The price is constant overhead: planning, review and retrospective every cycle, and an architecture that must tolerate continuous change. On a project where nothing was ever going to change, that overhead buys little. On the median product build, where a third or more of the initial requirements churn before launch, it is the cheapest insurance available.

The middle ground matters more than most writing admits. Regulated industries often run an agile build inside a waterfall wrapper: fixed compliance milestones and documentation gates, with iterative delivery between them. Done deliberately, that hybrid is legitimate. Done accidentally, with sprint ceremonies pasted onto a fixed-scope contract, it is the worst of both, and it is the single most common dysfunction we are asked to repair. The full comparison, including cost behavior and contract shapes, is in our agile versus waterfall guide.

Sequential versus agile, on the axes that decide projects

Axis	Sequential (waterfall)	Agile cycle
Phase traversal	Once, in order, with gates	All phases every iteration
Working product first seen	Near the end	End of the first iteration
Change between phases	Formal change request, replan	Reorder the backlog, next cycle
Where defects surface	Integration and acceptance, late	Inside the iteration that created them
Documentation	Heavy, contractual, up front	Lighter, continuous, just in time
Fits best when	Scope is genuinely frozen, penalties for change	Requirements will evolve, feedback is available
Fails hardest when	The market moves during the build	No product owner, no real users to learn from

Neither column is universally right. The last two rows are the ones that should drive the choice, and the ones most often ignored.

The major agile models: Scrum, Kanban, XP and the scaled frameworks

Scrum organizes the cycle into fixed-length sprints with three roles (product owner, scrum master, developers) and four ceremonies (planning, daily standup, review, retrospective). Its strength is rhythm: the sprint boundary forces integration, demo and reflection on a clock. It fits product builds with a dedicated team, which is why it dominates. Its weakness is rigidity for interrupt-driven work, where a two-week commitment is fiction.

Kanban drops the timebox entirely. Work flows through a visualized board, with explicit limits on work in progress, and the team optimizes flow time rather than sprint velocity. It fits maintenance, support, and any queue where priorities shift daily. Many mature teams run Scrumban: Scrum's cadence for planning and retrospectives, Kanban's flow rules for the work itself.

Extreme Programming (XP) is the engineering conscience of the family: test-driven development, pair programming, continuous integration, collective code ownership. Few teams adopt XP whole, but its practices became the technical floor beneath every serious agile team; a Scrum team without XP-style engineering discipline accumulates defects faster than it ships features. The scaled frameworks (SAFe, LeSS, Nexus, Spotify-style models) exist for one problem only: many teams, one product. They add coordination layers, and each layer costs speed, so the standing advice is to scale the product architecture before scaling the process.

Which model fits which situation

	Scrum	Kanban	XP practices	SAFe / LeSS
New product build, one team	Yes	part	Yes	No
Maintenance and support flow	part	Yes	Yes	No
Interrupt-heavy operations work	No	Yes	part	No
Quality crisis, defect backlog	part	part	Yes	No
Five or more teams, one product	part	part	Yes	Yes
Distributed or offshore team	Yes	Yes	Yes	part

A filled cell means the model is a natural fit for that situation; a partial fit means it works with adaptation; empty means it fights you.

Choosing a model for your team

Start from the shape of your work, not from familiarity. If the work arrives as a roadmap of features for a product, Scrum's cadence will serve you. If it arrives as an unpredictable queue, Kanban's flow will. If your problem is quality rather than throughput, adopt XP practices first regardless of the wrapper, because no process cadence fixes an untested codebase.

Then be honest about the two preconditions every agile model shares. First, an empowered product owner: one accountable person who can reorder the backlog and accept increments without a committee. Absent that, cycles degenerate into mini-waterfalls waiting for decisions. Second, real users or stakeholders who look at increments and react. Agile's advantage is the feedback loop; with no one on the other end, you are paying the ceremony cost for nothing.

For distributed teams, and for teams working with an offshore partner like ours, the model matters less than the artifacts. A written definition of done, a groomed backlog, recorded demos and honest retrospectives cross time zones far better than hallway agility does. That is why we default to Scrum with strong written practices for client work: the cadence gives remote stakeholders predictable checkpoints, and the artifacts keep decisions inspectable. The commercial side of that choice, including how it shapes estimates, is covered in our cost guide.

A model selection procedure that takes one afternoon

1. 1

   Classify the workStep 1

   Roadmap-shaped work points to Scrum; queue-shaped work points to Kanban; a mix points to Scrumban.

2. 2

   Check the preconditionsStep 2

   Name the empowered product owner and the real feedback source. If either is missing, fix that before choosing anything.

3. 3

   Set the engineering floorStep 3

   Version control discipline, CI, automated tests, code review. These are non-negotiable under any model.

4. 4

   Pick the cadenceStep 4

   Two-week sprints are the sane default. Go shorter for fast-moving products, longer only for heavy hardware or compliance coupling.

5. 5

   Scale only when forcedStep 5

   Add SAFe or LeSS only when multiple teams genuinely share one product and architecture cannot decouple them.

Run in order. Most teams finish at step 3 with Scrum or Kanban plus XP practices; the scaled frameworks enter only at step 5.

Measuring whether your cycle actually works

Ceremony compliance is not a metric. Teams can attend every standup while shipping nothing, and the literature on agile theater is written by their stakeholders. The measurements that matter describe the cycle itself: how long work takes to flow through it, how often it produces a release, and how much defect load escapes it.

Four numbers cover most needs. Lead time, from a story entering the backlog to running in production, measures the whole loop. Deployment frequency measures whether increments actually ship or pile up in a staging branch. Escaped defects, found in production rather than in-sprint, measure whether the definition of done is honest. And velocity, the perennial favorite, is useful only as a planning input for one team over time; comparing velocities across teams or vendors is numerology, because the unit is self-defined.

The pattern to expect when a cycle is healthy: lead time falls for two or three quarters and then stabilizes, deployment frequency climbs until it hits the organization's release appetite, and escaped defects fall as test automation compounds. When all three plateau at once, the constraint has usually moved outside the team, to decision latency or environment provisioning, and that is where the next improvement lives.

Measuring the cycle: practices that inform versus practices that distort

Do this

• Track lead time end to endFrom backlog entry to production, because that is the promise agile makes to the business.
• Count escaped defectsProduction bugs per release, trended. It keeps the definition of done from quietly eroding.
• Use velocity for capacity planning onlyOne team, over time, as a forecasting input. Nothing more.
• Review metrics in retrospectivesThe team that generates the numbers should be the first audience for them.

Not this

• Compare velocity across teamsStory points are self-defined units; the comparison rewards inflation, not output.
• Set velocity targetsAny team can hit a point target by repricing stories. The metric dies the day it becomes a goal.
• Measure individuals by tickets closedIt punishes review, pairing and testing, the activities that make the cycle work.
• Report burndown as progress to executivesBurndown shows effort consumed, not value shipped. Demo the increment instead.

Every metric here has been used both ways. The difference is whether the number describes the system or judges the people.

Running an agile cycle with an outside team

Everything above assumes a team; none of it assumes the team sits in your building. The agile cycle crosses company boundaries well, provided three things are contractual rather than aspirational. First, the engagement model must price iterations, not a frozen scope: a dedicated team or time-and-materials structure lets the backlog reorder freely, which is the entire point. Second, the definition of done must be written into the working agreement, including test coverage and review, so that "done" means the same thing on both sides of the contract. Third, the demo rhythm must survive time zones, with recorded sprint reviews and a shared backlog tool as the single source of truth.

This is how we run client engagements at AgileTech: Scrum cadence, a product owner on the client side, our delivery lead closing the loop, and the engineering floor (CI, automated tests, code review) supplied by the team rather than negotiated per project. Distributed does not mean diluted; the artifacts and the cadence carry the process. What changes with an offshore partner is economics, not the life cycle, and we have written up both sides of that trade-off in our guides to offshore delivery and outsourcing to Vietnam.

Before starting an agile engagement with any vendor

• Which model, exactly?Expect a concrete answer: Scrum with two-week sprints, Kanban with WIP limits, and why that choice for your work.
• What is in your definition of done?Tests, review, documentation, deployment. If it is not written, it does not exist.
• How do we reorder the backlog?The mechanism and the notice period. This is where fixed-scope contracts reveal themselves.
• What do we see every sprint?A working increment on a real environment, not a slide about one.
• Which metrics will you report?Lead time, deployment frequency and escaped defects beat velocity charts.
• Who is accountable on each side?A named product owner from you, a named delivery lead from them, and a written escalation path.

Six questions that separate vendors who run the cycle from vendors who run the vocabulary. Every answer should be specific and boring.

Frequently asked questions

A life cycle is only as good as the team running it. If you want the agile cycle delivered rather than diagrammed, work with AgileTech, an engineering partner in Vietnam whose teams arrive with the cadence, the tooling and the discipline already in place.