Thursday, April 21, 2011

Effort Estimation is Child’s Play

Our schools are teaching Agile techniques to 2nd graders.

My 2nd grader asked my wife for help with his math homework. As soon as she heard the word "math," she said "go ask your father." He brought it over to me. They are learning about weights and measures and how to use scales. He showed me his homework and said "dad, I don't get it. What is this?" I looked at it and smiled. "Well," I said, "that's what dad teaches grown-ups to do every day at work. You're learning about effort estimation."

Here is his actual homework sheet:

 

 

Each example gives you choices of absolute measurements (pounds), BUT you don't have the tool to weigh each object. Instead, you're relying on past experience and knowledge to estimate the weight. Have you ever held a baby? Probably, and even if not, you know they are a lot closer to 8 pounds than 20 or 70 pounds. And while you've certainly never weighed an elephant, you know from your visits to zoos and circuses that they are huge, and your experience with objects that weigh 100 pounds or 500 pounds tell you that an elephant is certainly much more than that, so given the choices, 11,000 pounds is easily the right answer.

This is essentially what we do with effort estimation in Agile product development. We are asking team members to measure how much work is required to complete the product feature, not how long the work will take. And the measurements are not on an absolute scale, they are on a relative scale, meaning "how much work is this item, relative to the amount of work the simplest item you can think of is?" When we start using effort estimation (BTW, a.k.a "story points" or "effort points") we have teams baseline on a common simple activity in their domain, and use that as the base measure. After they agree on what that is, all other features are measured relative to that baseline.

Many, if not most, Agile teams use a numerical scale called the Fibonacci scale to measure effort. The Fibonacci scale is named after Leonardo of Pisa, who was known as "Fibonacci" (son of Bonaccio). He introduced the concept to the West in the early 11th Century. These are the typical Fibonacci numbers used for effort estimation:

1, 2, 3, 5, 8, 13, 21, 40, 100

Without getting into a doctoral dissertation in mathematics, let's just say it gives you a scale with steps that increase in magnitude as you go up, so when you have to decide between two of the larger numbers, it's not so fine grained. Seeing it graphically really helps. Here is a "Fibonacci spiral" which you get by making boxes with areas the same as the Fibonacci numbers, and drawing circle arcs corner to corner, and connecting them:

And where else have you seen that shape in nature?


The increase in step values forces you to choose the closer "bucket" rather than argue over minutiae. And that's why it works so well in effort estimation…it forces you to "pick one!" and not get bogged down in the details, which is the point of effort estimation…the right amount of detail at the right time. We use it early on in the process, before you can know all the detail you would need to know to get down to estimates in hours.

Pick Your Measure

Here's one of the great things about effort estimation in Agile…you don't have to use Fibonacci. It's hard enough, when we're used to a professional lifetime of giving estimates in hours or days, to mentally switch to measuring effort. If your team is having a hard time with Fibonacci, and divorcing a numeric measure from absolute time measurements, don't use it. It's only important that your chosen measure has relative sizing that the whole team can relate to; it doesn't have to be numeric.

Teams have used T-shirt sizing for effort estimation (Small, Medium, Large, eXtra Large). I'm coaching a team right now that uses sea life: guppy, salmon, dolphin, shark, whale, Kraken. ("Release the Kraken, Jim!"…props to you). I even heard of a team that measured stories in "Frito bags." Why? They baselined a 1-Frito bag story on the amount of work it would take this one developer (who ate Fritos all day, every day) to complete while eating one bag of Fritos. You really can use any scaling method like that.

But in the end, remember to focus on simplicity. Effort estimation doesn't have to be difficult, They are teaching the concept to 2nd graders.

As always, I welcome your comments.