Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Estimation & Capacity Planning


Published on

This presentation includes an overview of the various estimation techniques used in Agile projects. I've also put in a slide for explaining the importance of business value for Agile requirements. A simple mechanism on capacity planning before weaving it all together to come up with a reasonably foolproof plan.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Agile Estimation & Capacity Planning

  2. 2. FOREWORD This presentation is a case representation of an estimation and capacity planning technique that has evolved and worked for me successfully across several projects. Although there might be some parts of this representation that might stretch beyond the boundaries of the Agile way, it embodies a working strategy to tackle estimation and capacity planning for Agile teams. To provide a holistic background various techniques and terminologies are also touched upon along with a few basics.
  3. 3. WHY ESTIMATE?  Estimates allow us to predict when a Sprint Goal will be met, and therefore when a substantial increment of value will be delivered  Estimates help our stakeholders plan ahead. They are part of the value we provide  Estimates help us to de-risk scope of uncertain size and complexity  Estimated work can be traded in and out of scope for other work of similar size. Without estimates you can't trade  The very process of estimation adds value. When we estimate we discuss requirements in more detail, and gain a better understanding of what is needed
  4. 4. ESTIMATE EFFORT OR SIZE? Consider this example that I like to give on this topic. You have to . In the past you know that , so you estimate . When you open the tap the water is trickling as opposed to gushing down as before! There goes your estimation down the drain! Consider having estimated the same as – It would take . You have moved from effort based to size based estimation. In the given circumstances your estimation still holds good!
  5. 5. WAYS TO ESTIMATE  Old school – Effort in hours with support of the many estimation techniques. Also helps during the initial ballpark estimate  Story Points - Done using relative sizing by comparing one story with a sample set of previously sized stories. Relative sizing across stories tends to be much more accurate over a larger sample, than trying to estimate each individual story for the effort involved. T-Shirt sizing (S, M, L, XL) and Fibonacci series (1,3,5,8) can be used as points  Story count - Discuss scope in terms of projected number of stories we think we can do (forget points) and put rules around the maximum duration of a story. Fairly even sized stories are ideal  Hybrid – Story count / points for size and effort estimation on the tasks required to implement the story. In this case the Sprint burn down would consider effort burn down and the Sprint Velocity would be calculated using Story count / Story Points
  6. 6. BUSINESS VALUE  The intrinsic value that is contained in a user story. Could be measured in points, whole numbers, size, et all.  Is it a good idea? In general terms – Yes, but not always possible  A tricky idea to assign value to a user story  Value of small bits of functionality are often intertwined  Value of a small bit of functionality can often be said to be the total value of the product. E.g. right wheel of a car, a highly critical bug in a product  Shared cost of implementation could lead to incorrect ROI decisions  A good idea to assign a value to an EPIC rather than a user story
  7. 7. CAPACITY PLANNING Name Work (days) Training Vacation Others Available (days) Available (hours) Sheldon 10 0 0 0 10 70 Rajesh 10 0 1 0 9 63 Leonard 10 0 0 0 10 70 Howard 10 1 0 0 9 63 Penny 10 0 3 0 7 49 Total Avaialble hours 315 Sprint 1.2 Sprint Start Date 16 February 2013 Sprint End Date 02 March 2013 Plan 7 hours We’ll use this soon! A basic capacity planning chart
  8. 8. PUTTING IT ALL TOGETHER Pull the highest order user story from the Product Backlog into the Sprint Backlog (Remember these have been sized before) Create the tasks required to implement the user story and estimate the effort. Preferably have tasks less than 7 hours (the time considered during capacity planning) but no crime if you can’t! Check if the sum of the efforts on all the tasks is less than the “Total Available Hours”. If yes, repeat steps 1-3. Do not add a user story to the Sprint Backlog if it’s causes the total implementation effort to be > 4 hours of the “Total Available Hours” Cross check your plan with checking if the size of the user stories matches roughly to your team’s Sprint Velocity Some teams might also want to nominate themselves for tasks upfront rather than pulling tasks one after another. In such a case, the individual’s available hours can be used as a reference to check over commitment
  9. 9. REFERENCES AND VOTE OF THANKS  Ian Mitchell - Agile Estimation in Practice  Martin Fowler - How do you estimate on an Agile project?" by Martin Folwer and ThoughtWorks  Succeeding with Agile - Mike Cohn's Blog  Thomas Botton - Key Dimensions of User Stories