The document discusses estimating user stories in Agile software development. It defines user stories and estimates, and explains why estimating is important despite criticisms. Planning Poker is presented as a technique for teams to estimate stories together. If estimates are tracked over time, a team's velocity can be calculated and used to estimate release dates based on the team's average delivery of story points per sprint.
3. About Stephane
• Consultant for banks, insurances, European
institutions &SMEs
• Java Architect (16+) & Agile Practionner (7+)
• Co-founder of Arexo Consulting
stephane.rondal@arexo.be
@stephanerondal
05/05/09 www.agiletour.com
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 Planning
05/05/09 www.agiletour.com
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 www.agiletour.com
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 Testable
05/05/09 www.agiletour.com
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 www.agiletour.com
9. Definition of Done
Source: http://www.scrumalliance.org/articles/106-definition-of-done-a-reference
05/05/09 www.agiletour.com
10. Why Should You Estimate User Stories
• Your boss wantsyou
to!
• Whenwillthisthingber
eady?
05/05/09 www.agiletour.com
11. Why Should You Estimate User Stories
• What can I buy for this price?
05/05/09 www.agiletour.com
12. Why Should You Estimate User Stories
• Buy yourself some credibility
05/05/09 www.agiletour.com
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 : http://www.estherderby.com/2012/03/estimating-is-often-helpful-estimates-are-often-not.html
05/05/09 www.agiletour.com
14. Estimatingisdifficult.
The more you do it, the betteryou’llgetatit.
05/05/09 www.agiletour.com
15. What’s all the Bad Fuss About Estimations
05/05/09 www.agiletour.com
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 : http://www.estherderby.com/2012/03/estimating-is-often-helpful-estimates-are-often-not.html
05/05/09 www.agiletour.com
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 lunch
05/05/09 www.agiletour.com
18. How to Estimate User Stories
• Demystify the
black art…
05/05/09 www.agiletour.com
19. How to Estimate User Stories
Scrum recommends a technique called
Planning Poker
05/05/09 www.agiletour.com
20. Planning Poker
Get your team together, you want everybody to
participate
05/05/09 www.agiletour.com
21. Planning Poker
Grab the top priority user
stories from your
backlog
Source: http://www.informit.com/articles/article.aspx?p=1928232
05/05/09 www.agiletour.com
22. Planning Poker
For each story
o Be time-boxed
o (Re-) present the user story,
briefly
o Then…
05/05/09 www.agiletour.com
23. Planning Poker
Step 1 - Reflection Time (individual)
Source: http://www.crisp.se/bocker-och-produkter/planning-poker
05/05/09 www.agiletour.com
25. Planning Poker
Step 3 – Repeat until convergence
Source: http://www.crisp.se/bocker-och-produkter/planning-poker
05/05/09 www.agiletour.com
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 estimations
05/05/09 www.agiletour.com
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 www.agiletour.com
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 www.agiletour.com
29. Velocity
• How many story points
were actually delivered
at the end
of the sprint?
05/05/09 www.agiletour.com
31. Estimating the Release Date
Assuming there are 5 iterations left
At our worst velocity, we’ll reach 5x14 SP
At an average velocity, we’ll reach 5x16,5 SP
At our best velocity, we’ll reach 5x19 SP
05/05/09 www.agiletour.com
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 21st
Source: http://www.mountaingoatsoftware.com/
05/05/09 www.agiletour.com
33. When to Estimate
Product PrioritizedBacklo
g
Backlog Release Sprintplanni
planning ng
Sprint
Backlog
Vision
Retrospective
Planning 2
Sprint
BacklogTasks
Sprint Review Daily Meetings
05/05/09 www.agiletour.com
34. Where to Estimate
• Online: www.planningpoker.com
• Within most Agile project managment tools
• At a table, using cards
05/05/09 www.agiletour.com
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
better
05/05/09 www.agiletour.com
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
