Agile Estimation & Planning

Requirements and the levels of agile planning

Every project has to answer "what are we building, and when will it be ready?" A traditional project answers by writing everything down before any design starts. Agile teams believe that is usually impossible for software, so they need a different way to plan: one that commits to a direction early but fills in the detail only as late as it safely can. This Part follows that planning path from a product idea to an estimated, ordered backlog, through sprint planning, to tracking progress with velocity and burndown charts. The Scrum framework itself (roles, events, the sprint) is in Part III, and formal scheduling (WBS, critical path, earned value) is in Part VIII.

Traditional vs agile: one assumption splits them

Both kinds of process need requirements; they differ in when and how they capture them. The whole difference grows from one assumption. A traditional process assumes the requirements can be fully specified up front, so it gathers them once, at the start, into detailed documents. An agile process assumes that complete requirements are hard to define up front (users don't know exactly what they want until they see something working), so it keeps them as short stories and lets them evolve.

The table sets the two side by side along five dimensions. Read the first row first, because every other row follows from it: if you believe requirements can't be known up front, you will naturally keep them short, gather them gradually, and give one person the job of ordering them by value.

A Product Owner is the Scrum role accountable for the value of the product; for planning, the important thing is that the PO owns and orders the list of requirements. The Developers are the people who build each increment, and the Scrum Master keeps the process working. This Part colours them consistently: Product Owner, Developers, Scrum Master, and stakeholders (the clients, users and sponsors who have an interest in the product).

Five levels of planning

Agile teams don't skip planning; they plan at several levels, each with a different horizon. The slides list five levels, from the product vision down to what each person commits to today. The higher levels change slowly and say little in detail. The lower levels are detailed but only cover the near future, which is exactly where detail can be trusted.

Plan progressively: features, then PBIs, then tasks

The slides also describe progressive planning as three documents, each adding detail to the one above it. This is how a vague idea becomes something a developer can do tomorrow morning, without anyone detailing work that might never be built.

1. The Vision & Scope document names the features.
2. The product backlog holds the product backlog items (PBIs): the what, business value seen from the customer's side. A PBI is a story or an epic, and a story fits in one sprint. Most PBIs are functional, though some are technical.
3. The sprint backlog holds the tasks: the how, the steps that create a PBI's value, each taking no more than one day. Some teams make their PBIs so small that they need no tasks at all.

The idea running through all of this is just-in-time, just-enough planning. Detail is added only when an item is about to be worked on, and only as much as is needed to start. The payoff is that no effort is wasted detailing items that may change or be dropped, and as a side effect the items at the top of the backlog, the high-priority ones, end up being the smallest and best understood.

Planning artefacts and the product backlog exam

Planning produces things you can point at: lists, notes, charts. An artefact is any such product of the process. Knowing which artefact feeds which, and what each one promises, lets you answer "where does this information live?" in a case-study question, and the Scrum Guide's three artefacts and their commitments are a favourite short-answer question.

The chain of planning artefacts

The slides draw planning as a chain. A Project Charter (the short document that authorised the project, see Part I) or a Vision and Scope document feeds the Product Backlog. Some teams in industry seed the backlog in a Sprint 0, a set-up sprint before real development; the Scrum Guide does not include one. Each sprint then draws on the backlog through its own planning notes, sprint backlog and retrospective notes, and the sprint backlogs feed the burndown chart that tracks progress.

Three artefacts, three commitments

The Scrum Guide 2020 defines exactly three artefacts and pairs each with a commitment: a target that gives the artefact its purpose and lets progress be measured against something.

The product backlog

A new backlog is rough. At first most PBIs are too large or too vague to build, so they need refinement (also called grooming): splitting them, adding detail and estimates, and re-ordering. The backlog is re-prioritised before each Sprint Planning, so that the top is always the next most valuable work.

The slides give a backlog template with eight columns. Here it is with the slides' own example row, from a smart-parking app:

Priority can be written either as Low/Medium/High or in MoSCoW (6.6), and the estimate is in story points, SP (6.7). The Dependencies column matters: this story can't be finished until the availability API exists, which constrains how the PO can order it.

Good and bad product backlogs exam

The slides contrast good and bad backlogs on three points. Each "bad" habit is a way the backlog stops being a reliable plan.

The five steps to a product backlog exam

The slides build a backlog in five steps, and sections 6.3 to 6.8 take them in turn. Step through one story card to see what each step adds. The story is the slides' parking example; the acceptance criterion and the DoD lines on it are our illustration of the format.

User stories and epics exam

If requirements aren't written as a full specification, they still need to be written somehow: short enough to change cheaply, but clear enough that everyone knows whose problem is being solved. The user story is agile's answer. It records a need in one sentence from the user's point of view, and leaves the details to be worked out in conversation just before the story is built.

As a [user role], I want to [goal], so that [benefit].

Each slot answers a question. The role says who wants it (here, a registered user, not just anyone). The goal says what they want to do (change the password). The benefit says why (security or convenience), and the why is what lets the PO judge its value and lets developers choose a sensible design.

The 3 C's: card, conversation, confirmation

A story is more than its sentence. Every story has three parts, known as the 3 C's:

1. Card. The story is a brief written statement. It acts as a placeholder for the requirement, not as a specification.
2. Conversation. The Product Owner and the Developers work out the details by talking, just in time.
3. Confirmation. Acceptance criteria and tests confirm that the story is done.

Stories deliberately leave out details. The slides say a story gives "a bone" to start elicitation (finding out the requirements) in the Scrum meetings. And a story focuses on what the user wants to do, not what the user wants the system to do. "As a trainee, I want to see the model in 3D so that I can judge depth as in surgery" is a story; "The system shall use OpenGL quad-buffered stereo at 60 fps" is a design decision dressed up as a requirement (Self-test Q2(d), worked in 6.4).

Levels of detail: epic, feature, story

Requirements come in different sizes, and the slides name three levels. They admit the classification is "contentious" (other sources draw the lines differently) but tell you to use this description in the exam. It runs from the business view at the top down to the developer's view:

An epic is decomposed into features, features into stories, and stories into tasks and subtasks, but only just-in-time and just-enough. As a result, higher-priority items are smaller and better understood than lower ones, and no effort goes into detailing items that may change.

Epics and splitting exam

The slides' example epic is "As a user, I want to log in to the system so that my information can be accessed only by me." It sounds like one thing, but it hides at least six separate pieces of work, each of which can be a story of its own:

Which users? User roles and personas

"As a user…" is a weak start, because users differ in purpose, usage, background and familiarity with computers. A forgetful user needs something different from an administrator. So the slides tell you to broaden beyond "a user".

INVEST: what makes a good story exam

Anyone can write a sentence that starts "As a…". The question is whether the team can plan with it: order it, estimate it, finish it in a sprint and prove it works. INVEST is a six-letter checklist for that. In the exam it is used both ways: "list the INVEST criteria" and "critique this story and fix it".

Each criterion, with the reason behind it:

• Independent. A story should be as independent of other stories as possible, because dependencies make prioritising and planning hard: you can't put B first if it needs A.
• Negotiable. A story is not a contract or a detailed specification but a note to discuss the details near development time. Staying high-level also avoids giving a false impression of precision.
• Valuable. It must be valuable to the user or owner, so only necessary requirements become stories. Technical chores (setting up a server, upgrading a library) are tasks, not stories.
• Estimable. It carries enough information to estimate its size, but it is still not a full specification.
• Small. Small in scope, which is not the same as short in text. The team must be able to finish it within the sprint it starts.
• Testable. It is clear how it will be tested; the acceptance criteria (6.5) supply that.

Negotiable or not? The job-posting example

The slides illustrate "Negotiable" with an HR system story, "pay for a job posting by credit card". The same card can be negotiable or not depending on what is written in its notes.

Worked critique: four bad stories exam

The guide's Self-test Q2 gives four Medic-flavoured stories to critique with INVEST and fix. (Medic, the tutorials' case, is a virtual-reality surgical simulator; see 6.14.) Try each one before opening the tab's answer.

Acceptance criteria and Given/When/Then exam

A story card deliberately leaves out details, so something must pin down what "working" means, or the PO and the Developers will discover at the Sprint Review that they imagined different things. Acceptance criteria do this: they are the "confirmation" C, written on the back of the card before the story is built.

The slides' example is US1: "As a Premier member, I want to cancel my hotel reservations at any time so that I can save on the cancellation penalty." It has three ACs. The second and third share the Given and the When of the first, and differ only in what must happen as a result:

• AC1.1 Given a premier member, When they submit a cancellation, Then the booking is cancelled with no penalty.
• AC1.2 … Then the hotel is notified.
• AC1.3 … Then a confirmation stating that no penalty was charged is sent.

Prioritise with MoSCoW exam

There is never time to build everything, so the backlog has to say what matters most. A plain High/Medium/Low label doesn't tell you what happens if an item is missing. MoSCoW does: each category is defined by the consequence of leaving the item out. It can be applied to a project, an increment or a sprint.

The "Won't" category is easy to undervalue. Writing down what will not be delivered this time stops stakeholders assuming it is coming, and stops the team quietly building it. It isn't "never": it is "not appropriate at this time".

How does the PO decide the order within and across categories? By weighing value against effort. A very valuable item that is cheap to build should come early; a modestly valuable item that is very expensive may become a Could or a Won't. That is why the next step, estimating effort, matters to prioritisation.

Story points and estimation techniques exam

To forecast when anything will be ready, the team needs to know how big each story is. But people are poor at saying "this will take 13.5 hours", especially for work they've never done. They are much better at saying "this is about twice as big as that one". Story points turn that ability into a planning unit.

The scales

Teams pick points from a fixed scale rather than any number. The slides list four scales. In every one, the gaps between values widen as the values grow, which reflects how uncertainty grows with size: there's no point arguing whether a huge story is 40 or 41.

Why story points, not hours?

The slides give four reasons:

Four estimation guidelines

1. Analogy. There are no units, so compare with other stories: stories of the same size get the same points.
2. Decompose. Break a story into tasks and combine what you know about them.
3. Right units. Don't be too fine-grained; use a pattern scale such as 1, 2, 4, 8, 12 or Fibonacci.
4. Group-based. The whole team estimates, using Delphi (anonymous estimates, compared and repeated until they converge) or adaptations of it to reach consensus. Planning poker is one such adaptation.

Two problems at opposite extremes exam

Planning poker exam

Planning poker is the slides' main estimation technique: a quick, game-like version of group (Delphi-style) estimation. Its key trick is that everyone shows their estimate at the same moment, so nobody is swayed by hearing someone else's number first. That swaying is called anchoring. Step through one round; the votes are our illustration.

Besides the estimate itself, planning poker has side benefits: the whole team estimates (so the people doing the work own the number), knowledge spreads across specialities through the explanations, and online tools exist for remote teams.

T-shirt sizing

T-shirt sizing sorts items into sizes from XS to XXL by open discussion, with the occasional vote to break a stalemate. It is informal and fast for many items, which suits a large, early backlog. Its weakness: the sizes must be converted to numbers before you can track effort and chart velocity, because you can't add "M + L".

The bucket system (tutorial)

For a large backlog, the tutorial describes the bucket system. Buckets labelled with point values are set out; a few anchor stories are placed together first, to fix what each bucket means; the remaining stories are divided among the members, who place them silently; and finally there is a sanity-check pass in which anyone can challenge a placement.

Two-pass estimation (tutorial)

The tutorial also suggests estimating a fresh backlog in two passes. First, the team sorts the stories by consensus into four piles: big, medium, small and "no idea: epic". Then it adds cheap story points to each. The guiding rule: defer detailed estimation and decomposition until just-in-time.

The Definition of Done exam

"Is it done?" sounds like a yes/no question, but one developer means "the code compiles", another "it's tested", and the PO "a customer can use it". If the team counts work as finished when it isn't, its velocity lies and the release slips. The Definition of Done (DoD) fixes one shared meaning of "done" for every item.

The DoD has three goals: a shared understanding of quality and completeness; a checklist that every story is checked against; and, as a result, an increment of well-understood, high quality.

The slides' example DoD reads like a checklist:

The slides' "When are tasks done?" diagram makes a further point: every story in every sprint has its own ACs, plus there are additional tasks (deployments, documentation, user manuals). Meeting the ACs alone is not "done".

DoD vs acceptance criteria exam

These two are the most-confused pair in the topic, so set them side by side:

DoD levels: PBI, sprint, release

Some "done" activities can be finished for each item, others only once per sprint or per release. The DoD therefore applies at three levels. To place an activity, ask the slides' questions in order (Scrum Alliance):

A living, auditable checklist

The readings add that the DoD is an auditable checklist and that it is not static: it grows as the team matures. Scrum Inc. lists five mistakes:

1. Having no written DoD.
2. Treating "code complete" as Done.
3. Having different DoDs on one product.
4. Lowering the bar under deadline pressure.
5. Never expanding the DoD.

A weak DoD creates hidden inventory: work that looks finished but isn't, and that will cost time later when someone discovers it was never tested, integrated or documented.

The Definition of Ready

The DoD is the exit gate; the slides also show the matching entry gate, a Jira checklist for the Definition of Ready (DoR). A story is ready to be pulled into a sprint when design specs are provided, it is a small unit of work, its ACs are agreed, and it is testable and estimated.

Sprint planning and the sprint backlog exam

The product backlog says what the product needs; it does not say what the team will do in the next two weeks. Sprint Planning is the event that turns the top of the backlog into a concrete, achievable plan for one sprint, with a single goal that gives the work its purpose. The exam has asked both for the slides' procedure and for the Scrum Guide's three topics, so learn both and how they line up.

The slides' six-step procedure

1. Preparation. Refine the backlog for relevance, completeness and priority.
2. Review the backlog. The PO presents the prioritised stories.
3. Define the Sprint Goal: a clear, achievable objective.
4. Select stories that serve the goal and fit the team's capacity (its velocity).
5. Break stories into tasks. Who does which task is self-organised during the sprint, not assigned at planning.
6. Finalise the sprint backlog. The team agrees its forecast and commits to the Sprint Goal.

The Scrum Guide's three topics exam

The Scrum Guide 2020 frames the same event as three topics, each a question. Slides steps 1–2 are the preparation; step 3 is the Why, step 4 the What, step 5 the How, and step 6 the output. Step through it.

Release planning, briefly

Above sprint planning sits release planning, described in the tutorial's Scrum Master brief: establish the product vision with the stakeholders, estimate the groomed backlog in story points, and determine the velocity. The Scrum Master's job in that session is to make sure everyone contributes and votes, and to build consensus. The arithmetic of a release forecast is in 6.10, and what defines a release in 6.11.

The sprint backlog: stories broken into tasks

The sprint backlog breaks the selected stories down into tasks (the how), each taking ≤ 1 day. Every task has an owner, a status and an estimate, and is tracked daily. The slides' example (Smart Parking, Sprint 1) has these columns; two of its rows are shown:

The "Day 1 … n" columns hold the remaining effort recorded each day, which is exactly the data a burndown chart plots (6.12).

Sprint (task) boards

A sprint board (task board) visualises the sprint backlog. The slides' Jira example has the columns To Do, In Progress, In Review and Done, in that order, with cards showing the ID, estimate, priority and assignee, plus the days remaining. A board gives transparency (anyone can see the state of the sprint) and exposes bottlenecks (a pile of cards stuck in one column), although the Scrum Glossary treats Scrum boards as optional.

Velocity and forecasting delivery exam

Story points tell you how big the work is; they say nothing about when it will be done. To turn size into dates you need to know how much this team actually finishes in a sprint. That measured rate is velocity, and with it a release forecast is a single division. Expect a calculation question.

Four properties matter when you use it:

• It reflects a sustainable pace: what the team can keep doing, not what it manages in a heroic week.
• It is guesswork for the first few sprints, until estimation matures and start-up issues settle.
• It is disrupted by changes in team membership, approach or type of system; that is why a stable team gives accurate estimates.
• Only stories meeting the DoD count. There is no partial credit: a story 90% finished at the end of the sprint contributes 0 to velocity.

The agile estimation process

The slides' process is a loop of four steps: plan with the velocity you expect, then correct the plan with the velocity you get.

Two formulas do all the work:

V = SP / Ti                       T = (SP1 + SP2 + … + SPn) / V

On the left, V is velocity and SP is the points completed over the period T_i, taken from historical data or previous iterations. On the right, SP_i is the points of story i among the n stories in scope, and T is the delivery time, in sprints if V is per sprint.

Worked example: the slides' 400-SP backlog

Re-forecasting with actual velocity: Self-test Q5 exam

The first forecast uses an expected velocity. Step 3 of the process says to measure the real one and re-estimate. The guide's Q5 does exactly that: 6 developers each complete about 1.5 SP per day in 10-day sprints; the backlog is 360 SP. Forecast the delivery. After 3 sprints the team has delivered 70, 80 and 75 SP. Re-forecast.

Timeboxes, scope, increments and releases exam

Plans and reality drift apart: a story turns out easier, another harder, a stakeholder asks for something new. A plan needs a rule for what gives when that happens. Agile's rule is that time is fixed and scope flexes, both inside a sprint and across a release. This section covers that rule, then the increments and releases it produces.

The timebox is fixed; scope flexes

A timebox is a fixed, maximum length of time for an activity. Sprints are typically 2–4 weeks according to the slides; the Scrum Guide says at most one month. The scope of a sprint is planned from priority, story points and velocity, and when reality differs from the plan, the sprint does not get longer: the amount of work changes instead. The slides give options for three situations.

The slides then ask a pointed question: if a change adds three hours of work, who provides that effort? For free? At the cost of family time? Absorbing changes through overtime breaks the sustainable pace that velocity depends on. The Scrum Guide adds two rules: no change may endanger the Sprint Goal, and only the PO can cancel a sprint.

Increments

Releases

A release is a set of increments released to the customer. Releases matter in bigger, multi-release projects; in a small project, the product backlog alone gives enough overview. The slides list the characteristics of a release exam:

• A release is defined by its date, theme and planned feature set, at system or program level, and the PO defines it.
• Scope is the variable, while date and quality are fixed. That is why a prioritised backlog is the basis of planning: when scope must shrink, it shrinks from the bottom.
• All teams keep the same iteration rhythm, so dependencies surface during planning.
• Release dates are fixed across teams, typically every 2–4 months, though this can stretch to 6–9. The same idea, scaled up, is SAFe's Program Increment (Part XI).

Fixed-date vs fixed-scope release planning

The forecasting formula from 6.10 can answer two different questions, depending on which of date and scope you hold fixed. Using the Self-test Q5 numbers after the re-forecast (actual V = 75; 225 of 360 SP done after 3 sprints; original target 4 sprints):

The slides' release characteristics make fixed-date the default: date and quality are fixed, scope is the variable. That only works because the backlog is ordered, so the work that falls outside the capacity is the least valuable work. This is also the guide's verdict on Q5: "either cut Could-haves or move the date".

Burndown and burn-up charts exam

Halfway through a sprint, is the team going to make it? A list of tasks doesn't answer that at a glance; a picture of work remaining over time does. The burndown chart is that picture, and in the exam you may be asked to build one from a table of completions or to read what a shape means.

Building one, day by day

The slides build a burndown for a 400-SP backlog of PBI1–34 (the same backlog as the velocity example: 80 working days, so the ideal burn is 400 / 80 = 5 SP per day). You need only each PBI's effort and status, and you update the status as soon as it changes. The chart starts at Day 0 = 400, and each day follows from the one before:

SP left at end of day X+1  =  SP left at end of day X  −  SP of PBIs completed on day X+1

Track it daily: a sprint-wise burndown (one point per sprint) is not good enough, because by the time it shows a problem the sprint is over. In Sprint 1 the team planned PBI1–11 (49 SP) and completed PBI1–9 and PBI11, which come to 41 SP. Step through it:

Sprint 2, and a slip in the slides

Sprint 2 then completed PBI10 and PBI12–17. The guide flags a caution here: learn the method, not the slide's figure.

Sprint 2 Done:  8 (PBI10) + 5 + 5 + 3 + 13 + 5 + 8 (PBI12–17)
              = 47 SP
Day 20:  359 − 47 = 312     ideal: 400 − 20 × 5 = 300

Reading a burndown exam

Each shape of the actual line has a standard reading. The rule underneath all of them: the line only drops when a story reaches Done, so its shape shows how work is finishing, not how busy people are.

In one of the slides' examples, 250 SP are planned over 25 days, so the ideal is 10 SP per day. The actual line is flat on days 0–2 and 7–9, so the team ran behind early on. By day 15, though, it is at 92 against an ideal of 100, which makes it slightly ahead.

Sprint burndown vs release burndown

Burndowns come at two scales, which differ in what they track, how the x-axis is laid out, and who reads them:

The slides mark the remaining-effort line and the ideal line as compulsory; bars for completed tasks are optional. A burn-up chart turns the picture over: it plots completed work rising towards a scope line (Scrum Glossary). Because scope has its own line, a burn-up shows scope growth separately from progress, which a burndown can only show as a rise. Here is the same release data drawn both ways, one point per sprint:

Reviews, retrospectives and planning pitfalls exam

Planning is only half of the loop; the other half is inspecting the result and adjusting. The Sprint Review adjusts the product plan, and the Sprint Retrospective adjusts the way of working. This section recaps both as they relate to planning (Scrum's events in general are in Part III), then lists the planning pitfalls the slides warn about.

The Sprint Review

At the Sprint Review, according to the Scrum Guide, the team inspects the outcome of the sprint with stakeholders and adapts the product backlog. It is a working session, not just a presentation, and it lasts at most 4 hours for a one-month sprint. The slides suggest demoing with a user journey map, which has 8 elements:

The Sprint Retrospective

At the Sprint Retrospective the team inspects individuals, interactions, processes, tools and the DoD, and improvements may go straight into the next Sprint Backlog. The retrospective ends the sprint and lasts at most 3 hours (for a one-month sprint). The slides' example retro record has four parts:

Common agile planning pitfalls exam

The slides teach the pitfalls through one scenario: a PO, a Scrum Master and 5 developers are adding a recommendation engine to an e-commerce site, with three stories for their first 2-week sprint. Each pitfall comes with a way to avoid it.

Medic: the whole planning process, end to end

Everything in this Part comes together in the tutorials' running case. Seeing one product go from roles to a re-forecast is the best preparation for an "apply it to the case" question, and the numbers here are the guide's own.

Roles, persona and the epic

The user roles are the trainee surgeon and the supervising surgeon (the clients), the haptic and UI liaisons, and RVEEH IT support. A representative persona: "Dr Sam, 2nd-year ENT registrar. General surgery background, never drilled a temporal bone, not a computing expert, wants a minimal UI." (drawn in 6.3).

Feature 5 becomes an epic: "As a trainee surgeon, I want to perform a simulated mastoidectomy so that I can practise drilling without a cadaver." It spans several sprints, so it is split; stories M-05 to M-11 come from this epic, and the other stories from the other features.

The prioritised, estimated backlog

Acceptance criteria for M-07

The facial-nerve warning story (a safety-critical behaviour, since damaging the facial nerve is what a trainee must learn to avoid) gets three Given/When/Then criteria, each with an observable, measurable Then:

• AC7.1 Given a mastoidectomy is in progress, When the drill tip comes within 1 mm of the facial nerve, Then a visual and audible warning appears within 100 ms.
• AC7.2 Given a warning is showing, When the drill moves more than 1 mm away, Then it clears.
• AC7.3 Given the session ends, When the summary is generated, Then each warning is logged with a time stamp.

The Medic Definition of Done

Notice that it covers quality only, with no functionality, as a DoD must:

The release forecast

Musts:    3 + 5 + 8 + 3 + 8 + 13 = 40 SP
Shoulds:  5 + 3 + 5 + 8          = 21 SP
Coulds:   5 + 13                 = 18 SP

Sprints 1–3 (C++/haptics spikes, set-up) delivered 18, 20, 22
V = (18 + 20 + 22) / 3 = 60 / 3 = 20 SP per sprint

Musts only:        40 / 20 = 2 sprints
Musts + Shoulds:   61 / 20 = 3.05  → round up → 4 sprints (8 weeks)

A spike is a short, timeboxed investigation to reduce uncertainty, here learning C++ and the haptics hardware. The conclusion: the release can promise the Musts and Shoulds, and the Could-haves only if velocity rises. The date is fixed and scope is the variable.

Sprint 4 plan

Sprint 4 burndown and re-forecast exam

The sprint is 10 days long, so the ideal burn is 19 / 10 = 1.9 SP per day:

Tutorial 5: critiquing a mock backlog

Tutorial 5 critiques a mock Sprint 1 backlog that was written to win the RVEEH contract. It finds four problems, each a principle from this Part:

Medic exam practice