Relative Estimation: Exercises & Illustrations

Relative Estimation
Exercises & Illustrations
David Hanson
dphanson63@yahoo.com
https://www.linkedin.com/in/david-hanson/
https://www.slideshare.net/DavidHanson5
May 2023 David Hanson | ANE 101

2
Why estimate user stories using poker planning? What’s the advantage of
relative estimation? Why leverage Fibonacci series?
This session will explore the reasons for relative estimation using Fibonacci
through a collection of exercises and illustrations.
Session assumes a basic understanding of user stories and poker planning.
David has been explaining why poker planning, why relative estimation, and
why Fibonacci to his teams since adopting user stories in 2008 and poker
planning in 2013.
David is currently an Agile coach at Mass General Brigham.
Relative Estimation: Exercises & Illustrations
David Hanson
dphanson63@yahoo.com | https://www.linkedin.com/in/david-hanson/ | https://www.slideshare.net/DavidHanson5
David Hanson | ANE 101

3
About the presentation…
During a recent training on effort & sizing a
colleague introduced me to Weber’s Law which got
me thinking. Such a simple concept should be easy
to illustrate and to test the validity. That followed
with other potential exercises to engage the
audience and test their current understanding.
The end result was this collection of exercises and
illustrations, with some additional commentary for
background and common understanding.
Hope you find value and enjoy the material.
About me, about you…
I’ve been sizing stories using Fibonacci for more
than a decade. I have found that many team
members in backlog refinement just go along, not
realizing why we play poker planning, use story
points, and leverage Fibonacci. I’m always trying to
reinforce why we do what we do, and that
everything has a reason.
What’s your experience with user stories, poker
planning, and story points? Why did you choose to
attend a session on relative estimation?

4
Assumes basic understanding of user stories
Covers all the work from ready to done to deliver
value to the customer.
Assumes basic knowledge of poker planning
Most common technique for estimating relative
effort and complexity of a user story.
As a <who>, I
need|want <what>,
so that <why>.

5
Introduction
True or False
Weber’s Law
Font Size
Other Reasons
Relative Contribution
Why Point?
Appendix:
Fruit Salad
Additional Commentary
Poker Planning

6
True or False
1. Fibonacci series is 0-1-1-2-3-5-8-13-21-34-55…
2. A popular alternative for pointing is 0 ½ 1 2 3 5 8 13 20 40 100, called the Modified Fibonacci.
3. 1 point usually equates to 1 day or 1 hour depending on the team's working agreement.
4. Points account for both effort and duration.
5. Points account for effort, but not complexity or risk, because complexity and risk cannot be measured.
6. Points track all work done by your team plus work done by those outside your team.
7. Effort and sizing is restricted to the Backlog Refinement event.
8. Team can repoint previously pointed story during Sprint Planning.
9. Poker planning using Fibonacci leads to less precise yet more accurate estimation.
10.If the estimates during poker planning vary widely, then ignore the outliers and take an average so the
story can be marked Ready.

7
More True or False
Bonus: Did I make it up or did I witness this usage?
1. When pointing, make sure to include effort already spent to get the story to Ready, to get full credit for the story.
2. Set really complex stories to an upper bound of 13, since that will be the maximum credit for any story.
3. The team member likely to lead the story should point first, then other team members should point to show
agreement or suggest alternative.
4. The most productive team members should point low and the least productive team members should point high.
5. During poker planning, the person who bids the lowest points should be awarded the story and assigned the PBI.
6. During poker planning, each person points only their effort, and then the Scrum master sums the effort for each
person, to set the total story point value.
7. Once the story is completed, repoint the story to reflect the actual effort, if the estimate was not accurate.
8. Points for the interrupt buffer should be set at the end of the sprint.
9. If story rolls over, then repoint story for remaining work and discard points for completed work.
10. During poker planning, simply take the average, to avoid pointless conversation and needless consensus, which
could lead to a shared understanding and a collective commitment.

Why relative estimation?
Why Fibonacci?

9
Weber’s Law
A baby that gains 10 pounds might double in size, while the adult that looses 10 pounds might
wonder why nobody noticed.
It’s relative.

10
A
C
X Z
Which two are the same size?

11
1
2
9 8.5
Which two are the same size?
Actual sizes

12
What are the relative sizes:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Hint: smallest is 1

13
What are the relative sizes:
1, 2, 3, 5, 8, 13
Close enough is good enough

14
1
2
8
8
3
8
Estimated sizes:
1, 3, 2, 8, 8, 8 or 13
My prediction of your responses

15
1
2
9
8
3
10
Actual sizes:
1, 3, 2, 9, 8, 10

16
1
2
5
8
3
13
Fibonacci sizes:
1, 2, 3, 5, 8, 13

18
8
8 = 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1
1 1
1 1
1
1
1
1
=
8

19
21
21 13
8
5
3
Fibonacci sizes: another look
2
1
13
8
5
3
2
1

20
10
9
8
7
6
5
4
3
2
1
Fibonacci compared to an incremental difference of 1 unit
13
8
5
3
2
1

21
Actual Size
The actual size, from your viewpoint, I don’t know.
The actual size of each square varies from person to person, depending on the size of
each person’s monitor and window.
Yet the relative size of each square is independent of the person.
When printed, the actual size of the smallest square is 1 square inches.
So, what is the actual printed size of the those that were 8 points?

23
Font Size
10 20 30 40 50 60 70 80 90 100
10 20 30 50 80 130
First options favors precision, second option favors accuracy.

24
ABC
JKL
DEF
MNO
GHI
PQR
What’s the font size? Be precise.
Estimate as 10, 20, 30, 40, 50, 60, 70, 80, 90, or 100 points

25
IJK
RST
LMN
UVW
OPQ
XYZ
What’s the font size? Be accurate.
Estimate as 10, 20, 30, 50, 80, or 130 points

26
90
20
30
80
70
45
The font sizes were:
In case you were curious.

27
How many pixels or mm is a point?
Despite desktop publishing standards, depends on whether you’re
Team Calibri or Team Georgia!
20 point Georgia
20 point Calibri
20 point Arial
20 point Times New Roman
20 point Courier New
20 point Parchment
20 point Wide Latin
Font Sizes
https://en.wikipedia.org/wiki/Point_(typography) includes history and current standard defining 1 point as 1/12 pica or 1/72 inch.

28
There’s more reasoning to using
Fibonacci for relative estimation
than just Weber’s Law

29
13
13
Larger Effort, Larger Uncertainty
Product Owner, Team Members, Scrum Master
User needs
this or that
for one thing or
another
Big…
Risky…
10 11
14
13
Fibonacci:
choose 8 or 13
Definitely
larger than 8
Let’s split

30
Once Split…
Don’t be surprised if once split that 13 point story results in multiple stories totaling 21 or more points!
As the story is decomposed inevitably hidden effort, complexity, and value are revealed.
User needs
this or that
for one thing or
another
13
User wants
this
for another thing
User wants
this and that
for something else
User wants
that
for one thing
2 2
5
User needs
this
for one thing
User needs
that
for another thing
8 8

31
Estimation is hard; don’t pretend to be precise.
How much time did you spend in your previous meeting? Probably accurate, possibly precise.
How much time did your team spend in your previous team meeting? Possibly accurate, unlikely precise.
How much time did you spend in all your meetings last Monday?
How much time did your team spend in meetings last sprint?
These are all knowable, yet even estimating a past activity is difficult. You might be accurate, but without
help you won’t be precise.
If the past is difficult to estimate, then certainly the future is even harder to estimate.

32
Relative estimation, collective
commitment, balanced workload
How can workload be balanced when some members work faster, and others need more time?

33
1
5
3 1
2
2
2
5
3
1
3
2
10
6
4
6
4

35
The low estimate helps find the
opportunities that might make
the story simple.
A user story is a conversation
starter. Poker planning is a
framework for structuring the
conversation.
The high estimate helps find the
risks that might make the story
complex.
Opportunity Shared Understanding Risk
Not Converging
If team doesn’t converge on an estimate, then declare the story not ready. The product owner should work to clarify
the ask or the team should add a spike to research the unknowns.
What’s the point of poker planning?

36
Conclusion
So, what did you think?
Anything resonate with you?
What would you like to review next?

37
David Hanson
dphanson63@yahoo.com
https://www.linkedin.com/in/david-hanson/
https://www.slideshare.net/DavidHanson5
ANE 101 Survey
https://www.surveymonkey.com/r/FTRT52C

Appendix
Exercise: Fruit Salad
When PBIs are not stories
First, is it a bug?
T-shirts
A little (of my) history
Spirals in science and math
Background: Poker Planning

39
Fruit Salad
As the pot lock party attendee nominated to bring fruit salad, I want to provide an eclectic and
inviting fruit salad, so that the compulsory fruit salad is not ignored.
Estimate relative effort to shop for and prepare the following fruits.

40
1 – 2 – 3 – 5 – 8 – 13 – 21 – 34 – 55

41
Have we at times
overestimated the
simple?
Have we at times
underestimated the
complex?
Over Under
1 durian covered by 89 blueberry triplets
David Hanson | ANE

42
Thanks to the collective inputs of the team during backlog
refinement, the fruit salad story takes a different angle:
As the pot lock party attendee nominated to bring fruit
salad, I want to provide an inviting and fresh fruit salad
using only local ingredients with whip cream on the side,
so that the compulsory fruit salad is not ignored.
Refined Fruit Salad
Berries icons created by ultimatearm – Flaticon
Whipped cream icons created by mynamepong - Flaticon

44
User Stories vs. Task-based PBIs
Story point estimation is intended to be used with user stories. In this case, the estimate is all the work
from ready to done to deliver usable value to the customer.
A PBI when written as a user story from the customer’s perspective, normally involves design, coding,
testing, and therefore represents work for multiple team members.
If your team has task-based PBIs instead of user stories, then arguably the individual owning the task
should own the estimate.
If you have task-based PBIs, you might ask what would it take to adopt user stories, before worrying about
pointing.
Task-based PBIs are widespread at my organization. Is that also the case at your organization?

45
If the defect is found during the
sprint, then this can be tracked as
a task under the story.
The original estimate should
account for mistakes found during
the sprint.
That’s why we design, code and
test.
Frequently during UAT, users
discover new, missed or changed
requirements.
If the original acceptance criteria
are still passing, then this is not a
defect.
Track this ask as a new story and
point accordingly.
Escaped defects found during UAT
or in production should be
tracked as Bugs.
Either revert the story from Done
to Doing or log an independent
Bug.
Either way the Bug is not pointed.
Bug is a Task Bug is a Story Bug is a Defect
Consider a UAT buffer to address some
limited feedback ASAP.
Velocity will be lower, which is good.
Slow down for better quality.
Some tools allow tracking bugs like
tasks, if you insist on labeling as bug.
Should bugs be pointed?
First, is the bug a defect, a task, or a story?

46
T-shirt Sizing
Don't T-shirt size unless you find a compelling need.
If you do T-shirt size do so for only roughly defined newer work (no need to be ready) or early
placeholder epics.
Consider T-shirts as doubling in size (unlike actual T-shirts which vary in size by only 10%):
4XS = 2S = 1M = ½L = ¼XL
Leverage affinity mapping and size many epics at a time.
T-shirt sizing should take maybe a couple minutes per item.
T-shirt sizing will be neither precise nor accurate!

47
A Little History
Before poker planning and relative estimation…
Story points started with ideal days. An ideal day was defined as 6 hours of uninterrupted work for an
average team member. (We didn’t define average.)
Then teams could track the actual amount of work completed in a week. Typically, teams found the
actual work took 2 to 3 times their estimate. They called this the load factor.
Actual time = load factor * ideal days
You’ll hear me call this the Rule of p. Make a good faith estimate and multiply by p. That’s about how
long it will take.
Realistic estimate = good faith estimate * p
And The Rule of p Credit to James Michael Ryan who introduced me to his estimation “Rule of p” in 1999.

49
In Nature In Math
Spirals
Source: https://en.wikipedia.org/wiki/Patterns_in_nature
Each cell is n x n or n2

50
Poker Planning

51
Most common Agile estimation technique
Leverages Fibonacci series: 1, 2, 3, 5, 8, 13, 21
Team initially establishes some very simple
benchmark story as 1 pointer
A relative estimation of complexity and effort
A 2-pointer is twice as hard as a 1-pointer
Team very quickly “knows” the relative sizes
against the baseline stories
What How
PO reviews story with team
Team asks questions and PO responds
SM asks if ready to estimate
Team members each select a Fibonacci number
SM asks team members to reveal estimates
SM asks one low and one high to comment why
consider simpler or more complex
PO may provide more information
SM asks team to re-estimate
If team converges then story pointed
Else story not ready
Poker Planning
Agile New England | David Hanson
PO: Product Owner
SM: Scrum Master

Relative Estimation: Exercises & Illustrations

Relative Estimation: Exercises & Illustrations

More Related Content

What's hot (20)

Similar to Relative Estimation: Exercises & Illustrations (20)

More from David Hanson (13)

Recently uploaded (20)

Relative Estimation: Exercises & Illustrations

Editor's Notes