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


Do Not Duplicate

Approach Comparison


Do Not Duplicate

A Holistic View


Do Not Duplicate

Simplified Scrum Overview


Do Not Duplicate

Product Backlog Darwinism


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


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


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?


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?


Do Not Duplicate

For More Information…


Do Not Duplicate

Thank you!


Do Not Duplicate

Appendix


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


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


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


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

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

Business

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