Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Product owner reviews product backlog items with the team for clarification and revision. The team estimates the effort of each item.
Key Ideas
Planning poker: a “game” where each team member uses a card to show their estimate of the work involved in an item
As we've discussed before,
0:00
the key contribution of the product owner
is to maintain the product backlog.
0:01
The product backlog is
a priority ordered list of items
0:06
that the team will eventually
pull into a sprint to complete.
0:09
Product backlog items may include defects
and technical items or technical debt.
0:13
As we learned before,
0:18
items that describe value to the user
are described in user's stories.
0:19
User stories are a special type of
product backlog item that describes who
0:24
will use the feature and why.
0:28
We'll learn more about how to construct
user stories later in the course.
0:30
For now, we'll look at the Scrum event
where these stories are discussed, or
0:34
the backlog refinement session.
0:38
Backlog refinement is also sometimes
called backlog grooming, or
0:41
more playfully, story time.
0:44
However your team chooses to name
the event, it is an opportunity
0:47
to review product backlog items,
get input from team members,
0:51
add clarity to the items, and
estimate the effort involved.
0:54
The product owner drives
the conversation in backlog refinement.
0:59
The goal is to refine items in the backlog
so that they are well understood, and
1:03
small enough to be
incorporated into a sprint.
1:07
Generally, the product owner will begin
with the items in the backlog that
1:11
are coming up, but may also incorporate
new items or ones that he or
1:15
she anticipates will require a few passes
1:19
before they are ready to
be taken into a sprint.
1:22
During backlog refinement, the product
owner presents a product backlog item or
1:25
user story.
1:29
The product owner opens
the floor to the team and
1:31
answers clarifying questions about what
the story means or what it entails.
1:33
If the story is too big,
1:39
the team discusses how it can
be broken into smaller pieces.
1:40
The team checks their shared understanding
by drafting conditions of acceptance, or
1:44
acceptance criteria.
1:49
These describe
the characteristics of a solution
1:51
without saying how
the problem will be solved.
1:54
For example,
a condition of acceptance might be
1:56
that the user sees relevant articles
when they type a support question.
2:00
This is something that can be tested
later, without having to work out all
2:04
the details of where the relevant articles
are presented or how they will appear.
2:08
After a few items have been discussed, the
team estimates the effort of each item.
2:14
There are many ways to estimate effort.
2:19
The most popular method is
probably Planning poker.
2:21
In Planning poker, each team member
gets a set of cards with story points or
2:25
effort points on it.
2:30
Each team member chooses one card and
2:32
displays it to the rest of the group,
showing their estimate of the amount of
2:34
work involved in a particular user
story or a product backlog item.
2:38
Story points are relative
estimates of the amount of
2:42
effort it will take to complete an item.
2:44
In Scrum, we use the story points
in place of time based estimates,
2:47
such as hours, because we recognize that
those estimates are likely to be wrong.
2:51
It's much easier to compare two items and
say that one requires a little more effort
2:56
than the other, or that one requires
twice the effort of the other.
3:00
Generally, story points are assigned using
a series where the steps increase in size.
3:04
This is because as we get
into higher estimates,
3:09
we recognize that we really don't know
how much effort something will take.
3:12
And in fact,
3:16
the item may need to be broken up into
smaller parts in order to be estimated.
3:17
An example number series used for
story points is the Fibonacci sequence.
3:22
The Fibonacci sequence is a series
of numbers where each number
3:26
is the sum of the previous
pair of numbers.
3:30
Don't worry too much about
the meaning of the Fibonacci numbers.
3:33
There's a mathematical allure
to the Fibonacci sequence,
3:36
which you may be interested
in reading about.
3:39
But in this case,
3:42
we really just need a number sequence
where each step is progressively greater.
3:42
That way, we can easily compare
the effort of two product backlog items.
3:47
In fact, another sequence of numbers
is also commonly used in Planning poker
3:51
based on powers of two, where each
number is the double of the previous.
3:56
Again, the most importing thing here
is to be able to compare the effort of
4:00
one item to another.
4:04
For example,
4:05
this story is twice the effort of another
story because when team members display
4:07
their effort estimates in Planning poker,
the team tries to reach consensus.
4:12
Often, the facilitator will ask
team members with the highest and
4:17
lowest estimates to
explain their reasoning.
4:20
For example, the Scrum master
might facilitate by asking,
4:23
your estimate is lower than the others.
4:27
Is there anything about your
thinking that you can share?
4:29
This is another opportunity to
come to a shared understanding
4:32
on the product backlog item and
the work it entails.
4:35
You need to sign up for Treehouse in order to download course files.
Sign up