• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Estimation Accuracy by Mark Layton presented PMI-OC dinner meeting Aug13 V2
 

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

on

  • 335 views

 

Statistics

Views

Total Views
335
Views on SlideShare
334
Embed Views
1

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 1

https://twitter.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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