Software development life cycle models, ranked

Choosing among software development life cycle models

Pick among software development life cycle models by asking how likely your requirements are to change once work starts. Ranked from most to least tolerant of change, the order is Kanban, Scrum, continuous delivery, prototyping, iterative and incremental, Spiral, Waterfall and the V-model.

A life cycle model is the order in which a team plans, builds, tests and releases software. The stages are the same everywhere: requirements, design, build, test, deploy and maintain. AWS describes the same stages and treats the models as different ways of arranging them.

What differs is how many times you loop through those stages and when the customer first sees working code. The model chosen on day one decides how painful the "scope changed in month three" conversation will be, and this ranking is ordered with that conversation in mind.

How these software development life cycle models are ranked

Ranked by change tolerance: how cheaply the model absorbs a requirement that changes after build has started. Rank 1 takes a change this week. Rank 8 expects it to go through a formal review.

That is one criterion, and it is not the only reason to choose a model. A regulated medical device cares more about traceable evidence than flexibility. The list below shows where each model pays for its position.

1. Kanban: highest tolerance, even mid-task. Best for support, maintenance and mixed requests. Weakness: no deadline rhythm.
2. Scrum: high tolerance, at sprint boundaries. Best for new products with feedback. Weakness: needs an engaged product owner.
3. Continuous delivery: high tolerance, per release. Best for live SaaS products. Weakness: needs automated tests first.
4. Prototyping: high tolerance early, low later. Best for unclear requirements. Weakness: the prototype ships as production.
5. Iterative and incremental: medium tolerance. Best for a known architecture with phased features. Weakness: early design flaws are costly.
6. Spiral: medium tolerance. Best for large, high-risk builds. Weakness: heavy overhead.
7. Waterfall: low tolerance. Best for fixed, written scope. Weakness: mistakes are discovered late.
8. V-model: lowest tolerance. Best for regulated, safety-critical work. Weakness: rigid, and late change is expensive.

1. Kanban

Kanban pulls work from a prioritised board and limits how much is in progress at once. Its best job is a steady stream of mixed requests, such as support fixes, small features and maintenance.

There are no fixed iterations, so a new priority can jump the queue the same day. Microsoft's documentation on Kanban boards in Azure DevOps covers work-in-progress limits, which are the one rule that stops the board filling with half-done items.

The trade-off is that nothing forces scope to close. For a greenfield product with a launch date, a Kanban board can drift for months because every item looks equally urgent. It is the wrong choice when a client expects a dated, bounded delivery.

2. Scrum

Scrum works in fixed-length sprints of a month or less, each ending with a demo of working software. Its best job is a new product where each demo changes what you build next.

Change is welcome between sprints and discouraged inside one. That gives developers a stable fortnight and gives the business a regular point to redirect. Microsoft's Agile process guidance for Azure Boards shows how the backlog, sprints and work items fit together.

The weakness is the product owner. If nobody with authority has time to rank the backlog and answer questions within a day, sprints become a ticket factory that ships the wrong things on schedule. Scrum is wrong for teams that cannot staff that role.

3. Continuous delivery

Continuous delivery means every change passes an automated pipeline and can be released at any time. Its best job is a live software-as-a-service product where small, frequent, reversible releases beat large quarterly ones.

Google Cloud's DevOps research programme has tracked deployment frequency and recovery time across thousands of teams for years. It is a useful benchmark when someone claims their release process is fast.

The trade-off is the up-front investment. Without automated tests you do not get continuous delivery, you get faster bad releases. A team adopting it should expect to spend its first weeks on the test suite and the pipeline rather than on new features, and to treat a failing build as a stop-the-line event.

4. Prototyping

Prototyping builds a working sketch early so users can react to something real. Its best job is a project where people cannot describe what they want but recognise it when they see it.

Our Moonship offering is a close relative: a fixed-scope MVP build. The fixed scope matters because an open-ended prototype keeps growing.

The failure mode is that the prototype quietly becomes production. The shortcuts that made it quick, such as hard-coded settings, no tests and a single shared login, ship to real customers.

Decide on day one whether the prototype will be thrown away or hardened, and write that decision down. It is wrong for any project where the requirements are already clear and stable.

5. Iterative and incremental

The iterative and incremental model builds the system in slices, each going through design, build and test. Its best job is a mid-sized system with a known architecture and features released in phases.

Unlike Scrum, the plan for the whole system is usually drawn up front, and the iterations fill it in. That makes budgeting and dependency tracking easier for organisations used to project plans.

The trade-off is that early architecture choices get tested late. If slice four reveals that the data model cannot support a feature, you are changing code that slices one to three already depend on. It is wrong for products whose shape you cannot yet predict, because the up-front plan will be rewritten repeatedly.

6. Spiral

The Spiral model runs in loops, each reducing the biggest risk before building more. Barry Boehm proposed it in 1986, and its best job is a large project with unproven technology.

Each loop might be a feasibility study, then a prototype, then a first build, with a go or no-go decision between them. The decision points are what make it valuable for expensive projects, where a wrong guess could sink the budget.

The cost is overhead. Risk analysis needs experienced people and takes time, so for a small team building a standard web application it adds ceremony without adding safety. It is wrong for any project where the main risks are already known and small.

7. Waterfall

Waterfall completes each stage before the next begins: requirements, design, build, test, release. Its best job is fixed, written scope, such as integrating with a published specification or delivering against a signed contract.

It has a worse reputation than it deserves. Winston Royce's 1970 paper, often cited as its origin, actually described the sequential flow as risky and recommended feedback loops. The strict version is mostly a later simplification.

The trade-off is late discovery. The first working software appears near the end, so a misunderstood requirement surfaces during testing, when it is most expensive to fix. Waterfall is wrong whenever users cannot fully specify what they need up front, which describes most new products.

8. V-model

The V-model is Waterfall with a test stage paired to every design stage. Its best job is regulated or safety-critical software, where an auditor wants to see which test proves which requirement.

Unit tests check the detailed design, integration tests check the architecture and acceptance tests check the requirements. That traceability is the reason to choose it. NIST's Secure Software Development Framework is a catalogue of secure development practices rather than a traceability rule, but it can be mapped onto any model, so a V-model team can use it to structure the evidence an auditor will ask for.

The weakness is rigidity. A change to a requirement means revising the paired test plan, and everything between. It is wrong for anything where users will redirect you, and it needs a strong QA and testing function from the first week rather than the last.

Our recommendation by project type

For a new product, we would pick Scrum with a continuous delivery pipeline. For ongoing support, Kanban. For regulated work, the V-model. For a single idea to be tested quickly, a fixed-scope prototype.

Many projects mix models. Feature work runs in sprints, support runs on a board, and both release through one pipeline. If you are a founder without a technical lead who can make this call, our fractional CTO service exists for exactly that decision, on a fractional basis.

The quick test is to look at your last three change requests and ask how long each waited. If the answer is "until the next phase gate", you are on a model that fits your scope worse than you think. The broken workflow assessment walks through that review with your actual delivery process.