Ever wonder why Agile teams swear by relative estimation? My teams improved sprint planning efforts by a factor or 3, once we started using relative estimation. Without understanding Agile relative estimation, teams tend to fall back to using time-based methods. This often leads them to spend way too much time on obsolete estimates that will be made even more complex with all the unknowns and constant emergent requirements of an Agile world! “It's better to be roughly right, than precisely wrong!” ~ John Maynard Keyenes The Solution is simple: understand that relative estimation is only a rough order of magnitude estimate to quickly organize the product backlog. This empowers your product owners (PO) to quickly make value based trade-offs on backlog items and decide on what stories the team should work next. This gives the business the highest bang for their buck! PROBLEMS WITH TIME-BASED ESTIMATES -Teams spend too much time trying to get it right -Lack of confidence/experience can lead to people being either optimistic or pessimistic -Timeline you are estimating may be too far in the future -Due to long timeline, there are too many risks, unknowns, changes or dependencies! WHY USE RELATIVE ESTIMATION? -Allows a quick comparison of stories in the backlog -Allows you to select a predictable volume of work to do in a sprint -Uses a simple arbitrary scale -Allows PO to make trade-offs and take on the most valuable stories next ESTIMATION TIPS -Relative points or equivalent Tshirt sizes are used to estimate stories, leveraging the Fibonacci sequence modified for Agile. -The team estimates the story, not management nor the customer. -Story estimates account for three things: effort, complexity, and unknowns. Don’t short sell yourself by estimating effort alone, that’s where waterfall projects face issues. -Remember to estimate all Stories, user stories or technical stories. Even estimate research or discovery spikes. -Refine your backlog as a team on a continuous basis, to get your stories to meet the Definition of Ready. -Only pull into your sprint, stories that are refined and estimated. -Break down stories that are large, into smaller slivers of value to optimize your flow. -Don’t sweat it if you get it wrong, teams often do early on but improve over time.

1. Story Sizing
using
Agile Relative Estimation
Alex Kanaan

2. About Me

3. Connect with Me!
Click Button For Direct Access
More about Me http://www.alexkanaan.com
Read My Blog http://www.alexkanaan.com/#latestnews
Contact Me http://www.alexkanaan.com/#contact
Follow my Tweets @AlexKanDu
Connect on LinkedIn https://www.linkedin.com/in/arkanaan

4. Let’s Get to Know You!
• Waterfall Experience
• Agile Experience
• Beginners
• Intermediate
• Advanced
• Scrum
• Kanban
• SAFe

5. Question
How long does it take 2
PM’s to change a
lightbulb?

6. Question
How long does it take 2
PM’s to change a
lightbulb?
HINT: THINK!!!

7. Question
How long does it take 2
PM’s to change a
lightbulb?
Answer: Do you have a
plan?

8. Traditional Project Planning
Creating a project plan is simple?
Identify tasks, durations & dependencies
Find out who will do the work & estimate how long it
will take them to do it
Plug all into MS Project and voila!
So one person assigned to a task that takes
48 hours, will finish it in 6 days, right?

9. Whoa...Whose Days Look like this?*

10. Out-of-Time?
So how many hours do
you really have left to
actually do the work in
the plan?

11. Planning for an 8 hour day?
Assuming 8 hrs a day
to allocate to tasks is
not realistic!!
What should we do?

12. Problems with Traditional Estimates
We spend too much time doing/redoing it
But we rarely get it right -
Fear of failure
Lack of confidence/experience
People are either pessimistic or optimistic
Timeline may be too far into future
Many unknowns, changes, dependencies

13. Traditional Planning
So how do we estimate accurately how long
it will take to get things done?

14. Traditional Planning
So how do we estimate accurately how long
it will take to get things done?
Answer: You cannot!

15. Self-Organize & Prove the Following!
Fact: Humans stink at Estimating!

16. So, Do Estimates Work?

17. Traditional Planning
“It is better to be roughly right...
than precisely wrong”
John Maynard Keynes

18. Solution? Use Relative Estimation

19. Relative Estimation
Educated “finger-in-the-air” guess-timate that
works!!
Used in Product Backlog
Uses comparing vs deconstructing
Allows you to select a predictable volume of
work to be done in a sprint
Basis to do capacity based planning

20. Sizing - Why Relative Estimation
Uses a Simple Scale
Normalized Story Points
Quick Estimates - Sizing a story
K.I.S.S. - Keeps it Simple
It’s all relative - comparing & evaluating one
story to another

21. Sizing - Why Relative Estimation
Allows PO to make
tradeoffs
Allows you to take on
low hanging fruit first
(more valuable stories)

22. Let’s Get Started!
Let’s learn how to use
relative sizes for
comparison

23. How Much does a Terrier Weigh? (estimate)

24. No Idea?
Because we aren’t comparing it to
anything...yet!

25. So...Which Dog is Heavier?

26. Where do we fit a Golden Retriever?

27. Between Chihuahua & German Shepherd

28. Let’s Up the Challenge!
Lets use relative sizes to help us “fit” something
new to our scale below

29. Where do you fit a Terrier on the scale?

30. More or Less than a German Shephard?

31. Where on Scale?

32. More or less than a Retriever?

33. Where on Scale?

34. More or less than a Chihuahua?

35. Where on Scale?+

36. About the same as a Chihuahua

37. How Much Does a Terrier Weigh?
HINT: This is what we know
• Less than a German Shephard
• Less than a retriever
• About the same as a Chihuahua
• But...we don’t know what a Chihuahua
weighs
Can You Answer NOW?

38. What If You Had this Table?

39. Can You Answer NOW?? (estimate)
How much
does a Terrier
weigh?

40. Yes…The Terrier Weighs...
Roughly about the same as a Chihuahua, or 4-6 Ibs

42. So how does this work in Agile?
We create buckets of standard story sizes and
‘fit’ new stories in these buckets

43. Do We Include Testing in Estimates?

44. What About Deployment?

45. YES: Include it ALL!
ALL efforts in the
process are included in
the size estimate -
including any spikes

46. What is this?
1, 2, 3, 5, 8,13

47. What is this?
Modified Fibonacci Sequence
1, 2, 3, 5, 8,13
20, 40, 100, 200

48. Size is not based on effort alone
Unlike Waterfall,
when we size
stories, we do NOT
base it on effort
alone!

49. More to Size than Effort alone!
Story Point Size is based on at least
Effort Complexity Doubt

50. Effort
Doubt
Complexity
Same Effort - Different Size
5PT
Effor
t
D
C
1PT
Both stories have the same
effort, why is the estimate so
different?

51. Effor
t
Doubt
Complexit
y
Effor
t
Compl
exity
Doubt
z
Co
mpl
ex
Dou
bt
Effort
Different Efforts - Same Size
5PT 5PT5PT

52. Using T-Shirt Sizing for your buckets
Small
1pt
Medium
2-3pt
Large
5pt
Extra Large
8 Points
TOO BIG -
Break into
Smaller
Stories

53. Normalized Story Points
• Pick a 1 pointer roughly equal 1 day
• Agree with Team this is your one pointer in
terms of effort, complexity and doubt
• Compare new stories to it
• Remember to use same scale within team

54. Planning Poker
Consent based estimation technique
I don’t use it with my teams because I find
developers are much more comfortable with
giving a relative number rather than an exact
number
Mike Cohn’s Website for a good explanation

55. Do we use hours in planning?
Yes: In sprint planning where your planning
horizon is only your 2-3 weeks - sprint length

56. Remember the Mantra!
Points for Stories, Hours for Tasks!

57. Points for Stories, Hours for Tasks!
Estimate
Using
When? For What?
Stories Points Refinement Velocity
Tasks Hours Sprint
Planning
Burndown
Chart

58. Tips on Sizing
• Avoid confusion: Sizing vs Estimates
• Use Story Points - choose & stick to scale
• Break large stories to multiple small stories
• Smaller stories have less uncertainty &
easier to estimate more accurately
• Only an estimate, don’t spend too much
time
• Team sizing efforts get better with time

59. Relative Sizing Advantages
• Sprint planning in minutes not hours!
• Less Stress: Team doesn’t worry if
estimates are not spot-on
• Meeting sprint commitments starts to
improve each sprint
• We now have historical velocity that can be
used towards future planning and
accepting new projects

60. Next Steps…
If you liked my presentation, connect with me
from the next page for more ☺

61. Connect with Me!
Click Button For Direct Access
More about Me http://www.alexkanaan.com
Read My Blog http://www.alexkanaan.com/#latestnews
Contact Me http://www.alexkanaan.com/#contact
Follow my Tweets @AlexKanDu
Connect on LinkedIn https://www.linkedin.com/in/arkanaan