What and When We Estimate

Organizations make estimates for planning purposes at

three different levels of detail. These estimates manifestin the Portfolio Backlog, Product Backlog, and

Sprint Backlog.

Relative Size Estimation

It is hard to estimate in absolute terms, most of the

people are “not so good” at absolute estimates but we

are much better when estimating in relative size. We

compare items to determine how large an item is relative

to the others.

i.e. In absolute size how big is the area (in square inches)

of the figures below?

Now in relative size, How big is the rectangle compare to the circle?

Relative Size Estimation

In relative size estimation we need a reference, something

that we can relate to, compare to.

In our example

the reference is

About 3 times

User Story estimation units

Story points are a unit of measure for expressing the

overall size of a PBI (user story)

Story points measure the bigness or magnitude of a PBI

Story points tell us how big a story is, relative to others

The goal is to be able to compare stories and say things

like “Well, if the create-a-ticket story is a 2, then the

search-for-a-ticket story is an 8,”

Reference story

A reference story is an example of a story that we can

fairly well relate to. A new story can be compared to the

reference story(ies) and we can tell whether it is larger,

similar or smaller than the reference story.

Planning Poker to PBI estimation

We will be using Planning Poker to estimate PBIs (User

Stories) during our Product Backlog Grooming sessions. Our

estimation scale will be:

1, 2, 3, 5 , 8, 13, 20, 40, 100, ∞, ?

“20 or 40” “this item is too big and it has to be refined /

decompose (split)”

"100" basically means "this will never fit into a Sprint – This is an

Epic.

∞ (infinity) Used to indicate that the item is so large it doesn’teven make sense to put a number on it.

? Used to ask additional clarification

Reference user stories

We should have 3 references, one small, one medium and one

that is the largest we would allow in a sprint, PBI (story) bigger

than the largest gets sliced.

SizeStory

PointsReference PBI – ESA Team

Small 2

Medium 8

Large 13

Velocity

A measure of the rate at which PBIs (User Stories) are

completed per Sprint. Velocity is typically measured as the sum

of the size estimates of the PBIs that are completed (DONE) in a

sprint. In our case Velocity will be reported in story points (SP).

Why to use Velocity?

Velocity is used for two important purposes. First, it is an

essential concept for Scrum planning. For release-level

planning we divide the size of the release (expressed in

Story Points) by the team’s average velocity to calculate

the number of sprints necessary to complete the release.

Additionally, at sprint planning, a team’s velocity is used as

one input to help determine its capacity to commit to work

during the upcoming sprint

Velocity as a range

For planning purposes, velocity is most useful when

expressed as a range, such as: “The team is typically able

to complete between 25 and 30 points each sprint.” Using

a range allows us to be accurate without being overly

precise.

Summary

Estimate in points is easier to get “accurate”. If you

estimate consistently, you may be able to measure process

improvements in the form of increased velocity.

To estimate consistently, you should have reference stories

at hand to compare with during estimation.

Velocity is unique (subjective) to each team. Comparing

Velocity between teams does not apply; Team’s Velocity

does not relate.