SCRUM MYTHS
Scrum Myth #2 Estimation in Story Points Is A Must In Scrum
Are estimates really a part of the Scrum framework?
Estimates are considered by many as an inseparable part of Scrum. Today I’m going to bust that myth along with some curious anti-patterns around the estimates.
Recently a friend asked me how to improve their team estimations. The team has worked together for some time now and has been performing pretty well. But of course, the estimates could be improved. He asked for advice and his idea was to pause by the end of the Sprint and re-estimate all stories and evaluate how complex the stories really were. And to see if the estimations were “correct”.
My advice was to put that energy and motivation into something more significant, for example, creating value.
This only shows how quickly a tool becomes an end on its own. Also, isn’t expecting the estimates to be “correct” an oxymoron? How to find the sweet spot? How can we use estimates in a helpful way so it doesn’t distract us from what really matters, which is delivering value?
What is your experience? Follow me on LinkedIn and let’s bust those myths together! Now, let’s dive into it!
The antipatterns
After debunking Scrum Myth #1 —The PO Is Not Part Of The Team, today we will debunk Scrum Myth #2 — Estimation in Story Points is a must in Scrum.
We will go through the antipatterns, then I will explain why we shouldn’t sweat it so much (I even have a video about not sweating the estimates).
It’s not only about the fact that people consider estimates a part of Scrum. And it is straightforward to check. You go to the Scrum Guide, hit “command+F” and there you go! No mention of words like “estimation”, “estimates” or “velocity” etc. No mention of “no-estimates” either. It’s up to you! The Scrum framework is purposefully incomplete, so you can complete it in any way that makes sense for your team and the company.
Having said that here are some typical questions I get asked that only magnify how the estimates move from being a tool to an end in themselves:
- We do Scrum, do we must do estimates in story points or can we use time?
- What’s the translation of the Story Points to time?
- Shall we estimate bugs?
- Should the team update the estimates during the Sprint when more is known?
- What about the spillover — the stories partly unfinished by the end of the Sprint — should we re-estimate them before adding them to the next Sprint?
- Should we reestimate each story after finishing it so we know how much effort each of them really took?
- Should we add an estimation to each bug after we kill it?
There’s more of this. Let’s compare it to something real.
What if…
Imagine you go on a weekend trip with your family. And instead of appreciating the sights and enjoying the ride you start sweating about the speedometers’ accuracy. You are on a highway and go 120 kilometers per hour but other cars are overtaking you. Is the speedometer right? Should you check with other drivers? And what about the kilometers made to the destination? Will it be what you planned, what if it will be 20–30 kilometers more or less? Not to mention the gas consumption…
Yeah, what if?
My favorite question to ask in such cases is: what’s the worst that can happen? Even if you take a wrong turn and go a dozen kilometers in the wrong direction, you course correct and get back on track. Even if it means taking 20 km more than initially planned, does it really matter in the long run?
Isn’t it the goal to enjoy our time off and arrive at our destination? Does it matter if we arrive 15 mins ahead or later than we forecasted?
Imagine that you planned to do 200km. And you focus on the metrics as opposed to arriving at your destination. Do you stop when the dashboard shows 200 km? Even if your destination is 20 km further? Do you obsess about the 20 km in excess?
Would you plan with 10% buffer next time? Do you always take wrong turns and do 10% more in excess? This is basically what those people who re-estimate stories want to do. As if all the stories had the same issues.
False sense of confidence
Do you know what’s my problem with this kind of obsession? That it gives people a false sense of confidence and control. And as a result of this confidence, you start committing to delivery dates and then the hell breaks loose!
Stakeholders are convinced the deadline will be met and they make their arrangements, the leadership is expecting results. There is no margin for mistakes or any manoeuvre. You have to mitigate these false assumptions by creating an escalation process. So to mitigate a faulty process you create another process in case there is an unforeseen occurrence. And you will use that escalation process often believe me. It’s a patch, it doesn’t solve the root cause, which is that we cannot predict the outcomes and outputs of software delivery. We work in a complex environment, remember?
Keep your eyes on the goal
How would I try to solve the root cause issue? Let’s get back to the weekend trip comparison. It shows us how deceitful can be to only think in metrics. It is very easy to lose sight of the goal and confide too much in such indicators.
My best advice to avoid an estimation trap is to lead by objectives. The Product Owner brings objectives to the team. And each Sprint is marked by a single objective. The Sprint Goal points the team in the right direction. There are no fixed dates or detailed releases. There is a goal to be accomplished in a given Sprint and given quarter. It is a topic for a bigger conversation, I encourage you to watch my conversation with Paweł Huryn on the Roadmaps, he explains very clearly why we should move away from such commitments.
What’s the alternative to estimates?
Have you ever used Kanban metrics? Flow metrics? Throughput instead of velocity. It means counting the number of all work items per given period of time, which can be your Sprint.
And I know what you’re thinking now. But not all of them are equal, some are bigger, some smaller, etc. My point exactly, in each Sprint you’ll have a representation of each. You can start using it as an additional metric and see how it performs for you.
The #noestimates movement doesn’t mean we have no clue what to add to a Sprint. It means we still learn from experience, empiricism, it’s just a more lightweight approach.
I don’t mean you should ditch the estimations altogether. I don't hate estimations in story points. Just use them wisely, e.g. as a conversation started, without obsessing over all the estimation anti-patterns I mentioned before.
Here goes a quick reminder of what are the estimates:
What are estimates?
Estimates are nothing more than educated guesses. They are based on experience and the information available at the time. Estimates are not accurate and can’t serve as a deadline or commitment.
Why estimate?
To assess technical feasibility. Provide a guess on the size of a work item. Support decision-making (prioritization) and forecasting (velocity/ release planning)
Why relative figures?
We are not good at estimating in absolute figures — think waterfall projects. That’s why it is easier to relate and compare the work items — relative estimation. Fibonacci is a complexity scale — the higher the more uncertainty.
