Agile Teams tend to use relative estimation rather than creating tasks, estimating hours, and then adding up all the hours. Adding up hours it fundamentally flawed. Relative estimation tends to be much more accurate as teams are instead attempting to compare new work with previous work.
Agile Teams will ask questions like:
- Which item is this new item equivalent to in terms of previous work?
- Is it bigger or smaller than previous work we’ve done from the perspective of effort and cycle time?
Agile Teams therefore estimate size and derive time.
Many Agile Teams, though, don’t have any exemplar Stories to do relative estimation. So, when I’m doing agile coaching, here are some techniques that I use.
Anchoring around the smallest Story
I ask the Agile Team to write up their Stories on cards or post-it notes and place them randomly on the table.
Next, I’ll ask the Product Owner of the team to read through the Stories and the Scrum Master facilitate a discussion as to the scope boundaries, complexity, risk, unknowns, and all of the usual things we might talk about at Sprint Planning.
I then ask the team to take out their Planning Poker cards and the “S” card (or a “2” if the team is using Fibonacci).
I’ll then count down from three and ask the team members (at the same time) to thrown down their “S” on the Story they feel is the smallest compared to all of the Stories on the table.
I’ll then ask the Scrum Master facilitate a discussion around differences of opinion as to which Story is the smallest, and repeat the pattern until there’s consensus.
Next, I’ll give the Development Team a 2-minute timebox in which to sort the cards into a ranked order from the smallest (the Story they’ve just chosen) to the largest. For Stories that are of equivalent size, these are placed side-by-side.
I’ll then place t-shirt sizes beside each of the Stories to reflect the progression of size from smallest to largest. Then I’ll ask for a Roman Vote to understand if the Development Team feels the order and the sizes best reflects orders of magnitude for the Stories. If not, I’ll then give the Development Team another 2-minute timebox to rearrange the Stories in much the same way as they would using a relative estimation matrix.
Once we’ve got consensus as to the size of the Stories, I’ll ask the Scrum Master to start recording cycle time so that we can assess our accuracy with those sizes in the Retrospective.
I’ll use a “S” or “2” as that’ll give the Development Team some room to still go lower if, after sorting their list, they feel there is in fact, a Story that should be smaller (i.e. a “1” or “XS” than the anchor point.
Anchoring around the largest Story
Anchoring size and estimation around the largest Story is pretty much the same as anchoring around the smallest Story (above). This time, the Development Team will take out a “L” (or “13” if they’re using Fibonacci), come to consensus, and then order the Stories from largest to smallest.
Gaps in sizes
Sometimes, as I lay out the sequence of sizes, the Development Team won’t put anything against specific size categories — and that’s ok. Without a baseline to compare new Stories against previous Stories, there’s no way to really be sure of the true difference in cycle time between each of the size categories until we reach the end of the Sprint and conduct a Retrospective with cycle time data.
Recording Cycle Time during the Sprint
Once the Development Team have agreed on their sizes for each Story, I’ll ask the Scrum Master to “dot” each Story for each day it spends “in-progress”. The easiest way to do this is to do it at the Daily Scrum. This is a record of its cycle time and should include both effort days as well as waiting days or days the Story is “blocked”.
Just differentiate between the two status by using two different coloured sharpies. I use red for blocked/parked and black for each day “in-progress”.
Assessing Story Size and Cycle Time at Retrospective
Once we reach the Retrospective, we have data that we can assess whether our sizes correlate to the cycle time. The easiest way is to put the Stories on the wall and cluster similar cycles times (ignoring the size we put at Sprint Review).
This gives us our first glimpse at what effort (and waiting time) it takes to deliver our Stories. I’ll normally create a baseline for my Agile Team after about 3 Sprints and conduct this activity of clustering and re-clustering with my Scrum Masters once a Sprint.
Conclusions
Many people find estimating using size a difficult concept to grasp, but using cycle time and these simple patterns, it’s fairly straight forward to establish a mechanism to create a baseline that’s good enough to start relative estimation.
M
