Agile Software Development Lifecycle: Phases, Ceremonies, Roles and Artifacts

Most teams do not struggle with agile vocabulary. They struggle with sequencing. Work enters the sprint without an entry check, testing happens after the release decision, no one owns the retirement call, and every delay gets labeled as an agile problem when it is really a lifecycle problem.

This guide is the operating map for the agile software development lifecycle, from concept to retirement. You will see the six phases in order, what must enter and exit each phase, which ceremonies run where and what they produce, who owns what, and how this lifecycle differs from waterfall and from the neighboring product lifecycle and MVP loop.

Quick answer

• The agile SDLC runs through six phases: concept, inception, iteration, release, maintenance, and retirement. Each phase repeats a plan, build, test, and review loop instead of running once in sequence.
• Each phase has an entry gate and an exit gate. You may start the next phase only when the exit evidence exists, not when the calendar says so.
• Scrum ceremonies live mainly in iteration: sprint planning, daily scrum, sprint review, and retrospective, plus continuous backlog refinement. Release, maintenance, and retirement add a small set of delivery and decision ceremonies around them.
• Product Owner owns backlog order and value maximization, Developers own the increment and quality bar, and the Scrum Master owns event effectiveness and impediment removal, following the 2020 Scrum Guide.
• The product lifecycle tracks commercial stages after market contact. The agile MVP development guide owns sprint level slicing and demo decisions. This page owns the full software lifecycle map they both sit inside.

Table of contents

• The direct answer in 60 seconds
• What agile SDLC is and what it is not
• The six phases from concept to retirement
• Ceremony to phase mapping
• Role and artifact ownership
• Agile versus waterfall orientation
• Lifecycle locator checklist
• Frequently asked questions
• Where to go deeper
• References and further reading
• Why CraftUp helps

The direct answer in 60 seconds

The agile software development lifecycle is an iterative way to take software from an idea to retirement. Work moves in short cycles that each produce a tested increment, collect feedback, and adjust the plan. Atlassian describes the general SDLC as planning, feasibility, design, implementation, testing, deployment, and maintenance. Agile keeps those concerns but folds them into repeating sprints so planning, building, and testing overlap instead of waiting in line.

The version on this page uses six phases because that is the shape practitioners now expect from current guides such as Monday and Skillify, and because it gives retirement an explicit home:

Concept to retirement flow: concept, then inception, then iteration, then release, then maintenance, then retirement.

1. Concept. Decide whether the idea deserves paid discovery. Output is a product vision, a named user, a business reason, and a go or no-go call.
2. Inception. Turn the approved concept into an executable backlog. Output is an ordered backlog, sprint cadence, draft architecture, and acceptance expectations.
3. Iteration. Build in short sprints with continuous testing and review. Output is a tested increment every sprint plus updated backlog and learning notes.
4. Release. Harden, validate with users, and deploy the increment. Output is production software, release notes, monitoring, and a named post-release owner.
5. Maintenance. Operate, fix, and improve in small updates. Output is fixes, small improvements, performance evidence, and backlog additions.
6. Retirement. Migrate users and shut down safely. Output is archived data, migrated accounts, and a closed infrastructure footprint.

If you need one sentence to carry into planning: no phase is done when time passes, a phase is done when its exit evidence exists and its owner has signed it.

What agile SDLC is and what it is not

In plain terms, the agile SDLC is the delivery map for software work. It answers which phase the work is in, what enters and exits that phase, which ceremony runs next, which artifact proves progress, and who decides.

Three boundaries keep this page from colliding with strong neighbors:

1. Agile SDLC is not the product lifecycle. The product lifecycle tracks the commercial arc of a product already near or in the market: introduction, growth, maturity, and decline. The agile SDLC tracks the software work itself from concept through retirement. A product can be in market maturity while one of its components is in agile iteration. Use the lifecycle page to set commercial posture, use this page to run the software work.
2. Agile SDLC is not the MVP sprint loop. The agile MVP development guide owns release goal slicing with MoSCoW, story splitting, sprint execution, and the kill, persevere, or scale call. This page shows where that loop lives, inside iteration and release, and what must happen before and after it. It does not re-teach slicing mechanics.
3. Agile SDLC is not the NPD stage gate system. The new product development process owns idea to launch as a seven stage business process with funding gates and cross functional handoffs. The agile SDLC owns the software engineering rhythm inside and beyond that journey, including maintenance and retirement which NPD treats as post-launch follow up. When the question is funding and business gates, go to NPD. When the question is how software moves phase to phase, stay here.

Two related workflows stay on their owners and appear here only as links. Story format, splitting, and acceptance criteria depth belongs to user stories best practices and acceptance criteria examples. Grooming cadence and the 45 minute agenda belongs to backlog grooming. Product Owner backlog ordering judgment belongs to the delivery and prioritization owners, including prioritization frameworks. This page names the ceremony and the artifact, then points to those owners for method depth.

The six phases from concept to retirement

Use the table as the orientation map, then read the phase notes for entry and exit detail. Entry tells you what must already exist. Exit tells you what proves the phase is complete.

Phase 1 Concept and product vision

Concept answers whether the team should spend discovery capacity at all. Keep it short and written. A usable concept record names the user, the problem with evidence, the business reason, the success signal that would justify further spend, and the main risks.

Enter only with observed input: interview notes, support patterns, sales feedback, usage data, or a market change. A feature request without provenance can enter the pool but may not skip screening.

Exit with a go or no-go call and its reason. A go decision funds inception with a bounded question, not with a full build commitment. A no-go decision records what would reopen the question. If the concept cannot state what would prove it wrong, it is not ready to pass the gate.

The shared ritual here is a short vision workshop with product, design, and engineering plus one stakeholder who controls discovery funding. The artifact is a one page concept note. The new product development process carries the full business case mechanics, this page keeps only the gate.

Phase 2 Inception and sprint planning

Inception turns the approved concept into work a team can start. The team forms, the backlog is created and ordered, user stories carry acceptance expectations, the sprint length is fixed, the technical direction is sketched, and the definition of done is agreed.

Entry requires the concept note and a funded team. Do not start inception with three competing visions and no decision owner. Resolve the bet first.

Exit requires an ordered backlog with at least two sprints of refinable work, a fixed cadence, draft architecture that names the main unknowns, and a release approach that states who accepts the release and how rollback works. The common failure is starting iteration with a long flat list and no ordering principle. Ordering is a Product Owner accountability, and the method choice can borrow from prioritization frameworks without rebuilding that guide here.

Design mockups and prototypes belong here as inception outputs when they reduce a named risk. They are not exits by themselves. A clickable prototype with no backlog, no cadence, and no done criteria is still concept work wearing an inception label.

Phase 3 Iteration and continuous development

Iteration is the core agile loop. Each sprint plans a small scope, builds it, tests continuously, demos working software, and ends with a retrospective that changes the next sprint. This is where Scrum events do their heaviest work, and the next section maps each ceremony to its exact place.

Entry requires a sprint ready slice: explicit user outcome, written non-goals, at least one success signal, known dependency owners, and stories small enough to finish inside the sprint. Stories that fail readiness return to refinement. They do not enter planning as surprises.

Exit happens every sprint with three artifacts: a working increment that meets the definition of done, test evidence tied to that increment, and demo notes that reorder the backlog. Velocity, burn charts, and throughput are useful planning signals, but they are not exits. Only a usable increment plus its evidence closes a sprint honestly.

Keep discovery running beside delivery rather than pausing it. The discovery and delivery guide shows how learning work and production work share one bet. The practical rule for this phase: refinement prepares the next slice while the current sprint builds, and review findings reorder the backlog before the next planning session.

The example below is hypothetical. It shows iteration mechanics, not results from any real team. A team building client approval requests for freelance designers plans a one week sprint with two stories: send a request with a file link and due date, and let the client decide in one click without an account. Both stories carry plain language acceptance checks. The sprint exits with a live increment the team can demo, a short test log, and a decision to order reminder timing behind the core loop rather than inside it. No grooming agenda, story template, or ordering workflow is taught here, those stay on their owners.

Phase 4 Release and deployment

Release turns a tested increment into production software users can trust. Final QA runs, critical bugs are fixed, user acceptance testing confirms the increment meets its stated purpose, deployment documentation is complete, monitoring is live, and the rollback path has an owner.

Entry requires a tested increment, acceptance evidence from iteration demos, and a readiness checklist with named owners for support, docs, instrumentation, communication, and rollback. Do not enter release with known data loss paths, unowned support, or silent monitoring gaps.

Exit requires a live release plus four companions: acceptance sign off, release notes users can understand, dashboards that show the success signal and guardrails, and a post-release owner with a review date. Many agile teams add a beta or pilot with a small cohort before full rollout. That pilot is part of release, not a separate phase, and its learning returns to the backlog.

For launch coordination detail such as messaging sequencing and enablement, use the product launch checklist. This page owns only the engineering gate into production and the handoff that makes the release operable.

Phase 5 Maintenance and continuous improvement

Maintenance begins once the product is live. The team monitors performance, fixes defects, ships small improvements, and collects feedback that feeds the backlog. Agile teams improve continuously instead of waiting for a large release train.

Entry requires telemetry, a support path, and a triage rule. Without those three, every bug report becomes a planning argument. With them, the team can separate incidents from improvements and order each stream honestly.

Exit is continuous rather than once. Each maintenance cycle should produce a small, inspectable result: a fix with regression evidence, a scoped improvement with before and after behavior, or a documented decision not to change anything yet. Track defect recurrence, support load per account, and the cost of delay for queued improvements. When small updates stop holding quality or a structural shift appears, the question moves to retirement rather than to another patch.

Phase 6 Retirement and product sunset

Retirement begins when the software is no longer needed or is replaced by a newer system. The team migrates users, archives data, shuts down infrastructure, and closes support in an order that preserves trust.

Entry requires a sunset decision with scope: which users move where, which data must be kept and for how long, which dates end sale, maintenance, and support, and who owns each communication. An unfunded wish to shut down is not entry. Funded migration with dates and owners is entry.

Exit requires migrated accounts, archived data with a retrieval path, decommissioned systems, and closed support queues. Test the migration itself, including data completeness and access for edge accounts, before shutting down the source system. The second hypothetical example shows the discipline: a reporting add-on keeps a healthy audit pocket while the broad market moves to platform native reporting, so the team narrows the add-on for that pocket, migrates general tier users with export help, then retires the general tier on stated dates. The example is hypothetical and exists to show gate order, not to describe any real company.

Retirement is also where the agile SDLC meets the commercial lifecycle explicitly. The product lifecycle owns the turnaround, harvest, narrow, or sunset capital decision. This page owns the software execution of that call once sunset or narrow is chosen.

Ceremony to phase mapping

The table below is the ceremony contract. It states where each ceremony runs, what it is for, and which artifact it must produce. If a ceremony ends with no artifact, it was a status meeting, not the ceremony.

Three notes prevent common misuse:

First, refinement is continuous preparation, not a phase gate of its own. It feeds planning. Teams that treat refinement as optional arrive at planning with unclear stories and leave with a Sprint Backlog nobody trusts. For the agenda and readiness mechanics that keep refinement short, use backlog grooming instead of inventing a local variant.

Second, the sprint review is a working session with stakeholders, not a slide presentation and not a release gate. An increment can be delivered before the review, and the review can still change the backlog afterward. That distinction comes directly from the Scrum Guide treatment of the increment and review.

Third, Kanban teams without fixed sprints still need the same decision points under different names: a replenishment rule instead of planning, a demo cadence instead of review, and a dated improvement note instead of retrospective. Flow without decision points produces output without learning.

Role and artifact ownership

Ownership means one accountable role plus visible proof. Contribution is welcome from many roles, but accountability is singular. The matrix below follows Scrum accountabilities and extends them to the full lifecycle so concept, release, maintenance, and retirement have owners too.

For PM scope depth beyond delivery, including how this accountability differs across PM, Product Owner, and related titles, use the PM responsibilities guide. For meeting mechanics that keep alignment async where possible, use stakeholder management rituals and the product review agenda.

A practical test for ownership clarity: ask who can say no. If nobody can reject an unclear story, reorder a misleading backlog, stop an unready release, or delay a sunset with incomplete migration, then ownership is decorative. Name the role that holds each no, and write that name on the artifact.

Agile versus waterfall orientation

Waterfall runs phases once in sequence with heavy upfront documentation and a single late release. Agile runs small cycles that each deliver a tested increment and invite change. Neither model removes risk, they place risk in different places. Waterfall risks late discovery. Agile risks drift without decision discipline.

Use this orientation aid to place your situation before choosing ceremonies:

1. Choose waterfall governance when scope is stable and change is costly. Fixed requirements, contractual acceptance, safety or compliance evidence, and irreversible deployment costs favor sequential control. Keep agile engineering habits inside phases where they help, but do not promise emergent scope on a fixed contract.
2. Choose agile governance when learning must change the plan. Unclear user needs, shifting markets, complex integrations, and products that benefit from early use favor iterative delivery. Fix the cadence and the definition of done, keep the backlog emergent, and fund the next cycle on reviewed evidence.
3. Do not mix the worst of both. The common hybrid failure is a fixed date, fixed scope, and fixed budget with an agile label and no entry or exit evidence. If the date is truly fixed, make scope emergent and write that trade explicitly. If scope is truly fixed, use sequential planning and stop calling reordering a sprint decision.
4. Match entry and exit style to the model. Waterfall entries need complete prior phase documents. Agile entries need a ready slice plus an owner for the next decision. Passing an agile phase on document completeness alone, or passing a waterfall gate on demo enthusiasm alone, confuses both models.

For many PM roles, the honest answer is staged: use concept and inception discipline from either model to earn the right to iterate, use agile iteration and release for learning speed, then use explicit maintenance and retirement governance so the product does not drift into unfunded life.

Lifecycle locator checklist

Use this checklist when you inherit work midstream and need to find the phase, the next ceremony, and the missing owner. Answer in order and let the majority place you. When answers split, name the transition and run both playbooks for one cycle.

# Agile SDLC locator

## Current evidence
- [ ] I can state the product vision, target user, and success signal in one paragraph
- [ ] The backlog is ordered and the next two sprints are refinable
- [ ] The team ships a tested increment on a fixed cadence
- [ ] The last increment has demo notes and a reordered backlog
- [ ] Production has monitoring, support ownership, and a rollback path
- [ ] Defects have a triage rule separate from improvement requests
- [ ] There is a named post-release owner with a review date
- [ ] Sunset, migration, or narrow scope has dates and owners if use is eroding

## Phase read
- [ ] Concept when vision, user, or success signal is missing or contested
- [ ] Inception when the backlog is flat, unordered, or has no done criteria
- [ ] Iteration when increments exist but testing, review, or retro is skipped
- [ ] Release when increments exist but acceptance, readiness, or rollback is missing
- [ ] Maintenance when the product is live but triage, telemetry, or ownership is unclear
- [ ] Retirement when use erodes, cost per account rises, or a replacement is ready

## Next ceremony, artifact, and owner
- [ ] Concept: vision workshop, concept note, PM
- [ ] Inception: release planning plus refinement, ordered backlog, Product Owner
- [ ] Iteration: sprint planning, sprint backlog, Developers with Product Owner
- [ ] Iteration inspect: review plus retrospective, demo notes and improvement owners, Product Owner with Scrum Master
- [ ] Release: acceptance testing plus readiness check, acceptance record and checklist, PM with engineering
- [ ] Maintenance: operations review, triage decision and backlog update, PM
- [ ] Retirement: sunset review, sunset plan with dates, PM with portfolio owner

Copy the result into one placement sentence with evidence, for example: this team is in late iteration moving into release for the approval loop, because two tested increments exist with demo notes, but acceptance sign off and rollback ownership are still missing, so the next ceremony is a release readiness check owned by the PM.

Frequently asked questions

What are the phases of the agile software development lifecycle?

The common agile form has six phases: concept, inception, iteration, release, maintenance, and retirement. Concept decides whether the idea deserves discovery. Inception makes the bet executable. Iteration builds tested increments on cadence. Release puts a trustworthy version in production. Maintenance operates and improves in small updates. Retirement migrates users and shuts down safely. Each phase needs entry evidence to start and exit evidence to close.

Which ceremonies run in which phase?

Vision work runs in concept, release planning and refinement run in inception and continue into iteration, sprint planning, daily scrum, review, and retrospective run in iteration, acceptance testing and readiness checks run in release, operations reviews run in maintenance, and sunset reviews run in retirement. The ceremony map pairs each ceremony with its artifact and owner so a meeting without an artifact can be spotted fast.

Who owns what across the lifecycle?

The Product Owner owns backlog order and the product goal. Developers own the sprint plan, the increment, and the quality bar. The Scrum Master owns event effectiveness and impediment removal. The PM owns vision, release acceptance, maintenance queue, and sunset execution with the relevant specialists contributing. The ownership matrix states the proving artifact for each concern.

How does agile SDLC differ from waterfall in practice?

Waterfall completes phases once in sequence with fixed early requirements and late testing, which suits stable scope and strong compliance needs. Agile repeats plan, build, test, and review in short cycles with an emergent backlog and continuous testing, which suits evolving needs and complex products. The orientation aid helps place the situation and warns against fixed date plus fixed scope plus emergent promises with no evidence gates.

How does agile SDLC relate to product lifecycle and MVP work?

The agile SDLC maps software delivery from concept to retirement. The product lifecycle maps commercial stages from introduction to sunset and sets investment posture. The agile MVP loop runs inside iteration and release to test one release goal with MoSCoW slicing and demo decisions. The NPD process maps the business journey from idea to post-launch learning with funding gates. This page links to each owner instead of repeating their depth.

When should a team skip iteration and go straight to release or retirement?

Skip iteration only when the increment already meets the definition of done with test and acceptance evidence in hand, for example a configuration change with proven rollback. Even then, run the release readiness check rather than deploying on verbal confidence. Move toward retirement when use erodes across cohorts, cost to serve rises, or a replacement covers the need, and run the sunset review before cutting maintenance. Both moves still need their exit artifacts.

Where to go deeper

This page owns the concept to retirement map with gates, ceremonies, and ownership. Each neighbor below owns its own depth. Follow the link instead of expecting this page to repeat it.

• Agile MVP development guide: release goal slicing with MoSCoW, story splitting, sprint execution, and kill, persevere, or scale decisions.
• Product lifecycle: commercial stages, stage signals, and per stage strategy shifts.
• New product development process: seven business stages with funding gates and handoff checklists.
• Discovery vs delivery: running learning work and production work around one bet.
• Backlog grooming: cadence and definition of ready that keep planning honest.
• User stories best practices: story formats, splitting, and team review.
• Acceptance criteria examples: plain language and Gherkin formats with observable outcomes.
• Prioritization frameworks: choosing MoSCoW, RICE, Kano, or WSJF for the decision at hand, plus the MoSCoW helper.
• Product launch checklist: launch execution detail for the release phase.
• Theme-based roadmapping and the roadmapping hub: sequencing validated bets after release.

References and further reading

Methodology sources first, these define the models this page builds on:

• The 2020 Scrum Guide, Schwaber and Sutherland: Scrum Team accountabilities, Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Product Backlog, Sprint Backlog, Increment, and Definition of Done.
• Atlassian: What is SDLC, seven SDLC phases with planning, feasibility, design, implementation, testing, deployment, and maintenance, plus Waterfall, Agile, Iterative, V-Model, and DevOps comparison.
• Monday: Agile SDLC explained, six agile phases from planning through retirement with sprint mechanics, Agile values and principles, and Scrum, Kanban, Scrumban, and SAFe framing.
• Agile Manifesto, the four values and twelve principles that orient iterative delivery toward customer collaboration and response to change.

Continue inside CraftUp where each adjacent job gets its depth:

• Product discovery vs delivery, learning work alongside production work.
• Problem validation when to research vs build, choosing cheaper tests before sprint spend.
• PM responsibilities, accountability scope from discovery to launch.
• User Story Generator, MoSCoW prioritization helper, PRD Generator, and Release Checklist Builder for the artifacts each phase needs.

Why CraftUp helps

Reading the lifecycle correctly is a practiced skill: placing the work, running the right ceremony, writing the exit evidence, and holding ownership when the schedule pushes back. That judgment compounds with repetition on real bets.

• Product Management Foundations for the end-to-end system: discovery, validation, strategy, roadmap, and execution across the full arc.
• Product Discovery for the assumption testing muscle that concept, inception, and iteration demand.
• User Story Generator, MoSCoW prioritization helper, PRD Generator, and Release Checklist Builder for the artifacts this lifecycle produces.

Start free on CraftUp to build the habit: https://craftuplearn.com