It’s Friday afternoon. Team Plaidpants is finishing up their sprint, but trying to understand why they struggled so much to complete their stories. “It really seemed like we had the stars aligned this time, ” said Yvonne, “but somehow those two bugs got in the way. And I have no idea why this story took so long to finish!” The team nodded their head in agreement.
Sarah, the team’s ScrumMaster, got an idea. “Hey team, I’ve read a lot on both Scrum and the principles of Lean. We’re good at story points, but bad at making our commitments. Maybe we can find a way to measure something else about the stories to see what our patterns are.”
The team agreed to spend the next three weeks measuring the Cycle Time of a story – when work started on it, until it was delivered. They also tracked how many times a story was delayed, and if it failed a test or otherwise have to have rework done on it. At the end of the third sprint, Sarah brought the team together.
“Thanks everyone for tracking these stories. I think there’s some interesting data in here that might just help us.” Sarah fired up her laptop and projector, and showed the following table on the wall:
| Estimate | Cycle Time | Rework Count | # Delays |
| 0 | 1 day | 0.3 | 0 |
| 1 | 4.1 days | 0.5 | 2 |
| 2 | 1.7 days | 3 | 0 |
| 3 | 2.6 days | 1 | 1 |
| 5 | 3.4 days | 0.4 | 3 |
| 8 | 4.7 days | 5 | 4 |
Sarah explained the data. “This table shows the estimates of each of our stories, as well as an average of how long it took us to actually complete the story once we started work on it. It also shows the average number of times we had rework, and the average times a story was delayed.”
John, a lead developer on the team, was confused. “Sarah, you are saying that a one point story actually took longer than a 2, 3 or 5 point story? Are you sure that data is correct? And we had an average of 5 cases of rework for an 8 point story?” Sarah replied, “Yes, John, that’s right. And I think it highlights that while we can get better about getting our smaller stories to acceptance instead of waiting until the end of the sprint, we really need to be concerned about the 8 point stories, becuase it seems like we just don’t know enough about them going into the sprints, which cause more issues than it’s worth.”
The team agreed that for the next three sprints, they wouldn’t allow any 8 point stories into their sprints until they had been split, and that they would drive 1 point stories to completion as soon as they were ready, instead of batching them up at the end of the sprint. They suddenly found themselves hitting their commitments much more consistantly, and found less surprises during the sprint.
Too often, teams focus on the commitment aspect of story points – “Did we hit our number? Where is our velocity at?” instead of focusing on the flow of work itself. But as Team Plaidpants found, sometimes focusing on the flow can lead to better delivery – and a happer, plaid covered team.
Nice article. One question — what is the units of Rework Count in the spreadsheet? What does it mean to have a fractional value for Rework Count – is it a time value, or is it count of how many times you had to rework the story before it was completed?
Hi John,
The numbers in the table are averages of all of the stories they completed. The rework number would be how many times a story flowed backwards through the team’s value stream. For example, assume they had a column for “ready to test” which had a policy that the code had to be on a test server before it could move forward, but when someone went to test it, found that not all of the code had been pushed up. That would be one instance of rework.
The tricky part of those kinds of measurements is getting the team’s to really think about what their process is, and setting it up in a way that it is used by the team for improvement and flow discussions, and not as a stick to make everyone conform to one specific way of working.
Excellent post on the ever-present challenge of story cycle time. Splitting larger stories is one of the few effective solutions to improving estimate accuracy and reliable completion of stories.