This page does one job: take the three "engines" of Agile math — velocity forecasting (Scrum), Little's Law (Kanban), and the burndown line (Scrum's progress ruler) — and run them through every case they can throw at you . Nice clean numbers, ugly fractions, zeros, degenerate teams, real-world word problems, and one exam trap. If a scenario exists, it's below.
If any word here feels unfamiliar, that's fine — we rebuild every idea from zero as we hit it. Parent: Agile — Scrum & Kanban .
Intuition The three machines we are stress-testing
Machine 1 — Velocity forecast. You know how fast a team burns story points (a made-up unit of "size of a task"). You want: how many sprints to finish a pile of work? See Project Estimation & Story Points .
Machine 2 — Little's Law. You know how many cards are stuck on a board and how fast they leave. You want: how long does one card wait? See Little's Law .
Machine 3 — Burndown line. You know how much work a sprint started with and how long it lasts. You want: is the team ahead or behind today ? It's a straight-line ruler you compare reality against.
All three are one-line formulas. The whole skill is knowing which numbers to plug and how to round — and that's exactly what breaks in the edge cases.
Before working anything, let's list every kind of case these formulas produce. A "case class" is a situation where the behaviour of the formula changes — a new sign, a rounding jump, a division that misbehaves, or a word-problem wrapping.
#
Case class
What's special about it
Which example
C1
Velocity, clean divide
backlog ÷ velocity is a whole number → no rounding
Ex 1
C2
Velocity, fractional divide
leftover points → ceiling jumps up
Ex 2
C3
Velocity, noisy data
one outlier sprint → why the mean smooths it
Ex 3
C4
Velocity, degenerate
a zero-point sprint (team blocked) in the average
Ex 4
C5
Little's Law, solve for W
given L , λ → find wait time
Ex 5
C6
Little's Law, WIP cut
lower L , same λ → shorter W (the core Kanban claim)
Ex 6
C7
Little's Law, limiting case
L → 0 and λ → 0 → what "empty board" means
Ex 7
C8
Word problem, mixed units
rate given per day , answer wanted in weeks → unit conversion
Ex 8
C9
Exam twist
a subtle "which lever?" question that punishes plug-and-chug
Ex 9
C10
Burndown line
reading "ahead/behind" off the ideal line, all day-values
Ex 10 (figure)
Every row is covered below. Let's go.
Past sprints completed 22 , 18 , 20 points. Backlog B = 240 points. How many sprints to finish?
Forecast (guess first): roughly 240/20 = 12 . Will rounding change it? Guess before reading.
Step 1 — average the three sprints. v ˉ = ( 22 + 18 + 20 ) /3 = 60/3 = 20 .
Why this step? We need one "typical speed" number; the mean is the balance point of the samples.
Step 2 — divide backlog by speed. 240/20 = 12.0 exactly.
Why this step? "amount ÷ rate = time" — the same logic as "distance ÷ speed = hours".
Step 3 — apply the ceiling. ⌈ 12.0 ⌉ = 12 .
Why this step? Ceiling only changes a number that has a fractional part. 12.0 has none, so nothing moves.
Answer: 12 sprints.
Verify: 12 × 20 = 240 points of capacity, exactly the backlog. No waste, no shortfall. ✓
Same team, v ˉ = 20 , but the backlog grew to B = 250 points.
Forecast: 250/20 = 12.5 — but you can't do half a sprint. So…?
Step 1 — divide. 250/20 = 12.5 .
Why? Same rate logic as before.
Step 2 — ceiling. ⌈ 12.5 ⌉ = 13 .
Why this step? After 12 sprints you've done 12 × 20 = 240 points; 10 points remain . Those 10 points still need a whole sprint (you schedule a sprint, not a fraction of one). Hence round up .
Answer: 13 sprints.
Verify: 12 sprints → 240 done, 10 left (>0, so not finished). 13 sprints → capacity 260 ≥ 250 . The smallest whole number that covers 250 is 13. ✓
Common mistake Rounding to the
nearest instead of up
12.5 "rounds to nearest" as 12 or 13 depending on convention — but forecasting is never "nearest". Any remainder, even 1 point, forces a full extra sprint. Always ceiling, never round-half.
Sprints completed 10 , 30 , 20 , 20 . Backlog B = 200 . Notice sprint 2 (=30) is an outlier.
Forecast: does the big 30 make us finish faster? Guess.
Step 1 — average all four. v ˉ = ( 10 + 30 + 20 + 20 ) /4 = 80/4 = 20 .
Why this step? The high 30 and the low 10 are both noise — a lucky week and an unlucky week. Averaging cancels them (+ 10 above, − 10 below the middle), leaving the honest typical speed of 20.
Step 2 — forecast. 200/20 = 10.0 , ⌈ 10.0 ⌉ = 10 .
Why? Clean divide, ceiling does nothing.
Answer: 10 sprints.
Verify: if you had only trusted the best sprint (30), you'd predict ⌈ 200/30 ⌉ = 7 sprints — and then miss the deadline badly, because you can't sustain 30. The mean protects you. Check: 10 × 20 = 200 ✓.
The team was blocked by an outage one sprint: completions were 24 , 0 , 21 , 15 . Backlog B = 180 .
Forecast: does the zero sprint break the average? Should we drop it?
Step 1 — keep the zero, it's real data. v ˉ = ( 24 + 0 + 21 + 15 ) /4 = 60/4 = 15 .
Why this step? Outages happen; a forecast should include the risk that they happen again. Deleting the 0 would over-promise. The mean of 15 already "prices in" the bad sprint.
Step 2 — forecast. 180/15 = 12.0 , ⌈ 12.0 ⌉ = 12 .
Why this step? We turn the smoothed speed into a sprint count exactly as before — "backlog ÷ velocity, then ceiling". Here 180/15 lands on a whole number, so the ceiling leaves it at 12.
Answer: 12 sprints.
Verify: 12 × 15 = 180 ✓. Sanity on the degenerate value: v ˉ = 15 > 0 , so the division is safe. (The truly broken case would be v ˉ = 0 — every sprint scored 0 — which means the forecast is undefined / infinite : a team that completes nothing never finishes. The formula honestly refuses to divide by zero, which is the correct answer: "never".)
Common mistake The letter
W means two different things on this page
In Machine 2 (Little's Law) W = lead time (how long a card waits). In Machine 3 (burndown, further down) W = total work in a sprint , measured in story points. Same letter, unrelated quantities — a classic textbook clash. Watch the section header to know which W is live; here in Kanban, W is always a time .
A board completes λ = 5 cards/week and holds L = 15 cards. What's the average lead time W ?
Forecast: each card is "in a queue of 15" leaving at 5/week — so a few weeks?
Step 1 — pick the rearranged form. We want W , and we know L , λ , so use W = L / λ .
Why this step? Always solve for the unknown by isolating it — divide both sides of L = λW by λ .
Step 2 — plug in. W = 15/5 = 3 weeks.
Why? Units check: cards/week cards = weeks . Cards cancel; weeks survive. ✓
Answer: 3 weeks average lead time.
Verify: run it forward — L = λW = 5 × 3 = 15 cards. Matches the given L . ✓
Same board, λ = 5 cards/week. You impose a WIP limit so only L = 10 cards may be in progress. New lead time?
Forecast: fewer cards on the board — does each finish sooner even though the team's speed (5/week) didn't change? Guess yes/no.
Step 1 — recompute W . W = 10/5 = 2 weeks.
Why this step? Only L changed; λ stayed 5. So we just re-divide.
Step 2 — interpret. Lead time dropped from 3 weeks to 2 weeks — a 1/3 cut — with the same throughput .
Why does capping WIP speed things up? A card no longer waits behind 14 others; it waits behind 9. Less queueing = shorter total stay. This is the reason Kanban enforces WIP limits.
Answer: 2 weeks (down from 3).
Verify: forward check L = 5 × 2 = 10 ✓. And note throughput unchanged: still 5/week both times — we made delivery faster without working faster. ✓
Two extremes on a Kanban board:
(a) The board is empty : L = 0 , λ = 5 .
(b) The team is fully blocked : λ = 0 , L = 8 .
What does W do in each?
Case (a) — empty board. W = 0/5 = 0 weeks.
Why this makes sense: no cards means no card is waiting — average wait is 0. The formula behaves gracefully at zero WIP.
Case (b) — zero throughput. W = 8/0 = undefined (→ ∞) .
Why this makes sense: if nothing ever leaves (λ = 0 ), a card on the board waits forever . Division by zero is the maths correctly screaming "infinite lead time". This is the mirror of Ex 4's zero-velocity team: a system that never delivers has no finite answer.
Answer: (a) W = 0 ; (b) W infinite/undefined.
Verify: (a) forward: L = λW = 5 × 0 = 0 ✓. (b) there's no finite W with L = λW ⇒ 8 = 0 ⋅ W = 0 , which is impossible — confirming no finite lead time exists. ✓
"Our support team clears 2 tickets per day . On average 28 tickets are open. How long, in weeks , does a customer wait for a reply?" (Assume 7-day weeks, steady flow.)
Forecast: a couple of weeks?
Step 1 — identify the symbols. L = 28 tickets, λ = 2 tickets/day, want W .
Why this step? "open tickets" = WIP = L ; "clear per day" = throughput = λ .
Step 2 — solve in the given units first. W = L / λ = 28/2 = 14 days.
Why? Keep units consistent: tickets ÷ (tickets/day) = days . Don't convert mid-formula.
Step 3 — convert to the asked unit. 14 days ÷ 7 = 2 weeks.
Why this step? The question asked for weeks; convert only at the end to avoid errors.
Answer: 2 weeks.
Verify: forward in days — L = λW = 2 × 14 = 28 tickets ✓. Unit chain: days → weeks, 14/7 = 2 ✓.
A manager says: "Lead time is 4 weeks; I want it halved to 2 weeks. Just tell the team to work twice as fast." The board has L = 20 , λ = 5 /week. Is doubling throughput the only way? What's the cheaper lever?
Forecast: the parent note hinted throughput is "hard to force". So what else can move W ?
Step 1 — confirm current W . W = 20/5 = 4 weeks. ✓ matches the manager.
Step 2 — write W in terms of both levers. W = L / λ . To halve W , you may either halve L or double λ — the ratio is what matters.
Why this step? W depends on the ratio L / λ , not on either alone. Two knobs, same effect.
Step 3 — the cheap lever: halve L . Set WIP limit L = 10 (same λ = 5 ): W = 10/5 = 2 weeks.
Why cheaper? Cutting WIP is a policy (a number on the board) — free and instant. "Work twice as fast" means doubling λ to 10/week — hiring or heroics, expensive and often impossible.
Answer: No, doubling throughput isn't the only way. Halving WIP (L : 20 → 10 ) halves lead time to 2 weeks for free — the Kanban lever.
Verify: cheap path forward: L = λW = 5 × 2 = 10 ✓. Expensive path forward: λ = 10 , L = 20 ⇒ W = 20/10 = 2 ✓. Both reach 2 weeks; only one is free. This is the trap: plug-and-chug on λ misses the WIP lever.
Sprint: W = 40 points, D = 10 days. Compute the ideal remaining at d = 0 , 5 , 10 . On day 5 the team actually has 25 points left. Ahead or behind?
Forecast: ideal at the midpoint should be half done — so 20 left. Real is 25. Which side?
Step 1 — endpoints. R ( 0 ) = 40 ( 1 − 0 ) = 40 ; R ( 10 ) = 40 ( 1 − 1 ) = 0 .
Why this step? Sanity check the line: it must start full (40, nothing done) and end empty (0, all done). In the figure, the black straight line runs from the top-left corner (day 0, 40 points) down to the bottom-right (day 10, 0 points) — that diagonal is the ideal.
Step 2 — midpoint. R ( 5 ) = 40 ( 1 − 10 5 ) = 40 × 0.5 = 20 points.
Why this step? The ideal is the reference; we need its exact value where we'll compare — halfway through, so we expect half the work gone. The black line passes through ( 5 , 20 ) , marked on the figure.
Step 3 — compare to reality. Actual = 25 , ideal = 20 . Since 25 > 20 , the red actual line sits above the black ideal at day 5.
Why "above = behind"? Above means more work remaining than planned → you're behind schedule. (Below the line = ahead.) In the figure, look at the red actual line poking above the black ideal at day 5, and the red double-arrow marking the "gap = 5" between them — that vertical gap is exactly how many points behind you are.
Answer: behind by 25 − 20 = 5 points at day 5.
How to read the whole figure: any day the red line is above black → behind; on black → exactly on plan; below black → ahead. The steeper the red drops, the faster the team is burning work.
Verify: slope of ideal = − W / D = − 40/10 = − 4 pts/day, so from 40 it should read 40 − 4 × 5 = 20 ✓ (matches Step 2). Gap = 5 points behind ✓.
Recall Self-test (reveal after guessing)
Backlog 250, velocity 20 → sprints ::: ⌈ 12.5 ⌉ = 13
Board L = 15 , λ = 5 /wk → lead time W ::: 15/5 = 3 weeks
Cut WIP to L = 10 (same λ = 5 ) → new W ::: 10/5 = 2 weeks
Zero-throughput board (λ = 0 ) → W ::: undefined / infinite (nothing ever leaves)
Ideal burndown at day 5 of a 40-pt / 10-day sprint ::: 40 ( 1 − 5/10 ) = 20 points
To halve lead time for free, which lever? ::: halve WIP L (throughput is expensive to raise)
Mnemonic The two one-liners
Scrum forecast: "pile over pace, round up" → ⌈ B / v ˉ ⌉ .
Kanban wait: "stock over flow" → W = L / λ .
Related: Little's Law · Project Estimation & Story Points · Continuous Integration & Delivery (CI-CD) · Lean Manufacturing · parent topic