And How to Fix Them
Estimation is a loaded topic in software development. It is where many anti-patterns in a company come together. Developers often suffer from the mechanics that come to play with estimation.
Here are 7 estimation blunders and also how you could fix them. Fair warning: in most cases, there are no easy answers.
Estimates because “We have to”
Not all work can be estimated easily. There’s even work that can’t be estimated at all.
Sure, when a topic is similar to something you did before, you have a reference. This will help you to make grounded estimates. And also, when work is quite clear-cut, you will typically have no problems estimating.
But there are other situations too. When you don’t know what to do to finish the work, things start to get messy. You may not have the experience in the team to understand the magnitude of the work. Or you may face a problem you never saw before. In both cases, you may not be able to estimate at all.
Despite the fact that too many things are unknown to come up with an estimate, very often teams still decide to estimate anyway. Because all work has to be estimated. So that all work can be planned.
But estimating for the sake of estimating makes no sense. It will not bring the predictability that people seek in their plans. It will only result in disappointments, especially when the estimates are leading the conversation. When it is more about “when will it be ready?” than “What have we learned?”
Because, if we want it or not, when we are dealing with a problem or a task that we don’t know how we should proceed, estimation doesn’t make a lot of sense. This typically happens with complex problems. Luckily, there are alternatives. I will discuss the one that I like most now.
When all that matters is that you should do the work regardless, accept the fact that you can’t determine how much effort this work will take. Approach the work as a learning experience and ensure you have short feedback loops.
Every iteration, you determine what small thing you wish to learn and you focus on that. Gradually, you will gain a better understanding of the problem. You may get to a point where you will be able to estimate (some parts) of the work. That could then be helpful information.
So, estimates don’t always make sense. But when they do, there’s still so much that can go wrong. I will tackle this now.
Neglecting different estimation opinions
Whenever a team is estimating their items, user stories or however they call them, they are bound to have different opinions about the magnitude of the work. As a result, their estimates may differ greatly. It is a mistake to average them out without discussion. A ‘3’ and a ‘21’ don’t simply average out as ‘12’ (or ‘13’ if you wish to use the Fibonacci sequencing).
Arguably the greatest merit of estimating is that teams can have a conversation about the work at hand. Whenever someone thinks an item is small while another says it’s extra large, this should trigger a discussion. Why do they think so differently about the same item?
Perhaps the person who says it’s small knows an easy way. Or they may have overlooked a complication that changes everything. In these cases, the estimation can help the team to gain a better mutual understanding and alignment. This is arguably more important than the estimate itself.
One estimator to rule them all
I have been in many refinement sessions. I found it interesting to see the power dynamics at work. Especially when one person in the team determined the estimates by themselves. Either by not allowing other opinions or by overruling other estimates. They knew best as they were the so-called expert. A similar situation occurs when the team has designated estimators, for instance when the work of doing estimates is divided.
But when you work as a team, everyone who has a part in the work also should be part of the estimation. Regardless of the seniority or expertise of a person, they may have important insights that help everyone to paint the picture.
As a team, you should value the input of every team member. It is important to have mutual insights. And also, in the area of complex work, it is beneficial to have a team that creatively collaborates to achieve their goals.
Estimating takes forever
I used to be part of a team where we wouldn’t stop estimating an item until everyone was on the same page. As long as we didn’t all agree an item was an ‘8’, we would continue to have a discussion. This is an example of wasteful activity.
Unless the work is clear-cut, it isn’t realistic to assume everyone will be on the same page. Now, whenever I see this occur, I advise the team to seek consent instead. Instead of having everyone agree on an estimate, you can also ask for permission to have an estimate of ‘M’ from the person that thinks it’s an ‘S’.
Seeking consent is often more effective and efficient than seeking unanimity. It surely allows you to spend less time estimating your work. For more on ways to make decisions, here’s a great article from Jurgen Appelo.
Estimates need to be “correct”
The urge to have correct estimates is an anti-pattern that is based on the misunderstanding that thorough knowledge or analysis will result in a clear path towards doing the work. And whenever something took longer or shorter it shows a lack of knowledge or insufficient analysis.
But the work isn’t always clear or complicated. You often don’t have a straight answer or the opportunity to find all the answers through analysis. Your work can be complex. You may have an idea of what you need to do, but there are unknowns that prevent you from being certain.
Whenever you have unknowns in your work, you need to accept that estimations are no more than “a rough calculation of the value, number, quantity, or extent of something”. Which is, by the way, the definition of estimation according to the Oxford dictionary.
It’s already in the definition. Estimates are rough calculations. As rough calculations, they ARE correct. As they reflect the notion of the members of a team at a certain point with the information they have at that moment.
Therefore, the way to solve this issue is to simply treat estimates as rough calculations and accept you learn while you work on the item.
Estimates are turned into commitments
One of the most harmful anti-patterns of estimates is how they are misused as commitments by people outside of the team, people with power over the team. After everything I discussed already, it is probably clear that this is dumb. Still, many developers are in this position.
Obviously, the behaviour is undesirable. and there’s no easy answer. It depends very much on the organization that you are in. Is the team allowed to push back? Then it is important they do so. They should confront the person who is committing them to the estimates and help them understand this is not how it works. You would expect this to succeed in an environment where agile approaches are the norm.
Isn’t your team allowed to push back? Then this surely can’t be the only thing holding the team back. It is a clear sign that the team can’t be effective because of command and control constraints. These are organizational impediments that should be resolved.
When organizational impediments hold the team back, leadership should step in. This leadership could come from someone or multiple people from the team. Typically, this is a job for the Scrum Master. But it could also be on the top of the list for a team manager. Regardless, it should be clear that this issue needs to be resolved asap.
I know. In many organizations, this is a pipe dream. But still, it is the only way to come to a resolution. It’s either that or leaving the company.
Others do the estimation
This anti-pattern is strongly related to the previous one but deserves a separate mention. It’s mind-boggling how teams get instructions on what to do and by when. I’ve seen Product Owners push for things to be finished by the end of the Sprint. And managers telling the team to solve a burning issue in a day. Often they don’t even consult the developers.
I also saw managers cutting estimates in half: “You say you need two weeks? I give you one week to finish it.”
You would expect that everyone understands that quality trumps speed. But also that you should leave estimation to the people who do the work. Sadly, real life isn’t this simple.
Again, there are no easy answers. Also here, the only way forward is to not accept this behaviour. And if needed help to change the organization to avoid this from happening again. Just like in the previous example.
Canary in the coal mine
The way the team and the organization handle estimation is like a canary in a coal mine. The way estimation is done and used can quickly answer some interesting questions:
how is the purpose of estimation understood?
how much is complex work understood?
how well does the team collaborate?
what are the power dynamics in a team?
how self-organizing are the teams?
There’s so much more to it than a number. It’s all about having conversations and the power dynamics too.