Estimation has both advantages and risks to it. They can be used badly or well. Here are the purposes of estimates.

• To get people to collaborate on understanding the work that has to be done is. The estimate is a side effect of this collaboration.
• To be able to calculate the velocity of each team. If you are using time-boxing, velocity is the number of story points completed each sprint/iteration. If you are using Kanban, velocity is the cadence period.
• To provide a prediction of throughput for a team.

The dangers of estimation occur when they are done in hours or, when done in story points, management doesn’t understand the purpose of using velocity. Estimates in hours are virtually always ineffective unless the development team has fully tested code that has automated tests and uses test-first methods at both the acceptance and unit test level.

You can only estimate well on what you know or when you have a sense of what you don’t know. In other words, if you think something is going to take three days but also know your requirements are not quite clear, you might reasonably estimate it to take four days. But is not always enough. There can be other factors that influence how long it will take to get a new feature done. Here are some examples.

• The impact of the interruptions the individuals on the teams will endure
• The availability of key people at the right time
• The technical debt of the code and how it will impact work
• The lack of clarity of the requirements, especially if If test-first requirements are not being used

These factors are “unknown unknowns” and unknown unknowns significantly impact estimates. Often, you can do a good job estimating what you know. You can even do poor estimates on what you don’t know (when you now you don’t know it!). But you cannot possibly estimate what we don’t know when you don’t know you don’t know it. (Think about it.)

This leads to a new opportunity for estimating. If you think something should take three days and it took five, your first question should be, “Why was that? Why were we wrong about the estimate?” Ask it as a true inquiry. Is it that you can’t estimate? Or is it that you are making assumptions about what you don’t know without it? If you see “bad” estimates as a reflection of the “gotchas” in your requirements and code,  you can use their poorness as an indicator of failures in your process and an indicator of code quality.

If this is true, then improving your process can lead to better estimates. One approach is to use Behavior-Driven Development with Given-When-Then as a way to write the specifications; this creates greater clarity on the requirements. Another approach is to use automated testing (even at the functional level); this helps developers fix their bugs much quicker.

Turn your thinking around. Poor estimates don’t mean you have poor developers. They reflect poor process and code quality. Use poor estimates to provide motivation to invest in a better workflow, automating tests, and reducing technical debt.