It's often said that estimates for software development are inaccurate and time-consuming. There's even a #NoEstimates movement that preaches that we stop sizing stories all together and "just start developing" instead.
Although I agree that estimates are time-consuming to make and rarely reflect reality, I don't agree that they're a waste of time. On the contrary, I think that estimates can help your team gain credibility, improve your business relationships, and even make your developers better at what they do. The key to making estimates work in your favour lies simply in managing the expectations you have of them.
Stakeholders need to make decisions
Whatever it is that you're making, you're going to have stakeholders, and those stakeholders are going to be making decisions about the software being built. In software development, management teams generally focus on time, money, and people; clients generally focus on time, money, and quality. They don't think too much about the people, as they outsource to your company for those resources.
So first and foremost, having estimates lets you give your stakeholders an idea of what they're going to get and when they're going to get it.
Without estimates, it's impossible to plan ahead or form any sort of strategy around resources. Simply saying that you'll have a few features coming out regularly isn't enough to allow decision-makers to plan ahead. You need estimates to get a rough idea of where projects are going and to plan for resources accordingly. In a sense, providing estimates, however imperfect they may be, are viewed as added value to stakeholders.
When you work with estimates, your team members have a better sense of how much work awaits them over a given interval of time. The more accurate and consistent your estimates, the easier it is for stakeholders to make informed decisions. Naturally, stakeholders want stable velocity, but they also want increasing velocity. And that's where things start getting complicated.
Your team suffers when estimates are inaccurate. You should never hold your team accountable for inaccurate estimates. Instead, view inaccurate estimates as a symptom of something else that needs to be addressed—and improved.
Estimating isn’t actually about estimating
Teams who make accurate and consistent estimates have two things in common: they know what they're building, and they know how they're building it.
Estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution.
As Mike points out in this post, accurate and consistent estimates are made possible when teams have a solid understanding of the requirements and the solution.
This means that your team must have a solid knowledge and understanding of what they're building. All things equal, a team with good domain knowledge will always make more accurate estimates. To measure this, try using a state-flow chart and track how often stories get rejected after delivery. If stories keep going back and forth between "delivered" and "in progress," it could indicate a lack of domain knowledge.
A good understanding of the solution translates into a team that's on the same page about how the software is being built. That means that you want to aim for high-quality code that's easy to understand and maintain. Again, all things equal, a team with a low technical debt will always make more accurate estimates. There are many ways of tracking this, but I'd start with a bugs-over-time chart, a code rating from Code Climate, and a cycle time chart.
However time-consuming and inaccurate estimates may be, they are essential. Whether you're looking to gain credibility, establish better business relationships with your stakeholders, or improve your development process, estimates are a key measure in improving your performance.