If you’ve stepped one toe into Agile you will have heard of story point estimation. This is a valuable tool in Agile as it aids in predictability, knowledge sharing and brings the team together as we collectively own the work. Yes, this post is about story point estimation, BUT not the whole shebang, just one very important aspect of it.
To kick-off, let’s look at the basics of estimation:
How do we estimate? Good question, there are many ways. I use story points as I’m a simpleton who likes numbers. You can however get quite creative and use T-Shirt sizes, superheroes, animals, etc… anything that indicates a range of size.
What do we use to estimate? Another good question! We don’t talk time, so not that, however, we do talk effort! This can be a hard concept to grasp when teams are kicking off. One of my teams really struggled with this notion so we added “we don’t talk time” into our working agreement which helped us quickly phase out any time talk. The only time aspect we need to consider in Scrum is when taking a story into a sprint. We need to ensure the story can be delivered within the sprint timeframe. If it seems too large for a sprint, break it down!
If I ask you how much effort will mowing the lawns take? How would you answer that? It can seem grey. No need to worry, we keep things simple here with a definition so we’re all on the same page.
Effort = Risk + Complexity + Uncertainty
The greater the risk, complexity or uncertainty the bigger the effort, therefore the bigger the estimate.
Remember! An estimate is an estimate and it’s based on what the team knows. As with anything the more practice, the better we get, BUT it is still an estimate which in essence is our best guess and not a commitment.
Story Pointing is all about estimating chunks of work that we call stories. In my team refinement sessions we point with this format:
- Our Product Owner gives an overview of the story
- The team asks questions to clarify their understanding of the story
- We confirm acceptance criteria for the story
- Each person in the team gives an estimate of the story points **at the same time** — based on the effort required to complete that story
2 scenarios can eventuate here:
- All members give the same estimate — then we’re good to go, the story has been estimated and the team has agreement OR
- We get a range of estimates — this is where it gets juicy!
For the second sich we ask the highest and lowest estimates or the outliers to give the team insights. If there is more than one person with the outliers, we pick one at random to talk through their thinking. Often a Scrum Master will need to stop the team from changing their estimates to conform so they can avoid the explanation part — this happens more often than not — which negates the true value of this exercise. I call this the high/low convo and it’s incredibly valuable — keep on reading to find out why.
A higher estimate will give their reasons and often you hear:
“Oh yes, you’re right, I hadn’t thought of that”, or
“we’ve been burned by this before so…” or
“ah yes, that’s far more complex when you take that into account”…
The higher estimate is stating their case and the rest of the team needs to decide if they believe it’s a valid reason to raise their estimate.
A lower estimate will give their reasons and you might hear from the team:
“Oh that’s a simpler way to do it, I hadn’t thought of that” or
“have you considered this piece”
Likewise, the lower estimate has conveyed their argument and the team needs to decide if they’ve been swayed to reduce.
After the team has discussed the high and low estimates, we do another round of pointing to see if anyone has been compelled to change their estimates. If we have a consensus (consistent estimates), we’re good to go, if not, the discussion continues until the timebox ends.
The high/low convo can lead to intense and valuable conversations within the team sometimes lasting for a decent chunk of time. For this reason, I timebox my refinements to 15 mins a story.
The goal is to reduce the cone of uncertainty based on what the team knows. Once the timebox ends, follow the team’s agreement on how stories with varying estimates are dealt with. This can include taking an average, taking the mean, removing the outliers, extending the timebox… The estimate itself is important for predictability however the hidden value comes from the team discussion to get to this estimate.
This high/low conversation gives insights that others may have missed or simply not known. This is a knowledge-sharing exercise that helps us combine the team’s experience and expertise to give us the most insightful estimate. Scrum is based on empiricism, this means we make decisions based on what we know. This high/low conversation is the team sharing what they know based on a variety of expertise. The outcome is an informed decision to aid in our predictability (this is a conversation for another time…). This high/low conversation is the Scrum Masters way of helping the team to leverage the knowledge and learnings they already have by helping them unwrap the present.
