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