No-waste agile estimating, with Ron Lichty
------------------------------------------
Everyone gets asked for estimates, but we mostly do it poorly.
"The point is not to do Agile. The point is to be effective. Agile provides us insights." - Al Shalloway.
"Simplicity -- the art of maximizing the amount of work not done -- is essential." - The Agile Manifesto
Why estimate?
Product owner input to backlog ordering (ie the I in ROI)
Some kind of predictability, for sales, marketing, the board, the CFO, etc.
The problems with estimating
Software requires creative work, learning new skills, and undivided attention for long periods of time. Innovation is unpredictable.
Classic approach: break the work down to small chunks, estimate them all, take the sum. Those estimates don't work.
Exercise: I want to eat some fruit
How much overhead is required? Overhead == time to prepare a serving, time to clean up after eating it.
Do the estimates in a group by doing the classic approach. Try to do it in 8 minutes. Good luck with that.
"There's no sense in being precise when you don't even know what you're talking about." John von Neumann, physicist.
Scrum sizing
Take the entire team into a room and size the entire backlog. Why?
Multiple points of view, wisdom of the crowd, drive alignment, gain understanding of teammates, engage the whole team, etc.
Story sizing is done relative to other stories, so it's helpful to look at all stories in relation to each other.
Use abstract measures (story points, typically in a Fibonacci sequence), but the points do NOT equate to calendar time.
With a measure of team velocity you can make a projection.
Many teams use planning poker. But it has issues:
How do you start? If stories are sized relative to each other, the first story is impossible to size.
It frequently devolves to guessing, stepping out of relative sizing.
Two-pass release sizing (aka the Steve Bockman method)
Faster than planning poker. Guarantees stories are sized relative to each other, and provides a second-pass double-check.
E.g.: sizing the two tallest buildings in the city from the top of Mt. Rainier. Can't say the exact sizes, but you know which one is taller. And you can estimate by how much, eg it's 5% taller.
How to?
Only doers participate: the people who do the work do the sizing. No product owners/managers allowed.
1st pass: order the stories from smallest to largest.
2nd pass: size by modified Fibonacci numbers: i.e., figure out where the break is between successive point sizes. Cards will move around some more.
Can do it with physical cards and a big table.
Start with 1st person putting the 1st card on the table. Pass the deck. Next person takes the 2nd card, and you place it relative to the first card. Pass the deck. Rinse & repeat: each person takes a card and places it in size order, getting consent from the group. You build a big snake of cards.
Can do ~150 stories in about 3 hours.
As you go, you'll learn about who has expertise in the stories, what the dependencies are, etc. Write those things on the cards.
Sometimes there are series of stories that are related (eg add cc support for visa, add cc support for mastercard). The first one will be bigger than the others. You can mark these stories by e.g. using colored post-its to color-code the related stories; you treat one arbitrary one as the first one to-be-done and the rest as the follow-ons. Consult with the product manager/owner about which one comes first.
What if you need research to size the story? Score it as really big, then do the spike, then resize it. But be careful -- you usually know it's rough relative size, so you can probably put it in the ranking without the spike.
Repeat the fruit overhead exercise, but with a bunch of different fruits. 5 minutes to order them, and 3 minutes to size. Be honest about doing 1 card at a time.
A neat trick to establish a team's velocity: take past stories and slide them into the sized backlog as a third pass, which gives you point values, so you can then determine velocity, give or take ~20%.
For distributed teams: this process works well, using realtimeboard or stormboard. Instead of snaking the cards though, use rows. It makes manipulation of the cards much easier.
==============================
Brent Miller
Principal Software Engineer & Architect
New Relic, Inc.
@foliosus
blog.newrelic.com | @NewRelic
==============================
