1. Agile Estimation

2. 2© All Rights Reserved
Do Not Duplicate
Fundamental Paradigm Shift

3. 3© All Rights Reserved
Do Not Duplicate
Approach Comparison

4. 4© All Rights Reserved
Do Not Duplicate
A Holistic View

5. 5© All Rights Reserved
Do Not Duplicate
Simplified Scrum Overview

6. 6© All Rights Reserved
Do Not Duplicate
Product Backlog Darwinism

7. 7© All Rights Reserved
Do Not Duplicate
• Can happen anytime
– Should definitely happen with increasing
detail prior to developing the Product
Roadmap, Release Plan, and Sprint Backlog.
Backlog Estimation

8. 8© All Rights Reserved
Do Not Duplicate
• Agreement between Development Team and Product Owner on
what needs to be completed for each user story
• Works in which environment and at what level of integration?
• Which tests have been passed?
› Unit
› Functional/System
› Performance/Load
› Security
• Level of Documentation?
› xDocs
› User Docs
› Maintenance Docs
• May be different for Sprints vs. Releases
Definition of Done

9. 9© All Rights Reserved
Do Not Duplicate
• An improved estimation model
› Accuracy over precision
› Mathematically valid
• Done by the Development Team members who will do
the work
• Self corrects for specific team idiosyncrasies
› Leverages Scrum’s “Apples to Apples” dynamic
› “Accelerated Reality”
• Enables more accurate long-term planning
What is Relative Estimation?

10. 10© All Rights Reserved
Do Not Duplicate
Backlog Estimation Example
• Assume:
• Remaining backlog is 500 story points
• Sprint duration is 2 weeks (1/2 month)
• Team velocity averages 20 story points per Sprint
• Today is January 1, 2012
• Team cost is $40,000 per week
• In 1 minute, calculate the approximate day of delivery and
cost of the project.
• In 30 seconds- what happens if the team increases its’
velocity to 25 story points per Sprint?

11. 11© All Rights Reserved
Do Not Duplicate
For More Information…

12. 12© All Rights Reserved
Do Not Duplicate
Thank you!

13. 13© All Rights Reserved
Do Not Duplicate
Appendix

14. 14© All Rights Reserved
Do Not Duplicate
1. Product Owner explains story
2. Each Dev Team member selects a card (don’t show
it)
3. Together, all Dev Team members show their card
4. If different, the HIGH and LOW estimators briefly
explain their choice and assumptions
5. The Product Owner provides additional information,
as necessary
6. The Dev Team iterates the process, usually up to 3
times, until consensus is reached
How to Play Estimation Poker

15. 15© All Rights Reserved
Do Not Duplicate
• The team needs to be in consensus on what it can
and can not do during a Release
• Common model:
5= LOVE IT!
4= Good idea
3= Yeah, I can support it
2= I have reservations, let’s discuss further
1= Opposed. Do not move forward
Team Consensus- Fist of Five

16. 16© All Rights Reserved
Do Not Duplicate
1. Take 1 minute and have the Development
Team agree on a single ‘small’ user story.
Repeat with XS, medium, large, XL and EPIC.
2. Take 10-30 minutes and have the Dev Team
put all remaining user stories into categories of
XS, Small, Medium, Large, XL, or EPIC.
3. Take another 10-30 minutes and have the Dev
Team review and adjust user story
categorizations as necessary.
4. Have PO review categorization
› For items that have >1 size difference, PO and Team
discuss. Team has final say on size.
Affinity Estimation

17. 17© All Rights Reserved
Do Not Duplicate
• XS= 1 point
• Small= 2 points
• Medium= 3 points
• Large= 5 points
• XL= 8 points
• EPIC= Product Owner needs to break down
17
Affinity Quantification