Let's estimate -- but why?
Gábor Bittera
Full-stack Scrum Master and a Scrum Guide | Story and Metaphor Explorer | Creativity Facilitator | Proudly not holding any SAFe certs
I was asked this question the other day. Whatever estimation technique we're using with our teams, we need to understand what we are trying to achieve: what service does estimation provide and how are we benefitting from a simple sizing that teams tend to give as estimates? I had to do some reflections to better understand my own take on it, and I think I have managed to boil it down to three separate but interdependent ideas and factors.
Shared Understanding
Some teams use story points because it somehow makes sense for them and I'm sure we have all seen that team. When, during sprint planning or backlog refinement, members look at a piece of work and Kate says "It's just a small one, maybe a one or a two" while Karl exclaims "Oh no, this is actually a significant piece, no less than an eight" -- the situation begs for an open conversation.
How come two team members have such a different understanding regarding the size of a piece of work? There might be several reasons, one possible explanation is that in Kate's mind the scope of the user story at hand was a lot smaller than for Karl. What also might have happened is that in Karl's understanding the technical challenge to deliver the business value is way higher or that the team is taking a lot of risks, entering uncharted territories to get the piece of business value done. Whatever the reason, there is some conversations to be had which, in my view, is the fundamental reason why teams estimate: to open up a dialogue towards shared understanding. To understand and be very precise about the scope, the technical challenges and the risks we are taking as a team.
Capacity Planning
If the team rigorously estimates all stories that they bring in into their iteration, after a good few weeks they will likely gain an understanding of how much work they can see through during their sprints -- they will understand what their velocity is. What I have seen work for teams is that they take the average of their last 6-10 iterations and consider that their full capacity. When it comes to planning, a team might say that "If on average, we can complete 17 cards/58 points/3 large, 2 medium and 8 small pieces of work (put your metrics here), then we think that during our next iteration, we can achieve this much because (put your reason here)." If the team is consistently hitting around their average estimates, they are likely to earn a solid reputation. However, I would be cautious of a team that consistently hits their velocity, I believe something is definitely off if a team never fails.
Predictability
And this leads me to my third point: predictability. If this team in question can consistently deliver as they promise/forecast, then they become a reliable and predictable team. If their product owner brings in a business problem and starts a few conversations with them, then they might be able to deconstruct the problem to small, estimable chunks and they might arrive at the point of saying with some confidence that resolving the problem would be about 150-170 points for example.
Taking the average velocity of 30, the product owner will appreciate the predictability of the team, knowing that the team is likely to solve the problem in about 6 iterations. The good thing about this is the closer the team gets to the end of that sixth iteration, the more confident the team can be of reaching or not reaching their goal.
Conclusion
So this is my take on why teams might want to estimate. I think the biggest benefit estimation will bring to the team is shared understanding. With the help of this, the team can gain confidence regarding its capacity during planning, and if a team has earned a solid reputation and understands how its velocity can be impacted by certain factors, the business can easily use that velocity to predict the timeframe the team needs to turn a piece of business problem into a business solution.
As I said above, this is just my own interpretation and my own train of thought. I would love to hear about yours in the comments below.
Over time story points or number of tickets - as the Team improve their stories, really makes no difference. For me it’s about the conversation. The emergence of different thoughts and perspectives. The listening, the debate. The laughter and camaraderie. The shared understanding. Apart from that? *shrug* Suggest reading Escape Velocity by Doc Norton - pretty much changed my life! :-)
Enterprise Agile Coach
4 年Very much agree Gabor Bittera. What's interesting is that if you forgot about Estimating, Capacity and Predictability and just wanted to focus on the basics of gaining a 'shared understanding' of work items, one very clear route would be estimating the work together as a team! So yes, arguably the biggest benefit of estimating arent the estimates themselves but the gained 'shared understanding' of the work items it brings!
Helping people to build better software faster. Staying human.
4 年Great piece, Gabor Bittera! First of all, I agree that if estimation helps a team, then use it. I simply recommend to be watch out for what you are trying to achieve and why, as you also recommend. Shared understanding is of course crucial, ideally the whole team is responsible for the delivery and future maintenance. Weak signs during estimations like you describe can spotlight the lack of it, but in my experience this is mostly caused by unclear requirements or acceptance criteria, which is already a bit late if coming up during planning only. I'd use this to discover such root causes and fix them instead of the various methods of estimating them efficiently. In general, in such cases I tend to recommend teams not to commit such stories to the sprint. Over time, this might help realizing as well that more similarly sized stories can improve this uncertainty. Also, if every story is 1 point implicitly, it might drive you towards measuring like throughput and cycle time instead of pure velocity. What I don't like about velocity-based approaches is that in my opinion it somewhat contradicts to the original definitions. Estimations usually should deal with complexity, yet, by simply calculating velocity you are practically converting it to time, giving some false promises to those who like to think in terms of deadlines. And this brings us to predictability. I think in general with any knowledge work, this is a simple myth with timespans of like more than a couple of sprints. First, complexity increases the uncertainty of those estimates given that we are farther from them in time. Second, it seems to ignore that we have valuable feedback that we should incorporate after at least every iteration, highly affecting those intial plans and so the estimates as well. So I simply recommend to drop predictability as a goal, and focus on building trust between the delivery teams and the rest of the organization (e.g. via an indeed stable throughput). In those cases people will tend to ask when it will be ready as they will be more focused on what to build actually. What do you think?