Revisiting Estimation

1 2 3 4 5

Here's

what’s on

tap

Estimation Fundamentals:

a quick review

1 2 3 4 5

Estimation:

the basics

Estimation determines velocity so we can pull the right amount of work into a sprint

Story points measure relative size + consider: amount of work, complexity, &

risks/uncertainties

Story points consider everything in the

definition of done

Estimation is done continuously, by the people doing the work (e.g. dev team) Story points allow team members with

different skill levels to communicate and agree on an estimate

but really, why don’t we

just use time (hours)

it’s about

striving to be

objective

• time still factored into story points, but time alone is subjective

• time involves effort,

effort differs per person • risks/unknowns not

easily captured in hours • accuracy & impact on

Here’s a quick example

“We are walking to a building and agree it will take 1

walking point to get there. You walk fast and I hobble on crutches.”

“We point to another building and agree it is twice as far away as the first building. Walking to it will take 2

walking points.”

“A third building is the same distance away as the second, but the path includes a narrow walkway over boiling

being

objective is

hard

• the point is to have the conversation; identify risks & dependencies upfront

• use velocity to measure individual output per

sprint

• BUT, if asked explicitly for hours, give hours

why do we use the

1) mathematical analysis shows exponential growth in

estimation points is better than linear

2) growth pattern found in nature; teams self-adjust to

optimize practice using it

3) distance between points is large enough for people

to make a clear distinction between sizes

Estimation:

how to

● “planning poker” - can be done with cards or fingers ● directed by Scrum Master,

everyone shows cards at the same time

● if cards are more than 3 numbers apart in

sequence, those who are “high” and “low” must

explain why, then everyone votes again

● not a debate, just a statement of reason

● consensus is necessary - average, round-up

Backlog grooming

(a.k.a “Backlog refinement”)

• Time taken out of every sprint to review & prepare backlog for

upcoming sprints

• Scrum team reviews priority items, Product Owners provide business

context

• Scrum team provides relevant technical information, breaks out &

clarifies large items, considers both business & technical concerns

• Requirements and done criteria are reviewed/discussed

• Team also estimates amount of effort to complete the priority items -

Backlog grooming

• Important to timebox the meeting as well as time spent on individual

tickets - point of diminishing returns

• Ideally, every member of Scrum team should be involved & have a

say in the discussion - ask relevant questions & provide context for estimation

• Story points refer to everything in the definition of done:

• What will it take to fully close out this story? Does the ticket need to be split?

(e.g. 8 points or more)

• e.g. QA should participate & chime in with any added complexity or

considerations for test, dev consideration of whether a tech spec or spike is needed, etc.

Building a Lego town!

• We’ve been assigned a project

to build a Lego town

• The town requires a variety of

items to be built

• Use what information is

available to determine an

estimate (relative size) of each item using Fibonacci numbers

Instructions

• Each of you should have been assigned to a team and invited

to a private Slack group (speak up if you haven’t!)

• We’ll be posting a PDF of the list of 5 required structures for

the Lego town in each channel

While on mute...

• Take the next 10 minutes to review the list with your teams

(about 2 min per item), play a mini planning poker via Slack, and come to a consensus on estimates for each item

Where did your estimates net out?

• Let’s review each item as a group

• Team representatives - when called, shout out or post your

estimate in chat!

• Heads up, you may be called on to give an explanation for your

If the helicopter is a size 3, what size is the work for the others?

Reference stories

• A reference story serves as a guide to assist teams in

estimating by providing a benchmark story to base new estimates on

• When estimating new stories, consider their size in relation to

Food for thought

Something can be technically “small” but requires a lot of little, complicated pieces

Something can look large as a whole, but

requires fewer pieces, larger chunks that can be placed together with less time/effort

Something else to think about

• What if the requirements for the town included ensuring that

these items were safe and usable for the Lego town people?

• How does that change your estimates? e.g. consider

additional risks, steps to consider them “done” or passing inspection!

What are the additional risks or considerations with the helicopter vs. the bulldozer?

Does this change your estimate when considering the done criteria?

Any questions?

Relevant sources

• Mountain Goat Software

• Scrum Foundations eLearning Series

• Scrum Guides