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.

1. Agile Est
timation
Stephen Forte
stevef@orcsweb.com
http://stephenforte.net

2. Bio
Bi
Chief Strategy Officer of Telerik
gy
Certified Scrum Master
Active 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 ww.nycdotnetdev.com
Wrote a few books: SQL Serve er 2008 Developers Guide (MS Press)
MBA from the City University of New York
Past:
CTO and co‐Founder of Corze en, Inc. (TXV: WAN)
CTO of Zagat Survey

3. g
Agenda
The Estimation Problem
Agile Estimation
Tools
Q&A

4. g
Agenda
The Estimation Problem
Agile Estimation
Tools
Q&A

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. 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. 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. y
The Cone of Uncertainty
c

9. Real life story
From Zagat.com 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. g
Agenda
The Estimation Problem
Agile Estimation
Tools
Q&A

11. g
Agile 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. How to Estimate
e
User Stories
Planning Poker
Pl i P k
Story Points
Product Backlog
Velocity
Re‐estimation

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. g
Planning 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. y
Story 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. 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. A sample product backlog
A 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. p
Sprint 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. y
Team 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. g
Calculating 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. y
Velocity Charts
True way to see the health of a project

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. g
Agenda
The Estimation Problem
Agile Estimation
Tools
Q&A

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. Visual Studio Tea y
am System
Scrum templates
Story points become work
S i b k
items
i

26. g
Agenda
The Estimation Problem
Agile Estimation
Tools
Q&A

27. Questions?
Questions?

28. Reading List
R di Li
Books I have read and recom
B 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