Dev Project Estimates: Stop Blowing It

Effective estimation is one of the toughest challenges software engineers face in their jobs. Regardless of team size, it's important to crisply define, estimate, and distribute work throughout a team. As teams get larger, it becomes even more important to build good habits around planning and estimating work. Lack of planning and estimating reduce confidence in a program, break down relationships between the team and the business, and make development harder on everyone. In this article, I offer techniques to make estimating easier and show how to build trust across teams in those estimates.

Let's start with defining a unit of work. Agile teams use terms like epic and user story, traditional teams may use task or feature, and all software teams use the term bug! I'm going to define work as a change from the current state that requires effort from one or more people to deliver. Properly defined work also includes clear metrics for success, so the team knows when work is complete.

Start with a product roadmap
Every team needs to build a roadmap. It's critically important to the development team to understand how the code base will evolve over time. The roadmap will likely have four to six major initiatives. Each initiative will have several large features inside of it. Each feature will likely have multiple components. And each component will require a set of tasks and user stories needed for delivery.

It's important to break down each component into a series of 8- to 16-hour tasks. The most effective estimation sessions involve the entire team. As a team plans, questions about how individual streams of work fit together will arise. This is a good thing. These questions foster organic conversations about the project and minimize surprises. If a team is new to estimating together, start with at least the product owner, Scrum Master, and the development team (dev and test engineers).

You're probably thinking, "I can't do that level of detailed estimation for my entire roadmap!" You're absolutely right. You shouldn't. Focus on doing detailed estimation for only the first few items in the feature pipeline. Once the team understands the effort required to deliver the first few items, it can more broadly forecast the scope of work for items deeper in the backlog. This highlights a key rule of thumb: Accuracy of estimates declines as the scope of work gets larger.

Read the rest of this story on Dr. Dobb's.