Estimating in for many teams is a pain. Endless discussion if a Product Backlog Item is now 5 or 21 Story Points.
Now, the conversation itself is important. To me it is even the most important part of the whole sizing exercise. Because this is the moment where a team's understanding is improved about this specific item. And that is exactly what Product Backlog Refinement is all about.
If only we could get to that sizing more effectively...
As we want our teams to be able to make swift decisions, they themselves need to have some way of having insight in their past performance, even if not all team mates are present. And we also want team members to be able to size items if not the whole team is available.
A reference model for sizing items is very powerful for this. This reference model should bring transparency in how the team remembers the size of items they implemented in the past. Once available they can take a new item, compare it to items they remember from their past experience, and in that way have a realistic size for it. And this without having to know every single detail of this new item. Only understanding that it is quite similar to something they implemented earlier.
The conversation will shift
from "is this 5 or 21 Story Points"
to, "How is this so different/similar than this other item in the reference matrix? My understanding is that ..."
The next steps outline a practice I use when coaching and facilitating teams to initiate this reference matrix.
PS. A big thanks to Jürgen De Smet who taught me this practice years ago.
1/ Collect 100+ items that the team implemented in the past. From all different sizes. Huge items that were not yet split and were way too large to be implemented in one Sprint, items that were effectively implemented in one Sprint, and everything in between. Not every team member will know about every single item from the past. And that's fine.
2/ Let the team make 3 groups of items: small, medium, large. Affinity mapping in silence gives good enough results quite fast. Give the team members the opportunity to question why some items are in a certain group. This grows the understanding in the entire team.
If you create a matrix, these will become the rows.
3/ Let the team pick the group "small" and do the same exercise. So you arrive with Small-Small, Medium-Small, and Large-Small. Repeat for the group Medium and Large. Giving you now 9 groups in total.
4/ I tend to use the Fibonacci sequence for sizes. Having identified the group with the smalles items, the Small-Small, these receive a size of 2. Not 1 as in the future the team might find still smaller items.
5/ Ask the team which of the groups contains items that took about the double of effort when comparing to the items in the "2" group. These receive a size of "5". Why not "3"? Because "about the double" is hard to tell and typically our human optimism makes us go on the low end anyhow.
6/ Now it can be that there was no group in between. In other words, the Medium-Small were selected. Fine. Continue with the next step.
In case there was exactly 1 group in between. Then these receive the size "3".
In case there are multiple groups in between, take the first group. Put them in the size "3", and let the team go over the items to decide if this is a good fit for these items, or if they are more related to the items in the sized group "1" or "5". Do this for all groups that were in between.
7/ Back to step 5. So which group of items is about the double of the effort when comparing to the items, now in group sized "5". These receive a size of "13".
And keep repeating until the Large-Large group is also sized.
You can have it all in a 3 x 4 matrix.
The team has now created their own reference model: 100+ items they implemented themselves. The reference model makes their understanding about their past work transparent.
Once this reference sizing matrix is developed, it is used during refinement workshops - see my earlier blog post How Dealing with the Drowning Details During Product Backlog Refinement. A team takes a Product Backlog Item, compares it with items in their own reference model, and has sized it in a matter of minutes, sometimes seconds. The conversations they have are about similarities and differences compared to their own past work, to work they can relate to.
Be sure to maintain this reference model. I guide the teams I coach to update this matrix with any items that they implement during a Sprint once Done is achieved. In that way their new insights and knowledge is still vivid. At regular intervals older items can be removed so this matrix does not get overloaded.
Summary:
Sizing without a reference model is painful.
Look to past work items with the team and create your own reference model for effective sizing of Product Backlog Items.
Prompt:
Have a workshop with your team - this should always be a team exercise - to initiate your own sizing reference model, based on items implemented in the past.
I hope you find value in my blog posts and if you are looking for more clarifications, feel free to take contact.
If you want to take a deeper dive into Product Backlog Management topics, then surely check out our Product Backlog Management Skills workshop. We have some scheduled in the coming period.
