This document provides information about agile estimation techniques, including story points and planning poker. It discusses how story points are used to provide relative estimates of complexity rather than time estimates. Planning poker is described as a consensus-based technique where a team privately selects story point cards before discussing to reach agreement. The document also covers insights around how additional details don't necessarily lead to better estimates and how past sprint performance can inform long-term planning estimates. Common questions about estimation techniques are addressed.
6. What’s a story point?
“An estimate of relative complexity of a user story”
It is a unitless number, but still a useful number
Story Points
7. Most commonly used estimating unit in Scrum teams
Factors involved
Volume: How much is there?
Complexity: How hard it is?
Uncertainty: What’s NOT known? What’s known?
Story Points
8. 1. Forces the use of relative estimating
There are studies that show that we’re better at this (1)
2. Focuses on estimating size, not duration
We can derive duration empirically
3. Unlike time estimates, it puts estimates in units that we
can add together
A 10-point user story is expected to take twice as long as a 5-points user
3 Key Advantages
(1) https://www.google.com.vn/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwjVn6GawK7OAhUFk5QKHfGXAwoQFggpMAI&url=https%3A%2F%2Fwww.simula.no%2Ffile%2Fsim
ulasimula814pdf%2Fdownload&usg=AFQjCNHkTpakk2JSFS--CGpwiqn6hoSdBw&sig2=x-5y_uQlXbl1LSzZCCvq0g&bvm=bv.129391328,d.dGo
15. 1. Group A
Given project spec
2. Group B
Given the same spec but with estimation
irrelevant details
List of users
List of passwords
Some Insights about estimations
1. 20 hours
2. 39 hours
16. 1. Group A
Given a 1-page project spec
2. Group B
Given a 7-pages project spec
Double line space
Margins
Some Insights about estimations
1. 117 hours
2. 173 hours
17. 1. Group A
Given requirements R1-R4
2. Group B
Given requirements R1-R5
3. Group C
Some Insights about estimations
1. 4 hours
2. 4 hours
3. 8 hours
18. 1. Group A
Given project spec
2. Group B
Given project spec
Customer thinks it’ll take 500 hours
Some Insights about estimations
1. 456 hours
2. 555 hours
3. 96 hours
19. More information will not always provide better estimations
Estimations get influenced very easily by external factors
Some Insights about estimations
22. 1. PO explains the User Story
2. Q&A (3 mins)
3. Each team member selects card and shows
4. High and low explain and discuss
If more than 2/3 minutes —> Revote
Converges after 2-3 rounds
Planning Poker
27. People doing the work, estimate the work
Estimators are required to justify estimates
Estimates are constrained to a set of values
So we don’t waste time in meaningless arguments
Group discussions lead to better estimates
Emphasizes relative instead of absolute estimates
Planning Poker - Why does it work?
30. Long-term Planning
y=27.3xy=38.3x
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
Less priority
31. Long-term Planning
y=27.3xy=38.3x
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
User story
Less priority
34. FAQ
What if my team is remote?
https://www.planningpoker.com/
35. FAQ
What if the story is not clear yet?
What part is missing?
Play with the uncertainty
part
Assume the worst
scenario
36. FAQ
What if there are dependencies?
Can you join dependent stories
into a bigger story?
Can you create one story for the
common work and STILL add
value?
Do 2 estimations for the
dependent stories:
5 if done first
2 if done later
41. Agile Estimation, Mike Cohn -
https://www.youtube.com/watch?v=fb9Rzyi8b90
Agile Product Ownership in a Nutshell -
https://www.youtube.com/watch?v=502ILHjX9EE
https://www.simula.no/publications
References
Hinweis der Redaktion
Zoom x3
My name is Pedro and I am currently Scrum Master at TINYpulse
Been working with 3 teams so far
One of the most difficult part is to understand points
You don´t like your manager
We have the deadlines - it´s stressing
From SW dev to FOOD & Beverages
You start as a waiter
Your boss comes
“I need you to tell me how long you need to move all these glasses
Can you come back in 10 mins?”
You need a tool → TRAY
Have an estimation of how many trays is that
After 30 minutes, see how many trips you have you done
→ Calculation
Why did we do that this way? → We inspect first, and adapt
What’s a story point?
“An estimate of relative complexity of a user story”
It compares how much you thought you can finish VS how much you actually finish
Estimate is not a commitment
Volume → High intensity tasks (like localization)
Complexity → Number of cases, possible interactions, many user profiles
Uncertainty → We don’t need all details
Best estimators are QA → Because they focus on complexity of the story, and not SPECIFIC TASKS
Human being tends to be optimistic
Just like the trips for the waiter before
Why can’t we add hours estimates? Elaborate
Because it makes people think that it will be done in X weeks
It doesn’t factor in side effects (like events, bank holidays, etc.)
80 hours → 2 weeks
Explain the example of 2 runners making a 5 kms trial
In 10 mins / 15 mins
The important point is the AGREEMENT
Split into groups - 3 minutes
2 Rounds
How many times is Portugal contained in Spain?
KM2
RELATIVE
Who got around +- 20,000
Who got 5?
Talk about Simula company
Norwegian company
Joke about the estimation by kilos from spec book
B - Maybe no work involved
C - Buffer for later requirements
And the funniest thing is that they were asked if the customer estimation influenced them
That’s how it works normally
When the team is discussing a LONG TIME , getting LARGE and LARGE
Stop and ask,
“What’s the simplest version that can possibly work?”
Capture that simple version as its own story
Break out all the variations and complexities into their own stories.
Mike Conh wanted to challenge their teams about ways of estimations
They started using just numbers
They complained about long discussions 14 or 15???
One came up with the idea that they don’t use those numbers
Long discussions
Then the numbers would be considered like buckets → Implicit buffer
But the buffers were too big specially for big numbers
A bucket of 13 kilos can hold 14-15 kilos of sand
Because a PO asked why a 21 specifically → You must be into something!
Because fibonacci! → (fibo what?)
For more EXPERIENCED teams
As a PO, you can get 2 questions
When will I get THIS done?
What will be done by the end of sprint 7?
If you get these stories too frequently, you should ask if your team is really cross-functional
Talk about mobile guys in the team
PO can’t just go and say “Make this part better”
But there are other cases like design tweaks that you can still assume the worst
McDonalds has burguer for 5$, and chips for 3$
However the Combo is 7$
Present stories
Let the team sort them by the swimlames
Story triangulation
I hope this can improve your teams doing estimations
Talk about all my learnings