FLOWER POWER
Don’t Sweat The Estimations
Stop delivering story points and start delivering value.
Today I want to write about some problems with overthinking and overdoing estimations. However, I’m not going to talk about what relative estimation is and why we tend not to estimate in hours. That gives for a whole new article and I will probably write it soon.
In my Scrum Master work, I am frequently asked questions like: should the team update the estimates during the Sprint when more is known? What about the stories half done by the end of the Sprint? Should we re-estimate them before adding them to the next Sprint? And what’s with the no estimates movements?
If those are some of the questions you face, let’s get some answers! The message of today’s article is simple: don’t sweat it! Let’s see how to do it no) because you don’t care but because you fully understand estimations are just a means to an end and not an end in itself. I am in a flower power celebration mode today because my YouTube channel has just passed the magic mark of 1k subscribers. Join me in the celebration and watch my video here:
Scrum Guide 2020 talks no estimates
Did you know that the words estimate, estimations, re-estimate disappeared altogether from the 2020 Scrum Guide? To compare, there were nine mentions of different variations of the word in the 2017 Scrum Guide. Another evidence of the Scrum Guide becoming less prescriptive. Now we know where most of the cutting was done.
So, just to underline — estimations, story points, etc. don’t come from Scrum and they are not mandatory at all. They come from XP and were adopted by Scrum practitioners. You don’t have to use them. But if you do, it might be helpful to understand them better.
Why do we estimate?
Even as a vivid supporter of the no-estimates movement, I can easily identify at least four reasons behind estimations. Let’s take a look at them now.
- Arrive at a shared understanding — you cannot estimate what you don’t know. To give story points to an item, you need to learn about it. You need to get in your curious mode and ask questions.
I used to work with a Kanban team in which we estimated user stories. Why on earth would we do that? Well, we didn’t record those estimations anywhere, hence the no-estimates movement. Yet, we considered it was the best way to check if everyone agreed as to the complexity of a given user story. Otherwise, it’s hard to know if, after a brief discussion, we reached a common understanding. What’s more, it is a great trigger for a conversation to learn why one person gives the same item a 5 and another a 13. The moment everyone reveals how many points they give to a story, we know if we are talking about the same thing. If only it were possible to do this so easily in other aspects of our life…
To learn more about refining user stories, watch my video about refining the refinement. - Organize Product Backlog based on value and effort — thanks to having the estimation in points, T-shirt sizes, or even hours, you have more information to organize your backlog. Product Backlog management is not only about the priority, it’s about the effort too. Would you rather accomplish five small stories or one big? Let the business decide. Note that if the estimates suck they won’t help much but I think that at least they will give you an idea of what is bigger and what is smaller.
- Plan upcoming work — Scrum is based on empiricism. We learn and apply this knowledge. Estimates provide us with a way to measure a team’s velocity and have data to support our forecasting. And works also for road mapping purposes — by knowing the team’s past capacity we can forecast when a new feature will be done or how much we can deliver by a given date. Note the deliberate usage of words like estimate and forecast. This is not a contract or a guarantee. Far from it, and I can’t stress it enough. It is a prediction based on a % of probability. E.g. We can predict that with a probability of 85% that a given chunk of work could be delivered in 3 sprints. But we still have a probability of 15% that it will end up being more. Know your lead time, know your delivery rate and make informed decisions.
[Updated with the 4th point: March 21st thanks to Simon Mayer]: - Split user stories — splitting large items has many advantages. You can reach more granular prioritization, and maximization of the work not done. Besides, if the items are of similar size it can increase predictability and reduce waste. And later it would be easier to move to the dark side of #noestimates…
Ok, so now we know why we estimate. Let’s see some questions I am frequently asked.
Question 1
Shall we reestimate the stories during the Sprint when more is discovered?
Use case: The sprint started, but the team found that one story would need considerably more work.
Let’s start from the beginning. Was the story ready to be added to the Sprint? Does the team have a Definition of Ready, meaning a checklist of what they need to have covered, to consider a story ready for the Sprint? Typically that would be: the story has acceptance criteria defined, it has been refined so a shared understanding has been reached, and as a result got estimated.
Even if the story has been deemed ready by the team, let’s not forget that we work in a complex environment with a lot of unknowns. This may happen especially to newly formed teams but also to those that work together for a long time.
To me, the answer to such questions is a big: it depends. If the team is new and only now do they learn what’s their velocity and how to estimate — go ahead and adjust the estimate just to keep a record of the previous estimation. Then list those stories with estimation changes and take them to the retrospective. Go through those estimations and learn what happened. Was there something missing we could have thought of before? Are there any parts of the system the team hasn’t taken into account? Is the testing effort unaccounted for? Step by step the teams will learn. Just don’t make too much of a big deal out of it, because it is easy to go from one extreme to another.
Question 2
Should the team update the remaining Story Points in an unfinished story before adding it to the next Sprint?
Use case: the Sprint ends. A story has three of five tasks done. Each one has an equivalent to one story point. So at the beginning of the Sprint, it was estimated to five story points. The story was considered as not finished and pulled to the next Sprint. Should the team update the remaining Story Points, in this case, two? Or keep the initial estimation?
My answer is that it is totally up to the team. I worked in both approaches with two different teams at the same time. It is as simple as changing the estimate while picking the stories at the Sprint Planning. If the team feels it will work for them, just do it. If you are not convinced, then don’t.
What I would advise here is not to get crazy about the estimations, story points, or velocity — it is all just an estimate. Instead, think about having some other metrics in place. At least measure the number of all issues delivered per time slot, if you work in 2-week Sprints, grab 2 weeks. In Kanban, it is called throughput. This way you can compare both metrics and see if they are consistent and which one is giving you more predictability. No sweat, no drama.
Instead of overthinking the estimations, I try to help the teams focus on delivering value.
When they focus so much on the estimations, the teams start delivering story points instead of value.
Sometimes the teams focus so much on the day-to-day work that they lose track of the bigger picture. I remember working with a team that created a burndown chart based on sub-tasks, instead of stories. They were really proud of how they were getting the work done. But sub-tasks themselves don’t deliver value. User stories do (I use the naming from JIRA here, you can call it anything you like).
If at the end of a Sprint a story is three quarters done and you focus on whether you should re-estimate it or estimate it again, we have a problem. Instead, think about what you can do so it can be released to the end-users. If after a Sprint nothing can be released, then you can re-estimate all you want but you haven’t done anything that matters.
Focus on delivering value and creating a great product. Don’t let estimations, Scrum, or any process or technique distract you from your mission. Keep calm, and make sure your work has an impact.
