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.

1. AGILE ESTIMATION
& CAPACITY
PLANNING
Mazhar Khan

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. 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. 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. 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. 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. 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. 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. 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