The agile development life cycle describes how a product moves from a fuzzy idea into working software, then keeps evolving until the team retires it. Six stages. Repeating loops. No big-bang launch.
That's the short version. The longer version matters because most teams misuse the word "agile" — they call any iterative work agile, even when they still hand requirements down a one-way pipe. Real agile is a cadence: build a small slice, ship it, learn, adjust, repeat. Each loop is a sprint, and each sprint touches every stage in miniature.
This guide walks you through all six stages of the agile development cycle — what happens in each one, who runs it, what gets shipped, and how teams measure progress. You'll also see how it compares with traditional agile vs waterfall approaches and where popular tools like Jira and Azure DevOps fit in.
Agile is a delivery philosophy first, a life cycle second. The philosophy comes from the agile manifesto — four values and twelve principles published in 2001 by seventeen developers who were tired of bloated software projects shipping late, over budget, and missing the point.
The life cycle is how teams operationalize those values. Six stages. Time-boxed iterations. Cross-functional teams. Continuous feedback. That's the recipe.
Here's the thing — the six stages aren't strictly sequential. The first two (concept and planning) happen once at the project's birth and lightly at the start of each sprint. The middle three (iteration, testing, release) cycle every sprint, sometimes daily. The last stage (maintenance and retirement) runs in parallel with new sprints once the product is in production.
Different frameworks slice the cycle differently. Scrum emphasizes sprints and ceremonies. Kanban emphasizes flow and limits on work-in-progress. SAFe scales the cycle across many teams. They all share the same backbone: build small, ship often, learn fast. If you want a deeper look at the agile development process, the variations matter less than the rhythm.
Worth knowing — agile isn't just for software anymore. Marketing teams run sprints. Hardware companies use kanban. HR teams write user stories. The life cycle scales to anything where work can be sliced into shippable increments. Even policy work and academic research now borrow agile rhythms when the team needs early feedback instead of a final report.
One more setup note. The phrase "agile development life cycle" gets used three ways in practice: the macro project life cycle across all six stages; the micro sprint life cycle that runs in two weeks; and the product life cycle from launch through retirement. They share the same backbone but operate on different time scales. When somebody at a job interview asks about the life cycle, clarify which one before you answer.
The six-stage model isn't sacred. Some sources list 5 stages, others 7. The version most agile coaches teach — and the one the Project Management Institute references — uses six: Concept, Planning, Iteration/Development, Testing, Release, and Retirement. It maps cleanly onto Scrum sprints and lines up with how Jira, Azure DevOps, and other agile tools structure their workflows. If you see a different breakdown elsewhere, the activities are usually the same — just chunked differently.
Goal: agree the project is worth doing. The Product Owner identifies a business need, drafts a vision, and gets stakeholder buy-in. Deliverables: a one-page vision statement, rough business case, and a high-level scope. No detailed specs yet — just enough to commit. This stage usually lasts days to a couple of weeks, not months.
Goal: turn the concept into a backlog. The team writes initial user stories, estimates them with story points, picks an architecture, and identifies the first sprint goal. The Scrum Master facilitates; the Product Owner ranks the backlog. Output: a prioritized product backlog, a release roadmap, and a definition of done.
Goal: build a shippable increment. Developers pull stories from the sprint backlog and code them. Designers prototype. Daily standups keep everyone synced. Each sprint runs 1–4 weeks (two is most common). The deliverable: working, tested software that meets the definition of done. This stage repeats — every sprint is a mini life cycle of its own.
Goal: verify the increment works and doesn't break what already shipped. QA runs alongside development — not after. Unit tests, integration tests, user acceptance testing, and exploratory testing all happen inside the sprint. Many teams automate the test suite so it runs on every commit. Bugs go straight back into the backlog, prioritized like any other story.
Goal: get the increment in front of real users. Some teams release at the end of every sprint; others batch a few sprints into a quarterly release. Continuous deployment pushes code to production multiple times a day. Deliverables: deployed feature, release notes, updated documentation. Then the cycle restarts with the next sprint planning meeting.
Goal: keep the product running, then sunset it gracefully. Once a feature is in production, the team monitors performance, fixes defects, and trains users. Eventually the product reaches end-of-life — replaced by a new system or no longer needed. The team migrates users, archives data, and shuts it down. Even retirement is iterative.
Stages are nouns. Ceremonies are verbs. Without the four core ceremonies, the iteration stage collapses into a chaotic to-do list. Scrum codified them, and most non-Scrum agile teams still use some version of all four.
Sprint planning kicks off each sprint. The team picks stories from the top of the backlog, breaks them into tasks, and commits to a sprint goal. Two-hour meeting per week of sprint, so a two-week sprint gets a four-hour planning session. Skip this and you'll waste days mid-sprint figuring out what to build.
Daily standup — fifteen minutes, every morning, same time, same place. Three questions: what did I do yesterday, what am I doing today, what's blocking me. It's not a status report for the manager. It's the team syncing with itself. If the standup runs over 15 minutes, you're doing it wrong.
Sprint review happens on the last day of the sprint. The team demos working software to stakeholders. Real software, not slides. The Product Owner accepts or rejects each story against the definition of done. Stakeholders give feedback — which often becomes new backlog items for the next sprint.
Retrospective follows the review. Just the team — no stakeholders. What went well, what didn't, what to change next sprint. This is where continuous improvement lives. Skip the retro and the team stops getting better. The format varies — start/stop/continue, 4Ls, sailboat — but the question is always the same: how do we improve next sprint?
Many teams add a midweek agile ceremonies session called backlog refinement (or grooming). The team looks at upcoming stories, asks clarifying questions, breaks down anything too big, and estimates new items. It keeps sprint planning short because the backlog is already ready when planning starts. Allocate roughly 10% of sprint capacity to refinement and protect that time.
Worth noting — these ceremonies aren't optional dressing. They're the operating system of the iteration stage. Cut them and you'll either ship the wrong thing or ship nothing at all. The math is simple: ceremony time runs 10–15% of the sprint; the feedback it generates saves multiples of that in rework.
Activities: Identify the business need. Draft a vision statement. Run stakeholder interviews. Build a one-page business case. Estimate rough scope and budget.
Owner: Product Owner with executive sponsor.
Deliverables: Vision statement, elevator pitch, high-level scope, go/no-go decision. Most concept stages wrap in 1–2 weeks. Anything longer means you're trying to plan in waterfall style.
Activities: Write initial user stories. Set up the product backlog. Pick the tech stack. Define done. Run a release planning workshop. Estimate first sprint capacity.
Owner: Whole team — Product Owner leads, developers contribute estimates, Scrum Master facilitates.
Deliverables: Prioritized product backlog (typically 30–60 stories), release roadmap with rough quarterly milestones, definition of done.
Activities: Sprint planning. Daily coding. Pair programming. Code reviews. Continuous integration. Daily standups. Mid-sprint backlog refinement.
Owner: Development team self-organizes; Scrum Master removes blockers.
Deliverables: Working software increment that meets the definition of done. Updated codebase. Demo-ready features for the sprint review.
Activities: Unit tests written alongside code. Integration tests on every merge. User acceptance testing with the Product Owner. Exploratory testing for edge cases. Performance and security tests for production-bound code.
Owner: QA engineers embedded in the team; everyone tests.
Deliverables: Passing test suite, bug reports added to backlog, accepted user stories.
Activities: Final regression tests. Deploy to staging. Smoke test. Deploy to production (manual approval or automatic). Update release notes. Notify users. Monitor first-hour metrics.
Owner: DevOps engineer or release manager; team owns rollback if needed.
Deliverables: Feature live in production, release notes published, deployment metrics captured.
Activities: Monitor production. Triage incoming bugs. Train new users. Decide when the feature or product reaches end-of-life. Migrate users to replacement. Archive data and code.
Owner: Product Owner makes the call; operations team executes the sunset.
Deliverables: Stable production system, eventual migration plan, archived deliverables, lessons learned document.
Agile teams are small — five to nine people is the sweet spot — and they have three named roles. Other titles exist (designer, QA engineer, DevOps), but the three core roles drive the life cycle.
The Product Owner owns the what. They write user stories, rank the backlog, accept or reject completed work, and represent the customer's voice on the team. One person, not a committee. The Product Owner is the only role that can change priorities mid-sprint — and even then, only by swapping stories of equal size. The PO also runs stakeholder management: keeping execs informed, negotiating scope changes, and saying no to feature requests that don't fit the vision.
The Scrum Master owns the how. Not the boss, not the manager — a facilitator and impediment-remover. They run the ceremonies, coach the team on agile practices, shield the team from outside interruptions, and track sprint metrics. Good Scrum Masters work themselves out of a job; the team eventually self-manages. In kanban-only teams, this role is often called "team coach" or "agile coach" — same job, different label.
The Development Team owns the building. Cross-functional means whoever is needed to deliver the increment — developers, designers, testers, ops engineers. The team self-organizes around the sprint goal. Nobody assigns tasks; team members pull work as they finish previous work. This pull system is what makes agile feel different from traditional project management. Pull beats push because the person closest to the work picks the next item, not a manager who's three layers removed.
If you're studying for a agile certification exam, expect questions on the boundaries between roles. The Product Owner doesn't tell developers how to build; the developers don't decide priority; the Scrum Master doesn't assign work. Cross those lines and the model breaks. Hybrid teams with managers or tech leads often blur these boundaries — which is fine in practice as long as the ceremonies still happen and the team retrospects honestly about what's working.
Larger organizations adopt scaling frameworks like scaled agile when one team isn't enough. SAFe, LeSS, and Nexus all keep the three core roles but add coordination layers above — a Product Manager owning multiple POs, an RTE (release train engineer) coordinating SMs, and shared sprint planning across teams. The complexity grows fast, which is why most coaches recommend mastering single-team agile before scaling. A frequent failure pattern: adopting SAFe at the org level without ever running a clean two-week sprint at the team level.
Role boundaries also explain why so many agile transformations stall. Executives sometimes treat the Scrum Master as a project manager who reports status, and the Product Owner as an analyst who writes specs. Both are wrong. The Scrum Master serves the team; the Product Owner serves the product. Neither answers to a steering committee. When organizations preserve old reporting lines while bolting on new titles, they get cargo-cult agile — same hierarchy, new vocabulary, no behavior change.
Writes user stories, ranks the backlog, accepts completed work, represents the customer. One person, not a committee.
Facilitates ceremonies, removes impediments, coaches the team on agile practices, shields from outside interruptions.
Cross-functional group of 3–9 people who design, code, test, and ship the increment. Self-organizing — nobody assigns tasks.
Agile teams measure their own throughput so they can plan future sprints realistically. Three metrics show up everywhere — velocity, burndown, and story points — and a few others worth knowing.
Story points are a relative sizing unit. A 1-point story is small; an 8-point story is roughly eight times the effort. Points are not hours — they bundle complexity, uncertainty, and effort into one number. Teams estimate using planning poker or t-shirt sizing, then convert to points. Most teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13) because relative jumps get harder to estimate as stories get bigger.
Velocity is the average number of story points a team completes per sprint. After three or four sprints, velocity stabilizes — call it 30 points per sprint. Now the Product Owner can forecast: if the next ten stories total 60 points, that's two sprints of work. Velocity is a planning tool, not a performance review metric. Comparing velocity across teams is meaningless because each team estimates differently. Don't do it.
Burndown charts show remaining work versus time. The line should burn down to zero by the last day of the sprint. If it's flat for three days, something is stuck — that's a signal for the Scrum Master to investigate. Burndown charts go on the wall (or the dashboard) so the whole team can see them daily. Burn-up charts work too — they show completed work climbing instead of remaining work dropping. Same data, different visualization preference.
Other useful metrics include cycle time (how long a single story takes from start to done), lead time (idea to deployed), and escaped defects (bugs found in production). The right metric depends on what you're trying to improve. Want faster delivery? Track cycle time. Want better quality? Track escaped defects. Want predictability? Track velocity variance sprint over sprint. Just don't track everything at once — it dilutes attention and creates dashboards nobody reads. Pick one north-star metric per quarter and let the rest run quietly in the background until a retrospective surfaces them.
One last metric trap to avoid — never tie an individual's pay or review to story points. The moment velocity becomes a personal target, estimates inflate, quality drops, and the metric stops meaning anything. Teams self-correct only when metrics are diagnostic, not punitive.
Tools don't make a team agile. But the right tool makes the life cycle visible. The top three in 2026 are Jira, Azure DevOps, and Trello, with a long tail of newer options. If you want a deeper comparison, see agile project management tools.
Jira from Atlassian is the enterprise standard. It supports Scrum boards, Kanban boards, custom workflows, advanced reporting, and integrates with Confluence, Bitbucket, and dozens of CI/CD tools. The downside: Jira is heavy. Small teams often configure it for weeks before they ship anything. Pricing is per-user, with a free tier up to ten users.
Azure DevOps from Microsoft bundles work tracking with code repos, build pipelines, and test management. If your team already lives in the Microsoft stack, Azure DevOps removes friction. It supports Scrum, Agile, and CMMI process templates out of the box. Free for the first five users, then $6 per user per month for the Basic plan.
Trello is the lightweight Kanban board most teams start with. Cards, lists, drag-and-drop. Trello is free for small teams and ramps up fast — but it doesn't handle complex hierarchies (epics, features, multiple teams) gracefully. Most teams outgrow it after a year and migrate to Jira, Linear, or Asana.
Other options worth knowing — Asana, ClickUp, Monday.com, Linear (popular with engineering teams), and GitHub Projects (free with any GitHub repo). The tool matters less than the team's commitment to keeping it accurate. A neglected Jira board is worse than a sticky-note wall, because at least the wall is hard to ignore.
The traditional waterfall SDLC moves through five phases — requirements, design, implementation, testing, maintenance — in strict sequence. Each phase must end before the next begins. No backwards. No iteration. Documentation is exhaustive; change is expensive once a phase closes.
Waterfall worked when requirements were stable and change was expensive. Building a bridge. Launching a satellite. Software in 1970. But modern software ships in days, not years. Customer needs shift. Markets pivot. The waterfall model handed completed projects to users who had moved on six months earlier — and the project budget had often doubled by then.
Agile fixes the feedback gap. Every sprint produces working software that users can actually try. If priorities change, the next sprint absorbs the change — no twelve-month rewrite required. That's the headline. Cost of late discovery drops dramatically because problems surface in week two, not week eighty.
The trade-off — agile demands more discipline from the team and more involvement from stakeholders. Daily standups, sprint reviews, and constant prioritization require energy that waterfall doesn't ask for. Teams that try agile without changing their culture end up with the worst of both worlds: ceremony overhead without the feedback benefit. For a deeper breakdown of when each model fits, see agile vs waterfall. Some regulated industries — aerospace, defense, medical devices — still use waterfall by design, because compliance demands documentation up front and change control is expensive.
Hybrid models are common in 2026. A team might run waterfall-style requirements gathering for the first month, then switch to two-week sprints once a baseline architecture is locked. Government IT contracts often mandate waterfall deliverables (gantt charts, signed-off specs) while letting the team work in sprints underneath. The trick is to treat the two systems as a translation layer — sprint outputs become waterfall artifacts at the milestone boundaries, and nobody has to lie about what they're doing.
Bottom line: the agile development life cycle replaces a single, long, fragile sequence with many short, resilient loops. Six stages, repeating ceremonies, three roles, a handful of metrics — and a discipline of shipping before you feel ready. The framework is forgiving when you respect the rhythm; it punishes shortcuts ruthlessly when you skip the parts that feel optional.
"Agile means no planning." Wrong. Agile front-loads less planning than waterfall, but it plans constantly — every sprint, every standup, every backlog refinement. The difference is that agile planning lives at the right level of detail for the right time horizon: rough roadmap for the quarter, detailed stories for the next sprint, hourly tasks for today.