Question bank — Agile — Scrum (sprints, roles, ceremonies), Kanban

False. The SM has no authority to assign work — the Developers self-organize and the PO owns priorities. The SM's only levers are influence and removing impediments.

False. Velocity is a measured, empirical average, not a target. Chasing an ever-rising number invites point inflation (bigger estimates, same real output).

Cancelled — yes (rarely, if the Sprint Goal becomes obsolete); shortened — no. Sprint length is fixed for the sprint; only the PO can cancel a sprint, and it's a heavy, uncommon move.

False. Its one strict rule is the WIP limit. Drop that and you have an unlimited to-do list, and Little's Law then predicts lead time $W$ growing without bound.

False — not if WIP $L$ rises with it. $W=L/\lambda$: if you speed up but also pull in proportionally more work, $L$ grows and $W$ can stay the same. Kanban instead caps $L$.

True. Anything not meeting the Definition of Done (tested, reviewed, integrated) is not part of the Increment — it stays "in progress", however close it looks.

False. Review inspects the visible product with stakeholders; Retro inspects the team's own process, internally. Different audience, different subject.

False. Story points are relative to each team's own scale, so cross-team velocity comparison is meaningless — 40 of A's points may be less real work than 25 of B's.

False. Above the ideal means more work remains than the constant-rate baseline expects — the team is behind, not ahead.

False. "Scrumban" hybrids exist — teams run Scrum ceremonies while adding WIP limits to their board. The methods target the same enemy (big unverified batches) from different angles.

Two errors: the Daily Scrum is for the Developers to re-plan among themselves, and nobody "hands out" tasks — the team self-organizes. The PO owns what/why, not who does what.

You must take the ceiling: $\lceil 12.5\rceil =13$. You can't finish the leftover 10 points in half a sprint, so it consumes a whole extra sprint.

Nothing is automatic — lead time obeys $W=L/\lambda$. Continuous flow without a WIP limit gives a growing $L$ and therefore a longer $W$.

Backwards. Remaining work should fall to zero: $R(d)=W\left(1-\frac{d}{D}\right)$. At $d=0$ all $W$ remains; at $d=D$ it's zero.

The Manifesto says prefer working software over comprehensive docs and responding to change over following a plan — it's a preference of the left, not ignoring the right.

The mean is a forecast, not a guarantee. It smooths noise but any single sprint can land above or below it — that variability is exactly why we average.

Humans are poor at absolute time but decent at relative size ("twice that"). Points capture relative effort/complexity and let velocity emerge empirically instead of being negotiated.

Each past sprint is one noisy sample of throughput; averaging cancels random highs and lows to give a single unbiased "typical output" number.

In $W=L/\lambda$, throughput is hard to force (it depends on real capacity), but $L$ is a knob you can directly turn down. Lowering $L$ cuts waiting and context-switching, so items reach Done faster.

It inspects how the team works together — candour about its own process needs psychological safety, which outside stakeholders would chill.

A stable goal keeps the team pointed at one shared outcome; letting them swap which items deliver that goal preserves flexibility without losing direction.

The derivation assumes arrival rate equals departure rate (steady state). If work pours in faster than it leaves, $L$ keeps growing and no single average $W$ describes the system.

Undefined; there's no data to average. Teams guess a first-sprint capacity, then let real velocity emerge over the next few sprints before forecasting.

$\lceil 240/20\rceil =\lceil 12\rceil =12$. It divides evenly, so the ceiling changes nothing — the ceiling only bites when there's a remainder.

$W=L/\lambda$ divides by zero → lead time is effectively infinite. Nothing completing means items sit forever; the formula flags a fully stalled flow.

It minimizes lead time per item but can starve people, leaving idle capacity when one card blocks. The healthy limit balances flow against utilization; extreme limits are as harmful as none.

The accountabilities still exist even if one person wears all hats, but the value of Scrum (cross-functional collaboration, separation of what/how) largely collapses — it's a sign Scrum may be the wrong tool.

No. Velocity counts only points completed to the Definition of Done. Partial work carries nothing; it returns to the backlog for a future sprint.