Using Cycle Time and Story Points to Improve as a Team Posted on January 24, 2014 by Cory Foy 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.