Estimating is perhaps the biggest issue facing product managers regarding roadmaps. Here are some tips to do better sizing estimates.
Did you ever have this conversation growing up?
You: “When’s dinner gonna be ready?”
You: “Uh, can you be more specific?”
Mom: “It’ll be ready when it’s ready!”
Estimating is perhaps the biggest issue facing product managers regarding product and portfolio roadmaps. Obviously you want to get an estimate before anyone spends too much time designing a solution but you can’t really get a valid estimate without some level of design.
Here’s the big trick: guess.
A guess is good enough for this level of planning. For roadmapping you don’t need a person-hour estimate; you just need an idea of whether it’s a month or a year, tiny or huge. Experienced teams find they can quickly and easily estimate roadmap items by fiscal quarters. This item will take one quarter; that one will take three quarters.
Unfortunately, a lot of product leaders and company leaders expect precision in these estimates much too soon. Postpone this level of detail until your team has a chance to examine the idea further and get more specific in terms of effort.
And remember: an estimate is a guess, not a commitment. Assure your teams that these are sizing estimates, not date commitments. If they said it might take a quarter, assure them that you are not committing them to delivering it this quarter. Estimates are “no-sooner-than dates.” An item estimated at two quarters will be available no-sooner-than two quarters from when we begin.
Estimating relative effort is the key
Rather than estimating in months and quarters, most teams are more comfortable—and more accurate—when estimating size: this is bigger than that. A little bigger or a lot bigger.
I like assigning a relative number to estimates so that you can compare dissimilar things. But be careful with numbers. Before you know it, some fool (maybe you!) will try to equate these effort numbers with person-weeks or –months, and create an atmosphere of distrust between the development team and the rest of the company.
Your teams probably have history estimating user stories; they can use the same techniques with epics and roadmap items.
Agile teams generally use the Fibonacci numbering scheme for estimating. Fibonacci numbering is the sum of the prior two numbers in the sequence, like this:
1, 2, 3, 5, 8, 13, 21, 34, 55
Estimating using a Fibonacci sequence means that each estimate level is as big as the prior two levels combined.
But Fibonacci is not the only way to estimate. It’s fairly common for agile teams to use “shirt sizes” for the first, rough estimation. This feature is small; that feature is large. You can assign numbers with shirt sizes using a scheme like this:
Tiny: 1, Small: 2, Medium: 4, Large: 8, Huge: 16
This “Doubles” method shows that each level of effort is twice as large as the prior one. So “small” is twice as big as “tiny;” “medium” is twice as big as “small.” Another way of thinking about it is you can do two “tiny” things for the same effort as one “small” thing.
For a more dramatic escalation curve, some teams prefer the “Squares” method:
12: 1, 22: 4, 32: 9, 42: 16, 52: 25.
Here, “small” is four times bigger than “tiny” and “medium” is more than twice as big as “small”.
Comparing three schemes
Here’s the thing: The actual values don’t really matter as much as the relative values. It turns out that people cannot accurately estimate time but they can estimate relative effort. It’s difficult to say “this will take 2 months” but it’s easy to say “this is larger than that.”
Estimating is a team effort
So bring your team together, discuss the various items you have planned for the roadmap, and get their estimates.
image sizing estimates
It’s been proven that team estimates are more accurate than an estimate from one person. Three people on a team is good; five is even better. When there’s a discrepancy, you’ll want to get those who estimated highest and lowest to explain their reasoning. Maybe they’ve seen something or assumed something that the others haven’t. Explaining this point of view may cause the team to re-estimate with the new assumptions.
This approach for assessing the effort for a roadmap item, a user story, or an epic is known as “planning poker.” Read more about this method of estimating at www.planningpoker.com from Mountain Goat Software.
One last tip: Before you start an estimating exercise, I recommend you begin with a benchmark. Choose an item or two that your team has already completed—one that you know the time and effort it really took—and then compare new items against that benchmark.
So whatever your method—time in quarters or relative effort—you’ll want an estimate of size for each roadmap item. It will help you ensure that you’re not over-committing your team.
There are so many ways to estimate, each one can suffice to figure out how “big” something is. My problem however, is taking that estimate to the release planning board. Without “real” numbers like “how many days”, how can I figure out how much can get in a release? We have created a capacity worksheet that identifies how many development days are available to us for each release based on start/end dates. Of course we take into consideration focus factor and overhead when making these calculations. So, I have 100 developer days for a release. How do I determine that a day equals 2 tiny or 1 small or a week is 1 medium? Or is this exactly what I have to do? Ask the development team what each means?
It’s helpful to separate effort from time as I indicated in my post. The real trick is now to look at past work to examine the effort sizing and compare to actual work time. And here’s what makes it really difficult: Each team is different. Dev teams are made up of people with different skills and areas of expertise. What takes one group 10 days may take another 20 days. That’s why product managers should look at effort instead–it’s a more effective way to balance the work. Embrace the concepts of Kanban where the work is in a continuous queue. The product manager’s job is to manage the queue; development’s job is to pull the next priorities from the top of the queue.