Ever wonder why Agile teams swear by relative estimation?
With great respect to the advocates to move away from estimation, newer teams benefit greatly from estimation. My teams improved our sprint planning efforts by a factor or 3, once we started using relative estimation.
Without understanding Agile relative estimation, teams tend to fall back to using time-based methods. This often leads them to spend way too much time on obsolete estimates that will be made even more complex with all the unknowns and constant emergent requirements of an Agile world!
| “It’s better to be roughly right, than precisely wrong!” | |||
| ~ John Maynard Keyenes | |||
The Solution is simple: understand that relative estimation is only a rough order of magnitude estimate to quickly organize the product backlog. This empowers your product owners (PO) to quickly make value based trade-offs on backlog items and decide on what stories the team should work next. This gives the business the highest bang for their buck!
Problems with time-based estimates
- Teams spend too much time trying to get it right
- Lack of confidence/experience can lead to people being either optimistic or pessimistic
- Timeline you are estimating may be too far in the future
- Due to long timeline, there are too many risks, unknowns, changes or dependencies!
Why Use Relative Estimation
- Allows a quick comparison of stories in the backlog
- Allows you to select a predictable volume of work to do in a sprint
- Uses a simple arbitrary scale
- Allows PO to make trade-offs and take on the most valuable stories next
Estimation tips
- Relative points or equivalent Tshirt sizes are used to estimate stories, leveraging the Fibonacci sequence modified for Agile.
- The team estimates the story, not management nor the customer.
- Story estimates account for three things: effort, complexity, and unknowns. Don’t short sell yourself by estimating effort alone, that’s where waterfall projects face issues.
- Remember to estimate all Stories, user stories or technical stories. Even estimate research or discovery spikes.
- Refine your backlog as a team on a continuous basis, to get your stories to meet the Definition of Ready.
- Only pull into your sprint, stories that are refined and estimated.
- Break down stories that are large, into smaller slivers of value to optimize your flow.
- Don’t sweat it if you get it wrong, teams often do early on but improve over time.
Click HERE to download my full presentation from slideshare:
