Exercises — Agile — Scrum (sprints, roles, ceremonies), Kanban

• (a) → Product Owner (owns the what and why; the single voice for priorities).
• (b) → Scrum Master (servant-leader; influence + impediment removal, no authority to assign work).
• (c) → Developers (self-organizing; they decide how much and how).

Why this mapping: the three accountabilities split cleanly into what (PO), process (SM), how-built (Devs). If a duty smells like "priority", it's PO; "team health", it's SM; "the building", it's Devs.

• Sprint Review → inspects the product (demo the increment to stakeholders).
• Sprint Retrospective → inspects the process (team reflects on how it worked).
• Daily Standup → inspects progress toward the sprint goal — it re-plans the day and surfaces blockers. (It touches process, but its target is the plan, not a formal retro.)

Mnemonic: Review = visible product; Retro = team.

(iii) the WIP limit. Kanban prescribes no sprints, no roles, no time-boxes — its entire discipline is the cap on how many items may sit in a column at once. Options (i), (ii), (iv) all belong to Scrum.

What: average the four sprint outputs. Why the mean: each sprint is one noisy sample of throughput; the mean cancels random highs and lows to give one forecast number. $\bar{v}=\frac{14+18+16+20}{4}=\frac{68}{4}=17\text{ points/sprint}$

What: divide backlog by velocity, then round up. $\text{sprints}=\lceil \frac{B}{\bar{v}}\rceil =\lceil \frac{200}{17}\rceil =\lceil 11.76\dots \rceil =12$ Why ceiling: $11.76$ sprints is impossible — the leftover $\approx 13$ points still needs a whole sprint to finish. You cannot ship in a fractional sprint.

What: rearrange $L=\lambda W$ into $W=L/\lambda$. Why this rearrangement: we know how many items are stuck inside ($L$) and how fast they leave ($\lambda$); the time each one waits is the stock divided by the drain rate. $W=\frac{L}{\lambda }=\frac{12}{4}=3\text{ weeks}$ Each new card must wait behind 12 others draining out at 4/week — so it takes about 3 weeks to reach Done.

Before: $W=20/5=4$ weeks. After: $W=10/5=2$ weeks. Lead time halves (factor of 2). Why it drops with no extra speed: Little's Law says $W=L/\lambda$. Throughput $\lambda$ (the drain rate) is unchanged, but each card now queues behind 10 rivals instead of 20. Less time waiting in line = shorter total time inside. Look at the figure: same water leaving the tank per week, but the tank holds half as much, so it empties any given card twice as fast. Same throughput, shorter wait — this is the whole reason WIP limits speed delivery.

What: the ideal line falls linearly: $R(d)=W_{\text{tot}}\left(1-\frac{d}{D}\right)$. $R(5)=40\left(1-\frac{5}{10}\right)=40\times 0.5=20\text{ points ideal remaining}$ Real remaining is 26, which is above the ideal 20. They are behind by $26-20=6$ points. Why "above = behind": the ideal line is the baseline of constant work rate $W_{\text{tot}}/D=4$ points/day. If more work is still left than the baseline predicts, the team has burned points slower than planned. In the figure, the real curve sits over the straight ideal line — the vertical gap is the 6-point shortfall.

Meaningless. Story points are relative to each team's own scale. Team B simply uses bigger numbers for the same work, so "30 points/sprint" means less actual output for B than for A. You cannot compare velocities across teams — the unit isn't shared. What velocity is good for: forecasting that one team's future using its own past. It is a planning tool, not a cross-team performance score.

(a) Velocity: $\bar{v}=(22+26+24)/3=72/3=24$ points/sprint. Sprints: $\lceil 300/24\rceil =\lceil 12.5\rceil =13$ sprints. (b) At 2 weeks/sprint: $13\times 2=26$ weeks. (c) New sprints: $\lceil 300/30\rceil =\lceil 10\rceil =10$ sprints $\Rightarrow 10\times 2=20$ weeks. Why the ceiling twice: both $12.5$ and the general case need a whole sprint for any remainder. Caveat (honesty): velocity rarely rises proportionally when you add people — onboarding and communication overhead often eat the gain. The 30 here is an assumed sustained figure, not a guarantee.

What: solve Little's Law forward for $L$: $L=\lambda W$. Why forward this time: we want a target $W$ and know $\lambda$; the unknown is the stock $L$ we're allowed to hold. $L=\lambda W=6\times 2=12\text{ cards}$ Set the board's total WIP limit to 12. Holding more than 12 in progress would (by $W=L/\lambda$) push lead time above the 2-week goal.

Kanban. Its defining property is change is allowed anytime — work is pulled continuously rather than committed for a fixed time-box. Scrum deliberately fixes the sprint goal to protect focus; a stakeholder who rewrites priorities every few days breaks that contract. Kanban's continuous flow + WIP limit absorbs volatile priorities without the "abandon the sprint" cost. (See the parent note's Scrum-vs-Kanban table: Change mid-cycle → Scrum: avoided; Kanban: anytime.)

(a) $W=L/\lambda =24/3=8$ weeks average lead time. Brutal — that's the "90% done forever" symptom quantified. (b) To halve $W$ to 4 weeks with $\lambda$ fixed at 3, solve $L=\lambda W=3\times 4=12$. Set WIP limit = 12. Check: $W=12/3=4$ weeks. ✓ (c) The mechanism: throughput $\lambda$ is the rate cards leave Done, and it doesn't fall when we cap WIP — the same people still finish work at the same pace. What changes is the queue: each card now waits behind 12 rivals instead of 24, so by $W=L/\lambda$ it exits in half the time. "Idle" is a misread — when a worker can't start a new card, the rule is to help finish an in-progress one (swarm), which pushes cards out faster, not slower. Starting less ⇒ finishing more. The traffic-jam analogy: fewer cars on the road means every car arrives sooner, even though the road's exit rate is unchanged.

A defensible Scrumban design:

• Keep from Scrum: a fixed cadence (e.g. 2-week review + retro). Why: the regular Sprint Review gives a predictable feedback drum-beat (feedback frequency ≫ planning accuracy), and a stable cadence lets velocity ($\bar{v}$) forecast release dates — you get predictability.
• Keep from Kanban: a WIP limit on the board and pull-based, reprioritizable work instead of a locked sprint backlog. Why: the WIP limit governs lead time by Little's Law ($W=L/\lambda$) so cards still flow fast, and pull-on-demand lets priorities change without abandoning a committed sprint goal.
• Drop: the rigid "sprint goal is frozen" rule (it fights reprioritization) — replace with "backlog reordered anytime, but WIP-limited." The defense in one line: cadence buys predictability (velocity forecasts), WIP limits buy speed (Little's Law), and pull buys responsiveness (change anytime) — each choice traces to a named principle, none to taste.

Velocity is computed by taking the ::: mean (average) of points completed over recent sprints. Backlog-to-sprints rounding always uses the ::: ceiling (round up), because a remainder needs a whole sprint. Little's Law states ::: $L=\lambda W$. To cut lead time without raising throughput, you ::: lower WIP (L). Review inspects the ::: product; Retrospective inspects the ::: process.