Module 8 · Agile Business Analysis
Measuring flow and quality
Measure how smoothly work moves through the team with cycle time, throughput, commitment reliability and bug trends, and use the numbers to start improvement, not blame.
About 20 minutes
The problem
Velocity says how much the kiosk app team finishes. It doesn't say how smoothly. Two teams with the same velocity can be very different: one finishes stories steadily through the sprint; the other starts everything on day one and finishes it all in a panic on the last afternoon, with bugs to show for it.
The retrospective after sprint 6 is coming up. The scrum master asks the BA to bring some numbers, so the conversation is about evidence rather than feelings. Which numbers help, and which ones do harm?
The concept
Flow and quality measures
| Measure | Definition | Tells you |
|---|---|---|
| Cycle time | days from started to done, per item | how long work takes once it begins |
| Throughput | items finished per sprint or per week | the team's output, without points |
| Work in progress (WIP) | items started but not done | how much is juggled at once |
| Commitment reliability | points done ÷ points committed, per sprint | how predictable sprint planning is |
| Escaped and found bugs | bugs logged per sprint, and how long they take to fix | quality |
Little's law
For a steady team, average cycle time = average WIP ÷ throughput. Starting more work at once doesn't finish more; it makes everything take longer. That's why many teams set a WIP limit, such as "no more than three stories in progress".
Use measures for learning, never for ranking
These measures describe the system the team works in, not individuals. Compare a team with its own past, never with another team, and never use velocity or cycle time to judge people. The moment numbers are used to blame, people game them: stories get split to inflate throughput, or estimates creep up to inflate velocity.
Example
The kiosk app team's commitment reliability:
| Sprint | Committed | Done | Reliability |
|---|---|---|---|
| 1 | 16 | 16 | 100% |
| 2 | 19 | 17 | 89% |
| 3 | 20 | 20 | 100% |
| 4 | 23 | 21 | 91% |
| 5 | 21 | 18 | ? |
| 6 | 24 | 24 | 100% |
Reliability around 90% is healthy: a team that always hits 100% is probably committing too little. But read it alongside the bugs. Sprint 6 hit 100% while logging 5 bugs, so the team may be finishing stories by passing problems on.
Walkthrough
- Calculate cycle time for every Done story, then the average (the first task below).
- Calculate commitment reliability for each sprint, using
committed_pointsfromsprints.csv. - Count bugs per sprint, and their average cycle time. Are bugs taking longer to fix than stories take to build?
- Prepare three observations for the retrospective, each with a number, a possible cause and a question for the team (the task below).
Practice
Practice
What is the average cycle time in days (done_date − started_date) for Done stories? One decimal place.
Practice
What was sprint 5's commitment reliability (points done ÷ points committed)? One decimal place.
Practice
What is the average cycle time in days for Done bugs? One decimal place.
Task
8 minWrite three observations for the sprint 6 retrospective, one per line. Each should give a number from the data, a possible cause, and end with a question for the team. Don't name or blame individuals.
Your work is checked for
- Three observations, each a line ending with a question mark
- Each includes a number
- Suggests causes (because, possibly, may, might, could)
- No blame words (fault, lazy, blame, careless)
Check your understanding
Answer every question to check.