Agile Tour Brussels 2012 - Estimating user stories


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • personally , if I was to invest all my savings in a software development project, I’d require to know upfront how long it would take/how much it would cost
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Explain why “everybody”
  • Agile Tour Brussels 2012 - Estimating user stories

    1. 1. Estimating User Stories Learning Why and How Stephane Rondal Arexo Consulting 2012 October
    2. 2. Grabsome free food05/05/09
    3. 3. About Stephane • Consultant for banks, insurances, European institutions &SMEs • Java Architect (16+) & Agile Practionner (7+) • Co-founder of Arexo Consulting @stephanerondal05/05/09
    4. 4. In this Talk, You’llLearn About• Definitions of User Stories, Estimations• WhyShould You Estimate User Stories• The Bad Sides of Estimations• How To Estimate (Planning Poker)• Velocity• Release Planning05/05/09
    5. 5. Recommended Reading05/05/09
    6. 6. Whatis a User Story• A user story is a very slim and high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.05/05/09
    7. 7. Whatis a User Story• Good User Stories are o Focused on features, not tasks o Independent o Negotiable o Valuable o Small ( <= 1 sprint/iteration) o Testable05/05/09
    8. 8. Whatis an Estimate• The approximate amount of effort required to achieve a user story• Called story points• Achieve = Done (Done Done Done)05/05/09
    9. 9. Definition of Done Source:
    10. 10. Why Should You Estimate User Stories • Your boss wantsyou to! • Whenwillthisthingber eady?05/05/09
    11. 11. Why Should You Estimate User Stories• What can I buy for this price?05/05/09
    12. 12. Why Should You Estimate User Stories• Buy yourself some credibility05/05/09
    13. 13. Why Should You Estimate User Stories• Group estimating reveals differences in knowledge and understanding• Finding those gaps early is helpful• But be disciplined to resist guessing and speculation. Dig deeper, understand more, then try estimating again. Source :
    14. 14. Estimatingisdifficult. The more you do it, the betteryou’llgetatit.05/05/09
    15. 15. What’s all the Bad Fuss About Estimations05/05/09
    16. 16. What’s all the Bad Fuss About Estimations• People construe estimates as promises. Failed predictions fan blame. Trust and openness suffer.• People game estimates.• People compare teams based velocity, while velocity and story points are team-dependent metrics. Source :
    17. 17. What’s all the Bad Fuss About Estimations• Most of these critics are valid• But… o Are they really questioning estimations, or just some estimation techniques? o What other alternatives do they propose? o Is your Agile practice at the same maturity level than theirs? o There’s no free lunch05/05/09
    18. 18. How to Estimate User Stories • Demystify the black art…05/05/09
    19. 19. How to Estimate User Stories Scrum recommends a technique called Planning Poker05/05/09
    20. 20. Planning Poker Get your team together, you want everybody to participate05/05/09
    21. 21. Planning Poker Grab the top priority user stories from your backlog Source:
    22. 22. Planning PokerFor each story o Be time-boxed o (Re-) present the user story, briefly o Then…05/05/09
    23. 23. Planning Poker Step 1 - Reflection Time (individual)Source: 05/05/09
    24. 24. Planning Poker Step 2 – Showdown & DiscussSource: 05/05/09
    25. 25. Planning Poker Step 3 – Repeat until convergenceSource: 05/05/09
    26. 26. Best Practices• Do not use units of time for story points• Involve all those active in the realization of the story• Baseline your estimations, what means 2 and 5 for the team• Avoid changing your baseline too often• Keep track of your estimations05/05/09
    27. 27. What’sNext• We now have a backlog with more important user stories estimated more precisely.• But how does this help us?05/05/09
    28. 28. What’sNext• How do we draw the release date?• Or how do we know what we’ll get at a certain date?05/05/09
    29. 29. Velocity• How many story points were actually delivered at the end of the sprint? 05/05/09
    30. 30. Velocity• Continue measuring velocity of each sprint Sprint Velocity Sprint #1 16 Sprint #2 18 Range: Sprint #3 14 Sprint #4 17 14-19 Sprint #5 1905/05/09
    31. 31. Estimating the Release DateAssuming there are 5 iterations leftAt our worst velocity, we’ll reach 5x14 SPAt an average velocity, we’ll reach 5x16,5 SPAt our best velocity, we’ll reach 5x19 SP05/05/09
    32. 32. Estimating the Release Date • A good plan will go from o We’ll be done in the 4th quarter o We’ll be done in November o We’ll be done in November 21stSource: 05/05/09
    33. 33. When to Estimate Product PrioritizedBacklo g Backlog Release Sprintplanni planning ng Sprint BacklogVision Retrospective Planning 2 Sprint BacklogTasks Sprint Review Daily Meetings 05/05/09
    34. 34. Where to Estimate• Online:• Within most Agile project managment tools• At a table, using cards05/05/09
    35. 35. Conclusion• Planning Poker and Velocity are not a perfect, flawless estimation techniques• Still much better than no estimation technique at all• Personally helped me gained lot of Agile experience and maturity• I recommend you use it if you have nothing better05/05/09
    36. 36. Thank You! Questions / Feedback @stephanerondal05/05/09