# Software Development Life Cycle Phases in Agile > The SDLC phases still exist under Agile, but the sequence does not. Here is what each phase becomes, and where the phase framing stops helping. Source: https://www.koombea.com/blog/software-development-life-cycle-phases-agile/ Published: 2026-08-22 Author: Jose Gomez --- Almost every guide to the software development life cycle draws the same diagram. Six or seven boxes, left to right, one arrow between each. Planning, then requirements, then design, then build, then test, then release. The boxes are real work. The arrows are the part that rarely survives contact with a running team. Agile does not delete any of those phases. You still plan. You still decide what the software should do. You still design it, build it, test it, and ship it. What changes is when each phase happens, how much work moves through it at a time, and how often you go back. This post walks each phase, explains what Agile turns it into, and then does the less common part. It shows you where the phase framing itself starts to mislead you. ## Key Takeaways - The [SDLC](https://www.koombea.com/blog/system-development-life-cycle/) phases are activities, not calendar stages. Agile keeps the activities and drops the fixed order. - Under Agile, every phase runs in every iteration, on a much smaller slice of the product. - Smaller batches are the actual mechanism. Feedback arrives while the decision is still cheap to change. - Some work genuinely belongs up front. Architecture, data modeling, security, and regulatory obligations do not iterate cheaply. - If your two-week cycles each contain a full sequence of handoffs, you are running short waterfalls, not Agile. ## The Phases, Stated Plainly Before you can talk about how Agile reshapes the life cycle, you need the phases themselves in neutral terms. Most models list six phases. **Planning.** Deciding whether to build, what problem it solves, and what constraints apply. Budget, timeline, and success criteria live here. **Requirements and analysis.** Turning intent into something specific enough to build against. Users, behaviors, rules, edge cases, and acceptance criteria. **Design.** Deciding how the software will work. Architecture, data model, integrations, and interface all count. **Implementation.** Writing the software. **Testing.** Confirming the software does what was specified, and finding out where it does not. **Deployment and maintenance.** Getting it into users' hands, then keeping it healthy as usage and requirements shift. Nothing about that list is Agile or Waterfall. Both models perform all six. They differ on batch size and sequence. ## What Agile Actually Changes Waterfall completes each phase for the entire product before starting the next one. All requirements, then all design, then all code. The batch is the whole system. Agile shrinks the batch. You take one thin slice of product value, carry it through every phase, and ship it. Then you take the next slice. The phases stop being stages on a calendar and become activities you repeat. That single change causes almost everything else people associate with [Agile](https://www.koombea.com/blog/benefits-of-agile/). Shorter feedback loops. Working software early. Requirements that change without a crisis. The reason is unglamorous. A wrong assumption you catch in week two costs almost nothing. The same assumption in month nine already carries code, tests, documentation, and other decisions on top of it. Small batches do not make teams smarter. They make being wrong cheaper. ## Planning Becomes Continuous Waterfall planning produces one plan. Agile planning produces a plan you expect to revise. Three planning horizons coexist. The product level sets direction and outcomes over quarters. The release or [roadmap](https://www.koombea.com/blog/agile-roadmap/) level groups work into meaningful increments. The iteration level commits to specific items for the next two weeks. Only the iteration level is a commitment. The others are current best guesses, and they are supposed to move as you learn. This is where teams new to Agile stumble. They hear "we replan every two weeks" as "we have no plan." The direction should be stable. The route to it should not be. ## Requirements Become Conversations In a phase-gated model, requirements get signed. In Agile, they get discussed, written down, and refined right before the work starts. The written artifact still matters. A user story with no acceptance criteria is not lightweight, it is unfinished. What changes is timing and depth. You specify the next slice in detail. You leave the slice three months out as a headline. That is a deliberate trade. Detailed specification of work you never build is waste, and specification decays as you learn. Writing it late keeps it accurate. The cost is real. Late specification demands people who can answer questions on short notice. Agile requirements work fails most often when nobody can reach the person who knows the business rules. ## Design Moves Alongside the Build This phase causes the most confusion, because many teams read Agile as "no design." What Agile actually rejects is designing the whole system before writing any of it. Interface design, [product design](https://www.koombea.com/capabilities/product-design/) research, and detailed screen work happen a short distance ahead of implementation, close enough to stay relevant. Architecture is different, and this is where honest advice diverges from the diagram. Some decisions resist change. Your data model, your authentication approach, your service boundaries, and your choice of platform all get harder to reverse as code accumulates. Deciding those late is not agility. It is deferred cost. Decide them early, decide them at the level of detail you can justify, and write down why. ## Implementation and Testing Stop Being Separate In the classic life cycle, testing follows implementation. Under Agile, that boundary largely disappears. Tests derived from acceptance criteria exist before or alongside the code. Automated checks run on every change. A story is not done because the code compiles. It is done because it passes the criteria someone wrote for it. This is the phase collapse that delivers most of Agile's quality benefit, and it is also the one most often skipped. A team that writes stories in two-week cycles but tests everything in a hardening phase at the end has kept the [testing life cycle](https://www.koombea.com/blog/the-importance-of-the-software-testing-life-cycle/) exactly where Waterfall put it. Manual and exploratory testing still matter. They work best against software that already passes its automated checks. ## Release Becomes Routine Deployment in a phase-gated project is an event. People remember the date. There is a war room. Agile treats release as a repeatable, automated procedure. The goal is not necessarily to ship every day. The goal is to be able to, so that shipping is never the thing blocking a decision. Getting there is engineering work, not process work. Continuous integration, environment parity, database migration discipline, feature flags, and a rollback path you have actually tested. Teams that adopt Agile ceremonies without this investment keep the ceremony and the release anxiety. ## Maintenance Feeds Planning The last box in most SDLC diagrams is maintenance, and the diagram usually ends there. That ending is the diagram's biggest distortion. Once software is live, operational reality becomes your best requirements source. Support tickets, usage data, performance traces, and security findings all tell you what to build next. In an iterative model, [maintenance](https://www.koombea.com/capabilities/maintenance-and-support/) is not a phase after the project. It is an input to the next iteration. Treating it as a separate downstream activity is how organizations accumulate the technical debt that eventually forces a rewrite. ## Where the Phase Framing Breaks Down Here is the part most SDLC articles leave out. The phase model has real limits under Agile practice, and knowing them saves you from arguments nobody can win. **Phases stop being a schedule.** You cannot report "we are in the design phase" in an iterative model, because every phase is active somewhere in the product at all times. Status has to name work items and their state, not a phase position. Stakeholders who want the phase answer want a completion date, and that conversation goes better if you talk about [throughput](https://www.koombea.com/blog/agile-metrics/) instead. **Sprints become miniature Waterfalls.** The most common failure pattern in the wild. Requirements on Monday, design Tuesday, code Wednesday through Friday, testing crammed into the last two days. Each phase hands off to the next. The iteration is short, but nothing about the flow is iterative, and the testing squeeze is structural. **Some phases resist thin slicing.** Hardware procurement, long lead times, security review, and regulatory approval run on their own clocks. In regulated environments, evidence requirements are mandatory and often sequential. That does not rule out Agile, but it does mean the [secure development life cycle](https://www.koombea.com/blog/secure-software-development-life-cycle/) has gates that iteration does not remove. **Discovery does not fit inside a two-week box.** Serious user research, complex data migration analysis, and integration reverse engineering often take longer than one iteration. Forcing them into sprint-sized pieces produces shallow work with a completed ticket attached. **The framing hides the real constraint, which is decision latency.** Most delayed projects are not slow at building. They are waiting on an answer. Neither the phase diagram nor the sprint board shows that clearly, so teams optimize the visible activity and never measure the actual bottleneck. ## How to Tell Which Model You Are Running Process labels are unreliable. Behavior is not. Five questions worth asking about your own team: 1. Can you release to production today if a business reason appears? If not, what specifically blocks it? 2. Does testing happen inside each item of work, or after a batch of them? 3. When a requirement changes mid-iteration, is that a normal event or an escalation? 4. Who answers a question about business rules, and how long does the answer take? 5. Which architectural decisions have you deliberately made, and which are you avoiding? Answers to those five say more about how you build software than any methodology name on a slide. ## Final Thoughts The SDLC phases are a useful vocabulary and a poor schedule. Agile keeps the vocabulary, shrinks the batch, and turns the sequence into a loop. Every real gain follows from smaller batches and faster feedback, not from ceremonies. So keep the phases as a checklist of work that has to happen somewhere. Just stop expecting them to happen in order, and stay honest about the few that genuinely need to come first. ## Frequently Asked Questions **Does Agile have SDLC phases at all?** Yes. Planning, requirements, design, implementation, testing, and deployment all happen. They repeat every iteration on a small slice instead of running once across the whole product. **How many phases are in the Agile SDLC?** There is no fixed count, because different sources split the same work differently. Six is the most common list. What matters is covering all the activities, not how many boxes you draw. **Is Agile better than Waterfall?** Agile suits work where requirements will change and feedback is available. Sequential models still fit projects with fixed, verifiable requirements and heavy compliance evidence. The honest answer depends on how much you already know. **Where does documentation fit?** Wherever it earns its keep. Write down architecture decisions, data contracts, and compliance evidence, and keep them current. Documents produced to satisfy a phase gate, and never read again, are the ones Agile targets. **Can regulated industries use Agile?** Yes, with adjustments. Build the evidence trail as you go instead of assembling it at the end. The required approvals stay sequential, so plan around them rather than pretending they iterate. If your cycles are short but delivery still feels like a sequence of handoffs, the problem is usually batch size and testing placement rather than the methodology. Koombea has been shipping [production software](https://www.koombea.com/capabilities/product-engineering/) since 2007, and we scope work in story points so the commitment is a defined outcome instead of a phase schedule. [Get in Touch](https://www.koombea.com/contact/) if you want a second read on how your life cycle is actually running.