Agile Estimation


Published on

We’re agile, so we don’t have to estimate and have no deadlines, right? Wrong! This session will review the problem with estimations in projects today and then give an overview of the concept of agile estimation and the notion of re-estimation. We’ll learn about user stories, story points, team velocity, and how to apply them all to estimation and iterative re-estimation. We will take a look at the cone of uncertainty and how to use it to your advantage. We’ll then take a look at the tools we will use for Agile Estimation, including planning poker, Visual Studio TFS and much more.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Estimation

  1. 1. Agile Est timationStephen Fortestevef@orcsweb.com
  2. 2. BioBiChief Strategy Officer of Telerik gyCertified Scrum MasterActive in the Community: International Conference Spea aker for 12+ Years RD, MVP and INETA Speaker    Co‐moderator & founder of N d f d f NYC .NET  Developers Group   http://ww Wrote a few books: SQL Serve er 2008 Developers Guide (MS Press)MBA from the City University of   New YorkPast: CTO and co‐Founder of Corze en, Inc. (TXV: WAN) CTO of Zagat Survey 
  3. 3. gAgendaThe Estimation ProblemAgile EstimationToolsQ&A
  4. 4. gAgendaThe Estimation ProblemAgile EstimationTools Q&A
  5. 5. Estimation  Wikipedia: Estimation is th   he calculated approximation of a result which is usable e  even if input data may be  incomplete or uncertain. Problem is that estimates becom me a unbreakable schedule, where  me a unbreakable schedule  where  any deviation is considered bad d
  6. 6. Problem #1 with h Estimates Estimate for our project: 1 month for design and archit t   th f  d i   d  chitecture 4 months for developmen nt  1 month for testing   h f   i Scenario: Your first estimate is wron ng by 1 week (design) What do you do?
  7. 7. The Estimation P Problem When you come up with a   project idea, your first  estimate is off by +/ 4x Not enough details are kn nown Traditionally too much tim  i   T diti ll  t   h time is spent on building a  t   b ildi     specification which is not c  complete  Again, not enough details   k A i   t  h d t ils are known As time progresses, more d  details emerge about the  system and its details t   d it  d t il The cone of uncertainty 
  8. 8. yThe Cone of Uncertainty c
  9. 9. Real life story From in .com bo oom Project was “late” due to no j o re‐estimation and  emerging requirements Daily status meeting with C y g  CEO on the MS Project plan j p Patrick has 5 tasks for this w  week, each estimated for 1  day each Patrick comes to you and s says I am going to spend 3  days writing a code gen uti y y g g ility and one day testing it  y g then on Friday, all of my ta asks will be done with a  button push Try explaining that to  the C  CEO!
  10. 10. gAgendaThe Estimation ProblemAgile EstimationToolsQ&A
  11. 11. gAgile Estimation n Wikipedia: Estimation is th   he calculated  approximation of a result t which is usable even if  input data may be incompl lete or uncertain. Problem is that estimates   become a unbreakable  schedule, where any deviaation is considered bad Agile Estimation throws th his logic away and always re‐ his logic away and always re estimates a project after ea ach iteration Different value system, de Different value system  de eviations are not deviations,  eviations are not deviations   they are more accurate est timations Uses the cone of uncertain nty to your advantage
  12. 12. How to Estimate e User Stories Planning Poker Pl i  P k Story Points Product Backlog Velocity Re‐estimation
  13. 13. User Stories Users break down the func ctionality into “User Stories” User Stories are kept small U  S i    k   ll User Stories include accepttance criteria
  14. 14. gPlanning Poker After all the user stories are e written, get a list of stories  and do a high level estimat te Estimate is for setting prio orities, not schedule NOT a time based estimati NOT   ti  b d  ti ti   ion  i Super hard, Hard, Medium m, Easy, Super easy Done by consensus  To get there you play planning poker Why? No pressure.
  15. 15. yStory Points Break down user stories to   units of relative size  So you can compare featur S        f t res Alternative to time Story Points are not a meas S   i         surement of duration, but    f d i  b   rather a measurement of si ize/complexity Start with 1 standard featur re and then other features  are either 1x, 2x, etc larger o  or smaller than that relative  feature in size/complexity  f t  i   i / l it  
  16. 16. Product Backlog g All story points are put into o a bucket This represents all of the ta k  f   h   j  ( Thi     ll  f  h   asks for the project (work  k  items) Backlog will have an item a d i   i B kl   ill h    i  and its estimate   Remember this estimate is   s not time based, but point  based b d Backlog can also contain th he priority
  17. 17. A sample product backlogA sample product backlog Backlog item m Estimate Allow a guest to make a rese ervation 3 As a guest, I want to cancel   a reservation. 5 As a guest, I want to changee the dates of a  3 reservation. As a hotel employee, I can r  run RevPAR 8 reports (revenue‐per‐availaable‐room) Improve exception handling g 8 ... 7 Total 50
  18. 18. pSprint 1 Developers will commit to   XX story points Warning, they will usually  W i   h   ill  ll    over commit   i After the end of sprint 1, yo ou have your first velocity  number  b  
  19. 19. yTeam Velocity  Velocity is the number of s  story points per sprint  completed You calculate velocity to prredict how much work to  commit to in a sprint Velocity only works if you e  estimate your story points  consistency  consistenc   Over time you will know: t team has a velocity of 32  story points per sprint t   i t    i t Over time this will self‐correct Over time you will be able    di   h   j   O  i     ill b   ble to predict the project  schedule (and release)
  20. 20. gCalculating Team y m Velocity Select a regular time periodd (sprint) over which to  measure Velocity Add up the story point estiimates 100% completed At the end of the sprint, th A   h   d  f  h   i   h  fihe figure you have is your     h  i     Velocity You can then use your Velo h locity as a basis for your  b f future commitments
  21. 21. yVelocity Charts True way to see the health of a project  
  22. 22. Re‐estimation As you complete more spri ints, your velocity will  change Velocity changes because   of minor inconsistencies in  the story point estimates Team velocity will typicall ly stabilize between 3 and 6  iterations Re‐estimation of the entire e project happens after each  sprint New Velocity New story points added an nd removed (completed) Use the cone!
  23. 23. gAgendaThe Estimation ProblemAgile EstimationToolsQ&A
  24. 24. Tons of Tools I prefer user stories to be on paper Can transcribe to Excel C  t ib  t  E l Do NOT create VSTS work k items until you have all of  the user stories estimated
  25. 25. Visual Studio Tea y am System Scrum templates Story points become work  S   i  b   k   items  i
  26. 26. gAgendaThe Estimation ProblemAgile EstimationToolsQ&A
  27. 27. Questions? Questions?
  28. 28. Reading ListR di LiBooks I have read and recomB k  I h   d  d  mmend:d User Stories Applied by Mike e Cohn Agile Estimating and Plannin by Mike Cohn ng Agile Retrospectives by Esthe er Derby and Diana Larsen