by Steve Johnson, Under 10 Consulting
Did you ever have this conversation growing up?
You: “When’s dinner gonna be ready?”
Mom: “Seven-ish.”
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”.
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.
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.
Steve
Tweet this: Estimation Tips to Create Realistic Product Roadmaps http://wp.me/pXBON-3KO #prodmgmt #agile #roadmaps
About the author
Steve Johnson is a widely recognized speaker and story teller within the technology product management community. As founder of Under 10 Consulting, he helps product teams implement strategic product management in an agile world. Sign up for his newsletter and weekly inspirations.