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, breaks down relationships between the team and the business, and makes 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.
Minimize Waste by Using a Backlog
By using a backlog, agile teams enjoy more flexibility in planning and delivery. A backlog of work is simply an agreed upon way for a team and business to prioritize work. The most important item is on the top of the backlog. Items are then listed in decreasing priority, walking down the backlog. As a team completes items at the top, they move on to the next item on the list.
Over the course of the project, business priorities will change. Product owners can easily move items in the backlog that the team is not working on. The team is not impacted and everyone remains focused on the goals ahead.
The Case for Relative Estimation
To get started, I strongly recommend using relative estimation. I learned the practice of using story points in scrum training. Story pointing assigns Fibonacci values (1, 2, 3, 5, 8, 13, etc.) rather than time estimates to bodies of work. Let's take a simple example: Imagine trying to estimate the relative complexity of fully consuming a piece of fruit. The first item in the backlog is to eat an apple. We assign that a story point value of 2. When looking at the next item, a banana, we know it's at least as complex as an apple, but with the additional cost of having to peel it. Let's give the banana a 3. Oranges are more complex, so we assign a 5. Once we eat another piece of fruit, we can compare the experience to eating an apple retrospectively. We then reconfirm estimates for both experiences. If eating a fruit is significantly harder than we estimated, this is a key learning and we make adjustments. Understanding learnings throughout the process helps improve a culture of estimation.
So why use story points instead of time values? Story pointing allows the team to focus on the complexity and time involved in delivering a piece of work. The team compares the new work against work they've already done. They compare the complexity of the new assignment against past challenges and rank the difficulty as well as the time required.
With time values, we don't often account for "the cost of doing business." Meetings, email, code reviews, etc. all are necessary practices throughout the workday, but don't actually count as "work." Story points isolate the workstream from the non-workstream items, so estimates are more consistent.
Finally, a team's process evolves over time. As the team incorporates better development practices, its ability to deliver work increases. Story points focus on the complexity of work versus just the duration, and they are more resistant to change. Likewise, if a team's definition of done changes, story points hold better over time.
Estimates are Self-Evident
In software teams, there is a lot of fear around estimates that "grow legs." We've all been on a project where it's proclaimed, "This feature will take three months to build," which really means "Commit to delivering this feature in three months regardless of cost." This sets up the potential for failure and missed deadlines. While there is comfort in locking schedules down, it limits a business's ability to make the right decisions as the program evolves.