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.
- 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.
- 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.