Estimation and Velocity - Scrum Framework

2015 - OpenArc Campus – BIT UCSC
IT4305- Rapid Software Development
Upekha Vandebona
upe.vand@gmail.com
REF: Essential Scrum Practical Guide to the Most Popular Agile Process, Kenneth S. Rubin

Chapter 04 - Core Concepts
 4.1 - Scrum Framework
 4.2 - Sprints
 4.3 - Requirements and User Stories
 4.4 - Product Backlog
 4.5 - Estimation and Velocity

• Describe the concepts of estimation and velocity.
• Discuss the items that should estimate and when and how to
estimate them.
• Describe how to estimate product backlog items.
• Explain velocity and how to use a velocity range.

Introduction
 When planning and managing the development of a
product….
“How many
features will be
completed?”
“When will we
be done?”
“How much will
this cost?”
To answer these
questions using
Scrum,
we need to
estimate the size
of what we are
building and
measure the
velocity (rate
at which we can get
work done).

What and When We Estimate
 Most organizations make estimates for planning
purposes at three different levels of detail.
1. Portfolio Backlog,
2. Product Backlog,
3. Sprint Backlog Task.

1. Portfolio Backlog Item
Estimates (optional)
 Many organizations choose to use rough, relative size
estimates like T-shirt sizes (such as small, medium,
large, extra large, and so on)

2. Product Backlog Estimates ***
 Estimating PBIs is part of the overall product backlog
grooming activity.
 Most teams prefer to put numeric size estimates on
them, using either story points or ideal days.

Why Estimate? (contd.)
 Not all PBIs will be at the same size at the same time,
so there will be some larger PBIs in the backlog even if
we do have a collection of smaller, similarly sized items
toward the top.
 It can take some time for teams to acquire the skills to
break down PBIs to be roughly the same size.

Why Estimate? (contd.)
 Finally, and most importantly, one of the primary
values of estimation is the learning that happens
during the estimation conversations. Nothing
promotes a healthy debate like asking people to put a
number on something, which will immediately surface
any disagreements and force assumptions to be
exposed. If we were to do away with estimation, we
would need to substitute an equally effective way of
promoting these healthy discussions.

3. Task Estimates (Sprint Backlog)
 At the most detailed level we have the tasks that reside
in the sprint backlog.
 Most teams choose to size their tasks during sprint
planning so that they can acquire confidence that the
commitments they are considering are reasonable.
 Tasks are sized in ideal hours (also referred to as
effort-hours, man-hours, or person-hours)

1. Estimate as a Team
 Traditional Approach
 Project manager, product manager, architect, or lead
developer might do the initial size estimation.
 Other team members might get a chance to review and
comment on those estimates at a later time.
 Scrum Approach
 The people who will do the work collectively provide the
estimates. (Development team that will do the hands-on
work to design, build, and test the PBIs. )
 The product owner and Scrum Master don’t provide
estimates. Both of these roles are present when the PBIs are
being estimated, but they don’t do any hands-on estimation

2. Estimates Are Not
Commitments
 The estimates ought to be a realistic measure of how
big something is.
If we ask people to estimate a story’s size, we expect
to get a realistic estimate. If we then tell them their
salaries/bonuses will be based on the work due on
time, everyone will give a much larger estimate than
the one we originally thought was correct.

2. Estimates Are Not
Commitments
 We don’t want them artificially inflated due to external
influences.
 That behavior only results in bloated schedules and a
back-and-forth game of estimate inflation by team
members and reduction by management.
 When all is said and done, we have no real
understanding of the numbers because they have been
manipulated so many times by different people.

(Accuracy Vs Precision)
Accuracy: The closeness of a given measurement to its true
value.
Precision: The stability of that measurement when repeated
many times.

3. Focus on Accuracy, Not
Precision
 Our estimates should be accurate without being overly
precise.
 We should invest effort to get a good-enough, roughly
right estimate.

4. Relative Size Estimation
 We should estimate PBIs using relative sizes, not
absolute sizes.
 We compare items to determine how large an item is
relative to the others.
People are much better at relative
size estimation than absolute size
estimation

PBI Estimation Units
 Although there is no standard unit for PBI size
estimates, by far the two most common units are
 Story Points
 Ideal Days.

1. Story Points (contd.)
 Story points measure the bigness or magnitude of a
PBI.
Scenario 1 :
Let’s say we have to update every cell in a 60,000-cell
spreadsheet. None of the individual updates is
difficult, but the updates can’t be automated.
How much of this work can we get done in a sprint?
Though not complex, this would be a large story.

Story Points (contd.)
 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,” implying that the
searching story is roughly four times the size of the
creation story.
 Because size measures like story points are ultimately
used to calculate time (duration), story points must
reflect the effort associated with the story from the
development team’s perspective.

2. Ideal Days
 Ideal days are not calendar days.
 They represent the number of effort-days or person-
days needed to complete a story.
“How big is this PBI?”
“Two days.”
“OK today is Wednesday, so you’ll
be done on Friday.”
“No, I don’t have any full day tomorrow to
dedicate to the PBI as I need an entire day just
to get caught up. I’m thinking I should be done
sometime next Monday.”
“I don’t understand; you told me it was
a two-day PBI, so you should be done
on Thursday.”
“I said two ideal days, not two calendar days”

Planning Poker (contd.)
Planning Poker is a
technique for sizing PBIs.

Planning Poker (contd.)
 Planning Poker is a consensus-based technique for
estimating effort.
 Knowledgeable people (the experts) slated to work on
a PBI engage in an intense discussion to expose
assumptions, acquire a shared understanding, and size
the PBI.
 Planning Poker yields relative size estimates by
accurately grouping or binning together items of
similar size.
 The team leverages its established PBI estimation
history to more easily estimate the next set of PBIs.

Estimation Scale in Planning Poker
 To perform Planning Poker, the team must decide
which scale or sequence of numbers it will use for
assigning estimates.
 Because our goal is to be accurate and not overly
precise, we prefer to not use all of the numbers.
 Instead, we favor a scale of sizes with more numbers at
the small end of the range and fewer, more widely
spaced numbers at the large end of the range.

Estimation Scale in Planning Poker (contd.)
 The most frequently used scale,
 Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, and 100.
 An alternative scale that some teams use is based on
powers of 2:
 1, 2, 4, 8, 16, 32
 When using this type of scale, we group or bin
together similar-size like PBIs and assign them the
same number on the scale.

Poker Game in Scrum
 The full Scrum team participates when performing
Planning Poker.
 During the session, the product owner presents,
describes, and clarifies PBIs.
 The ScrumMaster coaches the team to help it better.
 The ScrumMaster is also constantly looking for people
who, by their body language or by their silence, seem
to disagree and helping them engage.
 And the development team is collaboratively
generating the estimates.

Poker Game in Scrum
 Usually consensus can be achieved within two or three
rounds of voting, during which the team members’
focused discussion helps obtain a shared
understanding of the story.
 Planning Poker brings together the diverse team of
people who will do the work and allows them to reach
consensus on an accurate estimate that is frequently
much better than any individual could produce.

What Is Velocity?
 Velocity is the amount of work completed each sprint.
 It is measured by adding the sizes of the PBIs that are
completed by the end of the sprint.
 A PBI is either done or it’s not done.
 The product owner doesn’t get any value from undone
items, so velocity does not include the size numbers of
partially completed PBIs.

What Is Velocity? (contd.)
 Velocity measures output (the size of what was delivered),
not outcome (the value of what was delivered).
 We assume that if the product owner has agreed that the
team should work on a PBI, it must have some value to
him.
 However, completing a PBI of size 8 doesn’t necessarily
deliver more business value than completing a PBI of size 3.
 Perhaps the PBI of size 3 is high value and therefore we
work on it early (because it is high value and low cost), and
we work on the PBI of size 8 later (because it is lower value
and higher cost).

 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 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.

 Second, velocity is also a diagnostic metric that the
team can use to evaluate and improve its use of
Scrum to deliver customer value.
 By observing its own velocity over time, the team can
gain insight into how specific process changes affect the
delivery of measurable customer value.

Calculate a Velocity Range
 For planning purposes, velocity is most useful when
expressed as a range. Using a range allows us to be
accurate without being overly precise.
 it’s impossible to give a very precise answer. By using a
range, we can communicate our uncertainty.
“The team is typically able to
complete between 25 and 30
points each sprint.”

Forecasting Velocity
 One of the benefits of having long lived teams is that
they will acquire such useful historical velocity data
that we could use to predict future velocity.
 But how do we handle the situation where we have a
new team whose members haven’t worked together
and therefore have no historical data? We’ll have to
forecast it.

Forecasting Velocity (contd.)
 One common way to forecast a team’s velocity is to
have the team perform sprint planning to determine
what PBIs it could commit to delivering during a single
sprint.
 If the commitment seems reasonable, we would simply
add the sizes of the committed PBIs and use that as the
team’s forecasted velocity.
 Because what we really want is a velocity range, we
could have the team plan two sprints and use one
estimated velocity number as the high and the other as
the low (the two estimates would likely be different).

Forecasting Velocity (contd.)
 Alternatively, we could make some intuitive
adjustments to one estimated velocity based on
historical data for other teams, thereby converting the
one estimate into a two-estimate range.
 As soon as the team has performed a sprint and we
have an actual velocity measurement, we should
discard the forecast and use the actual.
 And as the team builds up a history of actual velocities,
we should compute averages or apply other statistics to
the data to extract a velocity range.

Affecting Velocity
Team’s velocity should constantly increase
over time????

Affecting Velocity (contd.)
 If the team is constantly inspecting and adapting
(continuously improving), its velocity should keep
getting better and better.
 A team that is aggressively trying to improve itself and
is focused on delivering features in accordance with a
robust definition of done and low technical debt can
see an increase in velocity. Well, at least an increase up
to a certain point, at which time its velocity will likely
plateau.

 Just because a team’s velocity has leveled out doesn’t
mean there is no more upward potential.
 There are a number of ways that the Scrum team and
managers can help get velocity to the next plateau.
 For example, introducing new tools or increasing
training can have a positive effect on velocity.
 Or managers can strategically change team composition
with the hope that the change will eventually lead to a
greater overall velocity.

 Of course, managers should be careful because
haphazardly moving people on and off teams can and
probably will cause velocity to decline.
 Although introducing new tools, getting training, or
changing team composition can have a positive effect
on velocity, these actions usually cause a dip in velocity
while the team absorbs and processes the change.
 After this decline, there will probably be an increase to
the point where the team establishes a new plateau
until some other change causes yet another plateau to
be achievable.

 Of course, there is one obvious thing we could do to
try to improve velocity: work longer hours.
 Working a lot of consecutive overtime might initially
cause velocity to increase.
 That increase will
almost certainly be
followed by an
aggressive decline in
velocity along with a
simultaneous decline in
quality.

 Even after the overtime period ends, the team will
need some amount of time to recover before returning
to its reasonable baseline velocity.
 Mostly the trough (decreased velocity area) during the
recovery period is larger than the crest (increased
velocity area) during the overtime period.
 The end result is that lots of overtime may provide
some short-term benefits, but these are frequently far
outweighed by the long-term consequences.

Misusing Velocity
 Velocity is used as a planning tool and as a team
diagnostic metric.
 It should not be used as a performance metric in an
attempt to judge team productivity.
 When misused in this way, velocity can motivate
wasteful and dangerous behavior.
 For example, say We have decided to give the largest
bonus to the team that has the highest velocity.
 Superficially this idea might seem sensible; the team
with the highest velocity must be getting the most work
done each sprint, right? So, why not reward that
behavior?

Misusing Velocity (contd.)
 Well, if I’m comparing teams that aren’t sizing their
PBIs using a common baseline (which is very likely
true), comparing the numbers would make no sense.
 Let’s say that team A assigns a value of 5 to a PBI,
whereas team B assigns a value of 50 to the same PBI.
 Team A doesn’t really want me to compare its velocity
against team B’s velocity.
 Team B’s velocity will be ten times that of team A, even
if both teams actually get about the same quantity of
work completed each sprint.

 Once team A sees the problem, its members will start
to game the system to ensure that their velocity
numbers are higher.
 The easy way to do this is to just change the scale the
team uses to estimate PBIs.
 So, team A now sizes the same item (the one it
originally sized a 5) to be a 500.
 We call this behavior point inflation, and it serves no
purpose other than to align a team’s behavior with a
misguided measurement system.
 Don’t do this.

 If we set up the reward system to favor bigger numbers,
that’s exactly what I’ll get—bigger numbers (point
inflation).
 Even worse than point inflation is when teams cut corners
to get more “done” in an effort to achieve higher, more
desirable velocities. Doing so leads to increasingly greater
levels of technical debt.
 At the end of the day, we should judge velocity on how well
it assists us with performing accurate planning and how
well it helps a team to internally improve itself.
 Any other uses will likely promote the wrong behavior.

Estimation and Velocity - Scrum Framework

Recommended

More Related Content

What's hot (20)

Similar to Estimation and Velocity - Scrum Framework (20)

More from Upekha Vandebona (20)

Recently uploaded (20)

Estimation and Velocity - Scrum Framework

Editor's Notes