Mike Cohn is quite explicit when he says story points reflect the effort required to get a Story to “Done”:
In a class a few years back, I was given a wonderful example of this. Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery — snip and done. These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example. Despite their vastly different complexities, the two items should be given the same number of story points — each is expected to take the same amount of time.
– Mike Cohn
Mike also reminds us to estimate size and derive time.
Plotting Size versus Cycle Time
What we end up with is a range of Stories or Product Backlog Items of varying sizes that then reflect the average time taken for an item to go from “in-progress” to “Done”.
If we plot size by time, we also get a picture of the size by its range of times.
The range of times around the average is called the variance. With both average and variance we can understand:
- Are our estimations accurate?
- Are we differentiating enough between our size categories?
- Are we sizing in a consistent way?
A graph of size and variance also helps a team inform customers when an item is likely to be done once we start.
The Product Owner asks Team Avatar to deliver a new search feature. The Team look at their historical data and note that last time they delivered something to do with search they classified it as a “L”.
“L” size items currently take Team Avatar 7 days on average to complete, but they could finish it as early as 5 days or as late as 9 days.
Using Cycle Time, Sequencing and Predicting Impediments
Estimating size and deriving time also has the advantage of helping a Scrum Team to sequence its work. In the current example, an “L” sized item could start no later than day 2 in the Sprint if the team wants to guarantee that it will finish by the end of the Sprint as it could take them up to 9 days to complete.
Furthermore, if a “L” takes the team 7 days on average to get to “Done”, the Scrum Master should know by day 7 whether he feels the team is on track or whether there’s some impediment slowing the team down (whether the team realise it or not).
Looking at Cycle Time in the Retrospective
Cycle time data is vital in a Retrospective.
The team ends up sizing the search item as a “S”, but it ends up taking 6 days of cycle time to complete. During the Sprint, they found some tricky problems, did a work around, and delivered it by the end of the Sprint.
When the team looks at its baseline, they see that “L” stories have 7 days +/- 2 days cycle time. The team discuss the data and agree that the story should have been a “L”.
The team now know that when they are asked to deliver something similar in the future, if they think the story is likely to contain a similar problem, then the story is not a “S” but more likely to be a “L”.
Clustering items on a wall by their cycle time is a useful way of looking for patterns amongst stories and their sizes. I did this recently with one of the teams I was coaching and found that while they had a wide range of sizes for different kinds of work. In the end, we found that there was no real difference in cycle time between “XXS”, “XS”, “S” or even “M” sized stories.
What the stories had in common, though, was that they were a certain type of electronic form that the team worked on with a specific tool. We also determined that there were two clusters of work: one that involved updates and the one that involved brand new forms.
Based on the clusters, updates took 1-2 days, while new forms took 4-5 days. The Scrum Master and team agreed to call the updates “S” and the new forms “M”. They then used this as their baseline for their relative sizing/estimation sessions.
With another team, when we plotted size by cycle time, we found that there was significant overlap between “S” and “M” stories.
The team were not making enough differentiation between the two sizes. Some stories that were “S” could have been “M”.
I always track cycle time when I’m coaching a team (whether they realise it or not). It’s as simple as putting a “dot” on the card on the team’s Kanban Board when they come to their Daily Scrum. I don’t find anything more precise than counting days worth the effort.
Cycle time helps me to understand the flow of work for different types of stories and this helps my the teams I coach to improve their sizing and make it more consistent and accurate. It’s not something the Scrum Guide tells you to do, but I find it’s one of my most useful tools to help improve an agile team’s performance.