Gummy Bears

An abstract concept of estimation.

Instead of estimating in hours, you use a parameterized value which is a factor representing complexity or difficulty.

Mike Cohn's one-liner around this is (as I can remember it from a presentation he did on XP-meetup): You don't measure a race track by how long it takes to get around it. You measure it by how long it is.

Reasons for using gummy bears

• Parameterizing task effort makes it easier to update all the estimates by tweaking one number (the velocity). Re-estimating 100 backlog items when you discover the team is slower/faster than expected can be alot of work.
• Disconnecting real hours from the estimation is an advantage because people are lousy at estimating in "ideal hours". When people think they can do one task in 8 hours, they assume that they will get it done in one day. In reality, people don't really get to spend more than 30-60% on their tasks. The rest is "lost" to context-switching, meetings and liasion activities.
• Product owner is disappointed when the team only manages to do 100 of the estimated "hours" when the team only spends 140 hours doing it.
• Like above, saying "Last sprint our speed was 100 estimated hours on 140 hours" sounds really lame and slow.

Resons for not using them

• If nobody are going to "respect" them (meaning doing the math with velocity), there's no real point in using them.
• There are claims that people actually make better estimates when re-estimating in real hours.
• And it is also said that using abstract concepts lead to lower commitment on planning sessions.

Resources

• Agile Estimating and Planning by Mike Cohn, Book review (PDF)