Waterfall, Spiral, PRINCE2 and Agile — and Scrum up close

Lesson 1 finished on a question: which methodology do this project's attributes call for? This lesson is what sits behind the answer. Four ways of shaping the work, drawn rather than described, and then the one you are most likely to walk into — Scrum — at the depth an interview will ask about.

Reading 45 minutes Follows Lesson 1 Bring nothing — everything runs here

By the end of this lesson you can

• Draw the shape of Waterfall, Spiral, PRINCE2 and Agile, and say what each one optimises for
• Explain why the cost of a change rises with the phase it arrives in, and what each method does about it
• Place Scrum, XP, Kanban, Crystal, Lean, FDD and DSDM inside the Agile family without conflating them
• Name Scrum’s three accountabilities, three artefacts and five events, with the right timebox on each
• Say who owns each Scrum decision, and recognise the common ways teams get that wrong

2.1 · The four shapesStart with the picture

Before any of the vocabulary: what each method looks like when you draw it, and the four trades every one of them is making.

A methodology is not a rulebook a team obeys. It is a shape imposed on the work — where the decisions sit, how often the outside world gets to look, and what happens when somebody changes their mind. Four shapes, one drawing each. The meters underneath are the same four every time, so switching between them is a comparison rather than four unrelated pictures.

Royce, 1970 One pass through requirements, design, build, test and deploy — each phase signed off before the next begins.

Waterfall · five sequential phases, one release, and change priced as a variation

How often the outside world sees the real thing

What it costs to change your mind in week twelve

• How much formal decision-making the method carries
• Up-front documentation 95
• How much is written down before anybody builds

Waterfall Everything is decided while the team knows least, and proved while there is least time left to act on it. In exchange you get a plan somebody can audit from day one.

1 of 4 seen. No bar here is a mark out of a hundred — they are the trades each method makes, and a project decides which trade it can afford.

2.2 · WaterfallBe right the first time.

Sequential phases with a sign-off between each. Its defining property is not the order — it is that going back re-opens something already signed.

Royce described this sequence in 1970, in a paper that also said running it in a single pass was risky. The diagram outlived the warning. Its logic is sound where it applies: if the requirements genuinely cannot move — a regulated migration, a certification, a contract with a fixed deliverable — then deciding everything up front and proving it against a specification is the cheapest honest way to work.

Everything hangs on that “if”. Drag the same change along the sequence and watch what it costs.

When the change arrives

1× What the same change costs here — about 4 hours of work, against four hours at the start.

One change: payments over $10,000 need a second approver

Requirements · 1× · 4 hours Nothing has been built on top of the assumption yet, so the only cost is the conversation and the paperwork. This is the cheapest hour any project will ever spend.

This curve is the entire argument between the methodologies. Waterfall answers it by trying to be right the first time; Spiral answers it by attacking the riskiest unknown first; Agile answers it by never letting a decision get more than a fortnight old.

When it is the right answer

Fixed, signed requirements. An auditor who needs each requirement traced to the test that proves it. A supplier contract with a defined deliverable. Hardware, construction, or anything where the cost of a late change is physical rather than editable.

When it is not

Anything where the customer will only know what they want once they see it working. A new product. A platform whose users have not been asked yet. In those cases the specification is fiction with a signature on it, and every later phase inherits the error.

The V-model is Waterfall with the testing folded up: each phase on the way down is paired with the level of testing that will verify it on the way back up. Same sequence, same sign-offs, with the verification planned at the point the requirement is written rather than months later.

2.3 · SpiralBuy the scariest answer first

Boehm, 1986. The same four activities in widening loops, with a risk analysis choosing what each loop is spent on — and a funding decision at the end of every one.

The spiral is usually mistaken for “Waterfall, but round”. What makes it different is the second quadrant: before anything is built in a loop, the largest remaining risk is identified and attacked, usually with a prototype whose only job is to make an unknown measurable. Then the loop ends with the sponsor deciding whether to fund another.

Walk one project through three loops. Two numbers move as you go, and the second one is the model’s own standing criticism.

The radius is money already spent. Every loop is wider than the one before, which is why the decision to fund another one sits at the end of each.

Cycle 1 · Determine objectivesWhat the first loop is for

Objectives: prove a payment can clear in under five seconds without breaking settlement. Constraints: the bank’s certification window opens twice a year, and the existing ledger is batch-only. Alternatives: extend the ledger, buy a rails provider, or build alongside and cut over. Nothing is committed yet — this quadrant produces a question, not a plan.

Risk still unresolved 100%

Share of what nobody could answer on day one.

Risk analysis is not free. This is the model’s standing criticism.

2.4 · PRINCE2Who is allowed to decide what

PRojects IN Controlled Environments. Seven principles, seven themes, seven processes — and a deliberate silence about how the work is actually built.

PRINCE2 answers a different question from the other three. Waterfall, Spiral and Agile are about how work is sequenced. PRINCE2 is about who is entitled to make which decision, with what evidence, and at which moment — which is why it appears with one of the others rather than instead of one.

Taught as three lists it sounds like bureaucracy. Each item here opens into what it stops going wrong, which is the only way any of it is memorable.

7 principles Non-negotiable. A project that drops one of these is not being run under PRINCE2, whatever the documents say.

Continued business justification

There has to be a reason, and it has to still be true

A documented business case exists before the project is authorised, and it is re-checked at every stage boundary rather than filed. If the justification disappears — the market moved, the regulation changed, the benefit was already captured elsewhere — the project is stopped.

What a project without it looks like Projects that nobody can defend keep running because stopping them is somebody’s awkward conversation. This principle is what makes stopping a normal outcome instead of a failure.

1 of 7 in this list. PRINCE2 7, published in 2023, renames the themes to practices and folds Change into Issues — the same material under newer labels, and worth recognising in both forms because workplaces and certifications are split across the two.

2.5 · AgileA family, not a framework

Four values, twelve principles, no instructions. Everything people mean by “doing Agile” is one of the frameworks that grew underneath it.

Seventeen practitioners wrote the Agile Manifesto in Snowbird, Utah, in 2001. It contains no process, no roles and no ceremonies — four value statements of the form “A over B”, and twelve principles behind them. Each value keeps the right-hand item on the scale. That is the half most often dropped, and most arguments that begin “we’re Agile, so we don’t…” are it going missing.

Four values · drag each beam

Individuals and interactions over processes and tools

The intended reading. A daily conversation resolves in five minutes what a workflow tool escalates for three days. The process still exists — it is just not the thing being served.

Working software over comprehensive documentation

The intended reading. Progress is measured by something that runs, not by a design document that has been approved. This is the value the cost-of-change curve pays for.

Customer collaboration over contract negotiation

The intended reading. A customer in the room every fortnight beats a specification argued over by two legal teams. The contract still exists — it just is not the mechanism for deciding what to build.

Responding to change over following a plan

The intended reading. A plan is a forecast, and a forecast made with new information beats one defended because it was signed. Re-planning is the work, not an admission of failure.

“While there is value in the items on the right, we value the items on the left more.” That is the Manifesto’s own closing line, and it is the sentence most often left off the slide. Nothing on the right is abolished. Agile is a statement about which one wins when the two conflict — which is why an undocumented, uncontracted, unplanned project is not an Agile project. It is just an undisciplined one.

Because the Manifesto says nothing about how to work, frameworks filled the gap — several of them predating the document they now sit under. Tap any branch. These are short on purpose: one of them gets the rest of this lesson.

Tap any branch · none of these is “Agile”, and all of them are

Schwaber & Sutherland, 1995 A lightweight framework of three accountabilities, three artefacts and five timeboxed events, repeating in sprints of one to four weeks.

The idea it contributed

The timebox. A sprint is a fixed length that the work is fitted into, rather than a length that expands to fit the work.

Where you meet it

The default in commercial software, and the one you are most likely to be interviewed about.

Scrum · share of Agile teams 87%

87% of Agile teams use Scrum or a Scrum hybrid — 17th State of Agile Report. Shares add to well over a hundred because most teams run more than one. Only Scrum’s figure is quoted from the report; the rest are indicative orders of magnitude, not measured shares.

Only one of these gets a full section in this lesson, and it is the one on the left of the fan. That is a statement about what you are likely to walk into, not about which framework is best.

2.6 · Scrum · the long sectionThe framework you will actually be handed.

Three accountabilities, three artefacts, five events. Easy to recite, and almost every team that struggles with it is getting the ownership wrong rather than the vocabulary.

Scrum is a lightweight framework for delivering complex products, built on three pillars: transparency — everything that matters is visible to everybody accountable for the outcome; inspection — progress toward the goal is checked frequently; and adaptation — when inspection shows a deviation, something changes immediately. Every event below exists to make one of those three happen on a schedule rather than when somebody remembers.

Start with the whole thing as one object. Tap any part of it.

Tap any part of the diagram · 1 of 8 opened

Artefact Product Backlog

Who

Owned by the Product Owner

How long

Never finished

What it produces

An ordered list

What it is

The single ordered list of everything that might be needed in the product. One list, one owner, and it is the only source of work for the team. It is refined continuously rather than written once — around a tenth of the team’s capacity typically goes on refinement.

The part teams get wrong It is ordered, not prioritised into buckets. “High priority” with fourteen items in it is not an order, and the moment two things are equally first, somebody outside the team is choosing.

1 of 8 opened. Every timebox here is a maximum for a one-month Sprint, and every one of them is part of the framework rather than a suggestion.

2.6.1 · AccountabilitiesThree roles, and no manager

Scrum calls them accountabilities rather than job titles, which matters: one person can hold two of them on a small team, and none of them is a line-management position. There is no project manager inside a Scrum Team, and the work of one is distributed across all three.

Product Owner

One person, never a committee

Accountable for maximising the value of the product. Owns and orders the Product Backlog, develops and communicates the Product Goal, makes backlog items clear, and decides what is released. Their decisions are visible in the order of the list, and the organisation has to respect them for the role to mean anything.

Scrum Master

A servant-leader, not a manager

Accountable for the team’s effectiveness and for Scrum being understood and enacted. Serves the Developers by coaching self-management and removing impediments, the Product Owner by helping with backlog techniques and stakeholders, and the organisation by leading its adoption of Scrum.

Developers

Typically three to nine, cross-functional

Accountable for creating a usable Increment every Sprint. They hold all the skills needed between them, plan the Sprint Backlog, adapt it daily toward the Sprint Goal, and own the Definition of Done. No sub-teams and no internal hierarchy — anyone doing the work is a Developer, whatever their job title says. The 2017 Guide set the range at three to nine; the 2020 Guide frames it as a whole Scrum Team of ten or fewer.

Activity · twelve situations, three buttons

Deciding which of two features is built first

0 right of 0 answered. Nothing is stored, and the wrong answers are the useful ones.

Almost every Scrum dysfunction in the wild is one of these decisions being made by the wrong person. Reciting the roles is easy; placing a live decision under one of them is the skill.

2.6.2 · ArtefactsThree artefacts, each with a commitment

The 2020 Scrum Guide pairs every artefact with a commitment — the thing that makes it measurable rather than a list. An artefact without its commitment is where transparency quietly goes: a backlog with no Product Goal is a wish list, and an increment with no Definition of Done is an opinion.

A real Definition of Done

• Code peer-reviewed and merged
• Unit tests written and passing
• Tested in a staging environment
• Accessibility checked to WCAG 2.1 AA
• API docs and README updated
• Accepted by the Product Owner

Six lines, agreed once, applied to everything. Its whole value is that it is decided before anybody is under pressure to bend it.

Why it is the load-bearing oneIt makes “done” a fact rather than a negotiation

Without it, whether a story is finished depends on who is asking and how close the deadline is.

It is the only defence against invisible debt

Every skipped test and undone migration is a loan taken out by a team against its own future Sprints, and the Definition of Done is what stops one being taken quietly.

It is owned by the Developers

Not the Product Owner and not a manager. It changes in the Retrospective, deliberately, for future work — never to absorb a story that has already missed it.

2.6.3 · EventsFive events, and the timebox nobody scales

The numbers everybody memorises — eight hours, fifteen minutes, four hours, three hours — are maxima for a one-month Sprint, and every one of them moves when the Sprint does. Move the slider and watch them. Then look at the share of capacity the five events consume, which does something most people do not predict.

• Sprint Planning · max 4 hrs
• Daily Scrum · 15 min × 10 days = 2.5 hrs
• Sprint Review · max 2 hrs
• Retrospective · max 1.5 hrs

23× a year that stakeholders see something working, at 2 weeks a Sprint across about 46 working weeks.

Total event time is 10 hrs across 10 working days of about 6 usable hours — 16.7% of capacity, at every Sprint length. The scaling events scale and the Daily Scrum is per day, so the proportion never moves.

Timeboxes are maxima, not targets — a Sprint Review that takes ninety minutes has not broken anything

Two weeks · the length most teams settle on Ten working days and about 23 Reviews a year: long enough to finish a real piece of work, short enough that a wrong turn is caught inside a fortnight. This is where most teams land, and it is why "two weeks" is the answer people assume the framework specifies. It does not — the Guide says one month or less.

2.6.4 · User storiesWhat goes in the backlog

Scrum does not require user stories — the Guide says “Product Backlog item” and stops there. They are borrowed from XP, and they have survived because the third clause forces somebody to say why the work is worth anything before it is scheduled.

The standard template, filled from the attendance product this site runs on

A usable story

A person, an action and a reason. The reason is what lets a developer suggest a cheaper way to get the same outcome, and it is the clause most often missing.

INVEST · six tests for a storyIndependent

It can be built without waiting on another story, so the order can change.

Negotiable

It is a placeholder for a conversation, not a contract clause.

Valuable

Somebody outside the team would notice it arriving.

Estimable

The team can size it. If they cannot, they do not understand it yet.

Small

It fits comfortably inside one Sprint. Thirteen points usually means split it.

Testable

There is an observable way to tell whether it is done.

Acceptance criteria for the first story

• Attendance percentage is shown for every enrolled paper
• Absence dates are listed in chronological order
• A warning appears when attendance falls below 80%
• The page loads in under two seconds on the campus network
• It works on a phone and on a desktop

Written by the Product Owner, verified by the team, and agreed before the story enters a Sprint. Acceptance criteria are per story; the Definition of Done applies to every story. Teams that confuse the two end up with either a bloated Definition of Done or stories nobody can accept.

Story points are relative size, not hours — the Fibonacci-ish 1, 2, 3, 5, 8, 13 scale exists to stop false precision. Total points completed per Sprint is the team’s velocity, useful for forecasting that team’s next few Sprints and useless for comparing one team with another.

2.6.5 · The boardMove the work and watch the numbers

The board and the burndown are not in the Scrum Guide. Every team uses them anyway, because transparency needs somewhere to happen. Eight real stories from this platform’s own attendance product: tap a card to move it right, and set which day of the Sprint it is.

Tap a card to move it one column right · from Done it returns to To do

28 points still to burn, of 36 committed. The ideal line sits at 14.4 on day 6.

Burndown · committed points remaining, against an even burn

About 14 points behind the line Being behind is information, not a verdict. The response is to look at why — usually work sitting in review, or items that were larger than they were sized — and to talk to the Product Owner about the Sprint Goal while there is still time to change something. Working later is the one response that fixes nothing.

Jira, Trello, Linear, GitHub Projects, Azure DevOps — or a wall and some sticky notes, which is where all of them came from. The tool is not the method, and a team whose board is accurate on a wall is in better shape than one whose Jira is tidy and lies.

2.7 · Side by sideAll four, one table

Worth a screenshot before the 60% case study. Every row here is a question you can ask about a real project.

The last row is the one the case study is marked on. Naming the method is worth almost nothing; naming the conditions under which your chosen method fails, and saying why this project does not meet them, is the argument.

End of the lessonCheck yourself

Six questions on what this lesson claimed. Nothing is stored and nothing is reported — this is for you, now, while there is still time to reread.

A requirement changes while the system is already in production. Under a Waterfall lifecycle, why is that change so much more expensive than the same change during requirements?

What this lesson saidFive things to carry forward

• 01 A methodology is a bet about when you find things out. Waterfall bets you can be right first time. Spiral buys the answer to the worst unknown first. Agile refuses to let any decision get more than a fortnight old.
• 02 The cost-of-change curve is the argument underneath all of it. The same change is roughly sixty times dearer in production than in requirements. Every framework on this page is a different response to that one fact.
• 03 PRINCE2 governs; it does not build. Seven principles, seven themes, seven processes — and a Managing Product Delivery seam where Waterfall or Scrum still has to go.
• 04 Agile is a family, not a framework. Scrum, XP, Kanban, Crystal, Lean, FDD and DSDM all sit under the Manifesto, and the Manifesto values the right-hand items too — just less.
• 05 Scrum is three accountabilities, three artefacts and five events, and the ownership is the hard part. Only the Developers decide how much. Only the Product Owner orders the backlog and cancels a Sprint. Only a Done Increment counts.

Everything below this line is where the course goes next. The lesson itself ends here.

NextWhere this goes

Scope and money come next, and both of them behave differently depending on which of these methods you chose.

Scope, and the sentence that costs the most money

The work breakdown structure, the scope baseline, and why “while you’re in there, could you also…” is free to say and expensive to absorb. Under Scrum the same request has a place to go — the Product Backlog — which is most of why the framework survives contact with real stakeholders.

Estimating and cost management

Three-point estimates, PERT, reserves and the S-curve, worked through the SecurePay NZ scenario that runs through this course. Story points and velocity are the same problem answered by a team rather than by a spreadsheet, and the lesson covers where each one is appropriate.

Certify what you have just read

Atlassian’s own Jira path, a LinkedIn Agile Professional Certificate and a free completion certificate. None of them costs anything, and all three name Scrum vocabulary that job listings ask for by name.

Your lecturerBring me a bad Sprint.

The most useful thing you can bring to the next class is a team you have watched run one of these badly — a standup that became a status report, a Definition of Done that moved, a stage gate nobody could fail. Naming which part of the framework was missing is exactly the skill the 60% case study is marked on.

Yasas Sri Wickramasinghe MBI804 lecturer