Mastering Estimation in Product Development: Understanding Hours, Story Points, and Business Needs

If you’ve been in product development long enough to ask yourself “What’s a burndown chart and why does it look like it’s burning up?” then chances are you’ve had your share of estimation frustration. Estimation is a messy process that’s muddled with terms like “capacity,” “velocity,” “complexity,” “burndown,” and many others that will make you cringe by your third sprint. Not only that, there’s little consistency in how estimation is defined. For any development project to succeed, we need to understand how to create estimates and why they’re important. This is part 1 of a series of posts that will help level up your team’s estimation process.

‍

Where Do Estimates Come From?

A young product team member walks up to their team lead and product owner and asks: “Where do estimates come from?” Panicked, the team lead and product owner think through how to explain to their young product team member — delicately and discreetly — where estimations come from and how they’re made. After several minutes of confusion, we’re left with the product equivalent of a large bird flying into a house late at night that drops off a baby in a nap sack for a random unsuspecting couple.

So why is this a problem?

One, birds don’t drop off babies to random couples. Two, if we can’t properly define our estimates, then we can’t measure their accuracy; if we can’t measure their accuracy, we can’t reliably predict what work we can accomplish in a given time frame; if we can’t do that, we have no value-centric way to prioritize work. We need to be able to communicate — internally and externally — how much value we can deliver and what needs we can meet as a team. If a business hires a consulting firm to build a product or update a site, they want to know the project’s cost and timeline. If we don’t have reliable estimates, we can’t accurately predict when a project is going to be completed.

‍

Understanding the Business Need

I know it’s easy to think that estimates are there just to drive you crazy, but let me ease the tension for a minute here: nobody likes making estimates. In my experience as a scrum master, estimation tends to create friction within the team, and requires a lot of planning that a stakeholder may not be expecting. A client or stakeholder asking for estimations without being specific is a nightmare to work through. You need to know what the end goal is, how to get there, customer stories, edge cases, app behavior, design and components, etc.; your estimates should have wiggle room in them, but to plan out how long development could take while missing pieces of information will only cause the estimating party to give the most reserved figure.

In the stakeholder’s defense, there’s a legitimate business need behind the estimate. In fact, there are many: development budget, resources, product release deadlines, and even (especially) market conditions, to name a few. The business needs to know how much it’s going to cost to build a product, how many people it’s going to take, and when it can be released, all to know if there’s a payoff for the effort required (and how large that payoff will be). A thorough estimation process can be the difference between a dud product or creating a breakthrough solution in a particular market.

This kind of thorough estimation process is daunting at first, however, it is a crucial part of the development process for the development team and stakeholder alike. Which leads me to my last point for this post:

‍

Defining Expectations

Project managers are all too familiar with defining expectations — it’s a key part of what they do, and keeps everyone happy, informed, and focused on the same goal. In our experience, the best way to start defining expectations is to gather as much information as possible about the desired outcome, while being a good steward of the client’s time. If this means you’re spending a week examining a codebase or spending hours with a client going through views and asking questions for a long term project, then do it. You might think “Zak, that is entirely unrealistic.” Well so is delivering a solution without understanding the problem.

If you’ve ever painted your home, you may have heard that a good paint job is 90 percent prep work and 10 percent painting. In development you’re going to spend a lot of time preparing for the work to be done — likely not 90% — and you may even spend a lot of time building systems before any visuals change. Setting these expectations will help to ensure a much smoother project and development experience for everyone involved.

So what does this have to do with estimation?

Part of defining expectations is defining how much work we can get done in a given amount of time. Now, I can’t think of a situation where a definitive expectation was set for a development task’s time, and neither should you. Understand that you will not be able to predict every possible situation — you simply can’t, nor should you try. You need to find a balance between expectations and estimates.

In product development there are multiple ways to estimate the effort required to complete a development task, and how long until a business can deliver value relative to those tasks. In the coming weeks we will examine two of the most commonly used — and misunderstood — forms of estimates: hours and story points. You’ve likely heard of these before, so let me make one thing abundantly clear before we proceed:

Hours and story points are not the same thing.

‍