Agile Estimation Accuracy by Mark Layton presented PMI-OC dinner meeting Aug13 V2

Agile Estimation

2© All Rights Reserved

Do Not Duplicate

Fundamental Paradigm Shift

3© All Rights Reserved

Do Not Duplicate

Approach Comparison

4© All Rights Reserved

Do Not Duplicate

A Holistic View

5© All Rights Reserved

Do Not Duplicate

Simplified Scrum Overview

6© All Rights Reserved

Do Not Duplicate

Product Backlog Darwinism

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© 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© 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© 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© All Rights Reserved

Do Not Duplicate

For More Information…

12© All Rights Reserved

Do Not Duplicate

Thank you!

13© All Rights Reserved

Do Not Duplicate

Appendix

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