Skip to end of metadata
Go to start of metadata

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.


Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.