How software
gets built.

Every software project does the same eight things, whatever it calls its process. A method never adds a ninth or skips one. It turns three dials: the order, the batch size, and who decides.

Hold on to that and every method in this manual becomes comparable. Waterfall runs all eight once, on the whole scope, with sign-offs between them. Scrum runs most of them every two weeks on one Sprint's worth of work. Kanban runs them for one item at a time, as soon as there's room. The activities didn't change; the dials did.

The eight, one at a timeWhat each activity is for

Each activity answers one question and leaves something behind. If you can't point to what an activity produced, it probably didn't happen — which is the most common way a project fails without anyone noticing.

Two questions pick a method better than any framework's marketing: how much don't you know yet? and how expensive is it to change your mind once you've built something?

When a lot is unknown, the most valuable thing a process can give you is fast feedback — each short cycle tells you something you couldn't have planned for. When a late change is very expensive (a recall, a regulator, a contract), the most valuable thing is catching mistakes before they're built in. Most arguments about method are really arguments about where a project sits on these two axes.

The first variable, over timeThe cone of uncertainty

Uncertainty isn't fixed; it shrinks as decisions get made. Barry Boehm's data on estimation error, later named the cone of uncertainty by Steve McConnell, puts an honest range on an estimate at each stage: at the idea stage, a quarter to four times the eventual actual Boehm 1981 McConnell 2006. That is a sixteen-fold range, and it is the best case — the cone narrows only when decisions actually remove variability, not because time passes.

Every method's lifecycle is one of four shapes, or a deliberate mix of two. The shapes differ in one thing a stakeholder cares about: what can people actually use, and when?

Below, the same product — four features, each at three levels of finish — is built four ways over the same twelve weeks. Hatched cells are built but not yet in users' hands; solid cells are usable. Stop the slider at week 6 and read the four sentences.

Most real methods combine two. Scrum is incremental within each Sprint (every Increment is finished and usable) and iterative across the product (the backlog is re-ordered every Sprint as the team learns). Spiral is iterative and gated by risk at once. Asking "which shape, or which pair?" is a more useful question about a method than asking whether it's agile.

February 2001, a ski lodge in Snowbird, Utah. Seventeen people who each ran a different "lightweight" method spent three days finding what those methods agreed on. They wrote it down on one page Beck 2001. They didn't invent a method there.

What they were reacting to was specific. The heavyweight, document-first processes common in the 1990s were good at planning a known thing and bad at absorbing what a project discovers once it's underway. The lightweight methods had each found ways to learn during delivery; the Manifesto named what they shared. They rejected "lightweight" as a name — it sounded like less rigour, not less ceremony — and chose "agile".

The Manifesto is four lines and one sentence. The sentence is the part most quotations drop, and it changes the meaning of the four lines.

Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.

Manifesto for Agile Software Development, 2001 Beck 2001

Each line is a weighting, not a replacement. The authors kept process, documentation, contracts and plans; they put them second. Every common misreading of agile comes from dropping the right-hand side entirely — and each one costs something specific, later, somewhere else.

The twelve principles published with the Manifesto are its operational half Beck 2001 — and the half most teams skip when they say they're agile.

A principle with no practice behind it is a poster on a wall. So read these as an audit, not a creed: for each one, can your team point to something it actually does, on a schedule, that makes the principle true? Where you can't, the chip underneath leads to the chapter with a practice that implements it.

Not a defence, and not a takedown. Four positions worth knowing — two of them from Manifesto authors — and how to tell a team doing agile from a team performing it.

Two sources, cited very differentlyThe evidence, and the statistic to stop quoting

Two bodies of numbers get quoted about agile. One publishes its method and has held up to scrutiny; the other is quoted far more often than its method survives.

Cargo cultSix tells, by symptom

A retrospective that changes nothing and a standup run for a manager aren't failures of agile; they're signs it was adopted as a set of meetings. Each tell below is something you can observe, with what it usually means and what to change.

Nine methods that all deliver in short, repeated cycles. The useful way to tell them apart is one question: what starts the next piece of work? A date on the calendar, a free slot on the board, or a bet someone placed.

Scrum starts work when a Sprint starts. Kanban starts work when an item finishes and frees a slot under the WIP limit. Shape Up starts work when the betting table picks a pitch. That one difference decides most of the rest — how much gets planned at once, how interruptions are absorbed, and what a stakeholder can be promised.

Six methods built on a different premise: do the thinking up front, verify before building at scale, and treat a gate as a feature. This is the family most often caricatured — so start with what its most-cited source actually says.

I believe in this concept, but the implementation described above is risky and invites failure.

Winston Royce, “Managing the Development of Large Software Systems”, 1970 — the paper Waterfall is usually traced to Royce 1970

Royce drew the single pass in order to warn against it, then proposed fixes: a preliminary design before analysis, heavy documentation, doing the whole job twice with a pilot first, planned testing, and involving the customer. What became known as Waterfall kept the diagram and dropped the fixes.

Each gate in this family converts calendar time into assurance: nothing proceeds until someone accountable signs that the previous step is right. That is worth paying for when a late defect is very expensive — firmware, medical devices, anything regulated — and is waste when the requirements themselves are still being discovered.

Every scaling framework answers the same question: what breaks when one product needs more than one team? They differ in how much structure they add to fix it — from almost none (LeSS) to a great deal (SAFe).

Four of the six extend Scrum: LeSS, Nexus, Scrum@Scale and SAFe. Team Topologies doesn't assume Scrum at all; it works on team boundaries and cognitive load. The "Spotify model" is included because it is so often copied — it describes one company in 2012, not a method.

A project that delivers the wrong thing on time has still failed. These four methods sit upstream of every delivery method in chapters 08–10: they decide what to build, before anyone argues about how.

Each one answers a different question, and teams often run two at once — jobs-to-be-done research to find the problem, a design sprint to test a solution, and MVPs in dual-track discovery to keep checking.

These are methods for deciding structure, and they run alongside a delivery method rather than instead of one. A Scrum team can use all four in the same quarter.

Event storming discovers what happens in the business. Domain-driven design turns that into bounded contexts and a shared language. The C4 model draws the result at four zoom levels. Architecture decision records keep the reasons, so they don't have to be re-argued every time someone new joins.

Most of this page assumes that software, once built and tested, does the same thing every time. Data science and ML break that assumption; LLM features break it on every call. These three methods are how teams cope.

CRISP-DM (1999) is still the clearest map of a modelling project, though its deployment phase predates modern operations. MLOps maturity models describe how far a team has automated training, release and monitoring. Evaluation-driven development is what LLM teams converged on: the evaluation set plays the part that unit tests play for deterministic code.

A user story is not a specification. It is a placeholder for a conversation, with a test that settles when the conversation is over.

Ron Jeffries named the three parts Jeffries 2001: the Card — one sentence, small enough to fit on an index card; the Conversation — where the details actually get worked out, with the people who'll build it; and the Confirmation — the acceptance test that says whether it's done. Teams that write long stories are usually trying to do the conversation in writing, in advance, alone.

Is it a good story?INVEST, applied

Bill Wake's six letters are the quickest check Wake 2003. A story that fails one isn't wrong so much as not ready — the failure tells you what to do next: split it, find its test, or remove the dependency.

From list to releaseStory mapping

A flat backlog answers "what's next?". A story map answers the harder question: what is the smallest release that lets someone do the whole thing? Lay the reader's journey left to right, stories under each step, most important on top — and cut releases horizontally across all of it Patton 2014.

What quietly drops outRequirements that don't fit “as a user…”

Latency, availability, security, accessibility and data retention rarely have an obvious user who "wants" them, so a backlog made only of user stories tends to lose them until an incident forces the conversation. Write them down as their own items, with thresholds — "p95 page load under 1.5s on 4G" — or as entries in the Definition of Done that every story must meet. For requirements precise enough that an AI agent can't misread them, the EARS patterns on /spec-driven go further.

**As a** {type of user}
**I want to** {perform an action}
**So that** {I achieve a goal}

**Acceptance criteria:**
- Given {context}, when {action}, then {outcome}

**Estimate:** {points}
**Definition of Ready check:** {yes/no}

## Definition of Ready

- [ ] The problem and the desired outcome are stated in one sentence
- [ ] Acceptance criteria are written (Given/When/Then or EARS)
- [ ] Dependencies are identified and not blocking
- [ ] Sized small enough to plausibly finish inside one iteration
- [ ] The team that will build it has seen and can ask questions about it

Caution: a Definition of Ready can become a gate that delays work as
easily as it can protect a Sprint. Review it if items are stuck "not
ready" for more than one refinement session.

Most estimation arguments are three different things wearing one word: an estimate, a commitment and a target.

Treating a target as if it were an estimate is where most "the estimate was wrong" conflicts start. The fix is to say which of the three you're giving, every time.

Sizing workStory points and planning poker

A story point is a relative size — this is about twice that — deliberately not hours, so it resists being read as a promise. Planning poker makes a team size an item without anchoring on whoever speaks first: everyone picks privately and reveals at once Grenning 2002 Cohn 2005. Its real output isn't the number. It's the disagreement, which surfaces what somebody knows and the others don't.

Forecasting instead of guessingMonte Carlo from throughput

Once a team has a few weeks of history, there's a better question than "how big is it?": how many items do we actually finish per day, and what does that imply? Replay the team's own recent days at random thousands of times, count how long each replay takes to finish the remaining items, and read the answer at a stated confidenceVacanti 2015. No one has to guess, and the answer comes with its own uncertainty.

Tracking a SprintBurndown or burnup?

Both chart the same Sprint. Only one of them can tell a stall from a change of scope.

Plans are made at three distances, and each deserves a different amount of confidence. The mistake is giving them all the same — usually by putting a date on every row.

A roadmap with a date on every item promises more than its far end can keep; chapter 02's cone of uncertainty applies to dates exactly as it does to estimates. A now / next / later roadmap states its confidence in its structure: now is committed, next is likely, later is direction without a date.

The middle distanceQuarters, OKRs and cross-team planning

The quarter is where dependencies between teams get planned — SAFe's PI Planning is the most elaborate version (chapter 10). It's also where OKRs usually live. An Objective names a direction; its Key Results say how you'll know you got there. Neither is a backlog item. An OKR that is really an epic with a new label creates a second priority list competing with the first.

Notice the shape: each key result is served by several backlog items, and one item serves two results. If every key result maps to exactly one item, the OKRs are a duplicate backlog.

The shortest distanceWhat fits in one iteration

Iteration planning is bounded by capacity, and capacity is never the calendar. Subtract what you already know is coming — the events, the other meetings, support rotations, leave — and then keep a buffer for what you don't know. Then compare the answer with what the team actually finished in its last few iterations, and trust the lower number.

Under every method on this page sits the same arithmetic: how much work is in progress, how fast it finishes, how long each piece takes, and where it waits. This chapter is six instruments, five of which you can run. None of them is a metaphor.

1 · The one equationLittle's Law

Average work in progress equals average throughput times average cycle time. It is a theorem about any stable queue, not a rule of thumb Little 1961: hold any two still and the third is fixed. The version to remember: cycle time = WIP ÷ throughput. If a team finishes the same amount per week, the only way to make each item take less time is to have fewer items going at once.

2 · The leverWhat a WIP limit actually does

A WIP limit caps how many items can be in progress at once. Below, three people pull from a backlog that never empties. Change only the limit. Up to three items — one per person — throughput rises and each item still takes under three days. Past that, throughput stops rising, and every extra item in progress becomes extra days on every item's cycle time.

3 · The trapWhy a fully booked team is slow

Planning a team to 100% of its capacity feels efficient. Queueing theory says otherwise: when work arrives at uneven times and takes uneven amounts of effort, the time it waits before anyone starts rises slowly and then very fast as utilisation approaches 100% Kingman 1961 Reinertsen 2009. Slack isn't waste; it is what keeps waiting times short.

4 · The constraintFind the bottleneck before you optimise anything

A system delivers at the rate of its slowest step Goldratt 1984. Speeding up anything upstream of that step only makes the pile in front of it grow faster; speeding up anything downstream changes nothing. The first question about any delivery problem is where does work wait?

5 · The instrumentsReading a cumulative flow diagram

A cumulative flow diagram plots, day by day, how many items have ever started, reached review, and finished. Two readings come straight off it: the vertical gap between the top and bottom lines is work in progress; the horizontal gap is roughly how long an item took. A band that widens is a queue growing — a bottleneck you can see without asking anyone.

6 · The forecastService levels: what 85% actually means

Plot every finished item's cycle time and draw the percentiles. "85% of our items finish within N days" is a service level expectation: not a promise, a statement about the team's own history that a stakeholder can plan around Vacanti 2015. The long tail is normal — and it is why a single average date misleads.

A meeting with no stated output is this manual's definition of a wasted meeting. Every event below states its output first, then its agenda.

Scrum's four events are the most widely run, so start there — on a real calendar, at their real timeboxesSchwaber 2020. Their total is usually smaller than people fear, and the time is only wasted when an event loses its output.

Output firstThe events worth running well

The same shape for every event: what comes out, what goes in, the agenda, and the observable sign it's going wrong. The Daily Scrum is the one most often broken — it drifts from the Developers' planning huddle into a status report to a manager, and then nobody plans anything.

The event that makes the others improveRetrospectives: five formats

Every format runs through the same five phases: set the stage, gather data, generate insights, decide what to do, close Derby 2006. The format only changes how you gather data — pick it for the Sprint you just had. What doesn't change: a retro ends with a change someone owns.

# Postmortem: {incident title}

**Date / Duration:** {when, how long}
**Severity:** {P0–P3}
**Author:** {name}

## Summary
{2–3 sentences: what happened and the user-facing impact.}

## Timeline
- {HH:MM} — {event}

## Root cause
{The mechanism, not "human error" — what in the system allowed this.}

## What went well
## What went poorly
## Where we got lucky

## Action items
| Action | Owner | Due | Priority |
|--------|-------|-----|----------|

Methods decide when work happens. Engineering practice decides whether the work is any good — and most methods are silent on it. These are the practices that fill that silence.

Where to spend testing effortPyramid, trophy, honeycomb

The test pyramid Cohn 2009, the testing trophy Dodds 2021 and the testing honeycomb Schaffer 2018 are three answers to the same question. None is correct in general. Look at where your last twenty bugs came from, and put the tests there.

Test firstOne loop of test-driven development

TDD is a loop measured in minutes: write a failing test, write the least code that passes it, then improve the code while the test keeps you honest Beck 2002. The tests are a by-product; the short feedback loop is the point.

test("an article's reading time rounds up to whole minutes", () => {
  expect(readingTime(1)).toBe(1);
  expect(readingTime(230)).toBe(1);
  expect(readingTime(231)).toBe(2);
});

// readingTime.ts
// (nothing here yet)

The practice, not the serverContinuous integration

Continuous integration means everyone merges to one shared trunk at least daily, and every merge is built and tested automatically Fowler 2006. A build server that tests long-lived branches is useful, but it isn't the practice. Trunk-based development keeps branches to hours or a day or two Hammant 2017; the arithmetic below is why.

Done means doneA Definition of Done you can enforce

The Definition of Done isn't a column on a board. It's a checklist the team holds itself to before anything counts as finished. An item that meets six of seven isn't nearly done — it's not done.

Deploying code and releasing a feature are different events, and separating them is most of modern release practice. The mechanics — pipelines, environments — live on /version-control; this chapter is the policy: who sees a change, when, and what stops it.

A feature flag lets code ship to production switched off, then turn on for a chosen set of people. That turns a release from one irreversible moment into a dial you can move — and move back.

Limiting the blast radiusCanary releases

A canary release sends a small share of traffic to the new version first and widens it in steps, with a rule that rolls back automatically if errors cross a threshold. The point isn't to prevent bad releases — some will get through testing — it's to limit how many people meet one.

How much failure is allowedSLOs and error budgets

A service level objective states a target — say, 99.9% of requests succeed over 30 days. The 0.1% it allows is the error budget: failure the team may spend, usually on shipping faster. When it runs out, the agreed policy shifts priority to reliability until it recovers Beyer 2016 Beyer 2018. Every extra nine divides the budget by ten.

Two more practices make releases survivable. An on-call rotation spreads the load of being woken at night — designed badly, it burns people out, which is an organisational problem, not a scheduling one. And a runbook, written before the incident, turns 3am improvisation into following steps.

Two ways a project finds out it's in trouble: early, from a list of what might go wrong; or late, from numbers that stopped meaning anything the day someone was judged on them.

Before it goes wrongThe RAID log

Risks, Assumptions, Issues, Dependencies — one list, so nothing forward-looking quietly turns into an unplanned problem. The distinction that matters most: a risk might happen; an issue has. Risks are retired by testing them — a spike, a prototype, a fake-door test — not by discussing them at every meeting. The premortem on /decisions is the fastest way to fill the list.

Delivery performanceDORA's five metrics

The DORA research programme measures software delivery with five metrics: three for throughput and two for instability DORA 2025. They began as the "four keys"; in 2023 time to restore became failed deployment recovery time, and in 2024 deployment rework rate was added DORA 2025. The durable finding is that speed and stability move together — teams that do well do well on all five.

Against a single numberSPACE

No single number captures developer productivity. The SPACE framework names five dimensions and argues for reading several at once, mixing survey data with system data Forsgren 2021.

Why numbers stop meaning thingsGoodhart's law, made visible

"When a measure becomes a target, it ceases to be a good measure" — Marilyn Strathern's phrasing of Charles Goodhart's point Strathern 1997. Velocity shows it most clearly: make points a target and the points inflate, while the work shipped doesn't change.

Every method on this page is run by people arranged into teams, and the arrangement shapes the software more than most technical decisions do.

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Melvin Conway, “How Do Committees Invent?”, 1968 Conway 1968

Conway's law works in both directions. Left alone, a system takes the shape of the org chart. Used deliberately — the inverse Conway manoeuvre — you arrange the teams to get the architecture you want.

Designing teams on purposeTeam Topologies

Skelton and Pais name four team types and three ways teams interact Skelton 2019. The idea underneath is cognitive load: a team can only hold so much of a system in its head, so scope has to be sized to the team, not the other way round. Most teams should be stream-aligned; the other three types exist to take load off them.

Who decidesDecision rights

RACI assigns each decision one Accountable person, at least one Responsible, and lists who is Consulted before and Informed after. The rule people break is the first one: two Accountable people means nobody is. DACI makes the same point with a Driver who pushes the decision to a close.

The condition for everything elsePsychological safety

Psychological safety is a shared belief that the team is safe for interpersonal risk: raising a problem, admitting a mistake, asking a naive question Edmondson 2018. Google's Project Aristotle, which studied its own teams, found it the strongest of the factors it identified in effective teams — ahead of who was on the team.

One feature — let a reader save an article to finish later, a real candidate for this site — built four times: under Scrum, Kanban, Shape Up and the V-Model. Same team, same feature, same working-day ruler.

Pick a method and step through it. Each step changes that method's own artifact: cards cross the Scrum board and the burndown extends; the Kanban card ages against its service level; scopes climb Shape Up's hill; the V-Model's levels light up as each gate is signed. The ruler above the stage keeps all four in view, so you can see where every method stands on the same day.

None of the four numbers is right or wrong on its own. Kanban was fastest because the item joined a board that was already flowing; the V-Model spent its extra fifty-odd days buying a signed trace from requirement to test. Which of those is worth paying for is chapter 02's question — how much you don't know yet, and how expensive a late mistake would be.

Scrum, 10 days to readers: day 0, Refinement — “Save an article for later” is near the top of the Product Backlog. The team splits it into five tasks and sizes it at 5 points. day 0, Sprint Planning — The feature's five tasks and two smaller items go into the Sprint. The Sprint Goal names the outcome, not the task list. day 1, Work starts — Two Developers start on the schema and the API in parallel. day 3, Schema done — The schema is merged. Work begins on the save button and the thumbnail cache. day 4, Blocker, raised at the Daily Scrum — The thumbnail cache can't write to object storage — a permissions problem outside the team. It's raised at the Daily Scrum; the Scrum Master takes it to the infrastructure team. day 5, Unblocked — Permissions are fixed overnight. While blocked, that Developer picked up the small pagination fix and finished it. day 7, API and dark mode done — The API is merged; the save button is in review; the saved list page starts. day 9, Checked against the Definition of Done — Everything but the saved list page is reviewed, merged, deployed to staging and smoke-tested — the team's Definition of Done. day 10, Sprint Review, then Retrospective — The Increment is shown working. The Product Owner accepts it and decides to release. The Retro adds one item to the Definition of Ready: check infrastructure permissions before planning. Kanban, 8 days to readers: day 0, Replenishment — “Save for later” goes into Ready. In Progress is at its limit of 3, so nothing starts yet. day 1, Pulled when a slot frees — The pagination fix moves to Review, freeing a slot. The top of Ready is pulled. The cycle-time clock starts now, not at replenishment. day 3, Aging check at the standup — Two days in progress, well inside the service level expectation: 85% of items finish within 6 days. No action needed. day 6, Finished — but Review is full — The code is done, but Review is at its limit of 2. Instead of starting something new, the Developer helps review the items ahead of it. day 7, Pulled into Review — A review slot frees up; ★ moves in. day 8, Done and deployed — Review passes and the change deploys. Cycle time: 7 days — just past the 6-day SLE, one of the 15% it allows. It becomes a new point on the cycle-time scatterplot. Shape Up, 24 days to readers: day 0, Shaped and bet on — The pitch: readers lose articles they meant to finish. Appetite: six weeks for a team of two. No-gos: no cross-device sync this cycle. The betting table places the bet. day 2, Scopes mapped — The team explores the codebase and names three scopes — the parts they'll get over the hill one by one. day 8, Figuring out the data model — Most unknowns are in how saves relate to readers and articles. Positions on the hill are honest: still uphill. day 12, Scope hammered — Thumbnails need storage work nobody planned. They're cut from this cycle to protect the date. Time is fixed; scope moves. day 16, Over the hill — The data model and API are settled. Both scopes cross the top: what's left is known work. day 22, Finishing — Polish, edge cases, QA. day 24, Shipped — Save for later ships inside the cycle. The circuit breaker never had to fire. day 30, Cycle ends; cooldown — Two weeks of cooldown: bugs, clean-up. Thumbnails can be pitched again for a later cycle — nothing is queued automatically. V-Model, 66 days to readers: day 0, Requirement written — REQ-014: an authenticated reader can save an article and retrieve it from a dedicated view. Its acceptance test is designed in the same sitting. day 10, Requirements gate — The requirement and its verification plan are signed off together. day 11, System design — A SaveService component is designed; the system test (concurrent saves from two tabs) is designed alongside it. day 25, Design gate — System, architecture and module designs are signed off with their paired integration and unit test designs. day 26, Implementation starts — Coding begins against the frozen design — 26 working days after the requirement was written. day 50, Build complete; unit tests pass — Verification climbs the right side of the V, starting at the bottom. day 56, Integration and system tests pass — The concurrent-save system test designed on day 11 now runs against the built system — and passes. day 62, Acceptance test passes — The acceptance test written on day 0 is run as written. day 66, Deployment gate — live — Final sign-off. The feature reaches readers 66 working days after the requirement was written, with every level traced.

A recommendation you can't see the reasons for can't be argued with. This one prints three things with every suggestion: which of your answers drove it, what it will cost you, and what would change it.

Side by sideCompare

Every method in Part III sits on the same schema, so any four can be read across the same rows. Pick up to four.