As we've discussed before,

the key contribution of the product owner is to maintain the product backlog.

The product backlog is a priority ordered list of items

that the team will eventually pull into a sprint to complete.

Product backlog items may include defects and technical items or technical debt.

As we learned before,

items that describe value to the user are described in user's stories.

User stories are a special type of product backlog item that describes who

will use the feature and why.

We'll learn more about how to construct user stories later in the course.

For now, we'll look at the Scrum event where these stories are discussed, or

the backlog refinement session.

Backlog refinement is also sometimes called backlog grooming, or

more playfully, story time.

However your team chooses to name the event, it is an opportunity

to review product backlog items, get input from team members,

add clarity to the items, and estimate the effort involved.

The product owner drives the conversation in backlog refinement.

The goal is to refine items in the backlog so that they are well understood, and

small enough to be incorporated into a sprint.

Generally, the product owner will begin with the items in the backlog that

are coming up, but may also incorporate new items or ones that he or

she anticipates will require a few passes

before they are ready to be taken into a sprint.

During backlog refinement, the product owner presents a product backlog item or

user story.

The product owner opens the floor to the team and

answers clarifying questions about what the story means or what it entails.

If the story is too big,

the team discusses how it can be broken into smaller pieces.

The team checks their shared understanding by drafting conditions of acceptance, or

acceptance criteria.

These describe the characteristics of a solution

without saying how the problem will be solved.

For example, a condition of acceptance might be

that the user sees relevant articles when they type a support question.

This is something that can be tested later, without having to work out all

the details of where the relevant articles are presented or how they will appear.

After a few items have been discussed, the team estimates the effort of each item.

There are many ways to estimate effort.

The most popular method is probably Planning poker.

In Planning poker, each team member gets a set of cards with story points or

effort points on it.

Each team member chooses one card and

displays it to the rest of the group, showing their estimate of the amount of

work involved in a particular user story or a product backlog item.

Story points are relative estimates of the amount of

effort it will take to complete an item.

In Scrum, we use the story points in place of time based estimates,

such as hours, because we recognize that those estimates are likely to be wrong.

It's much easier to compare two items and say that one requires a little more effort

than the other, or that one requires twice the effort of the other.

Generally, story points are assigned using a series where the steps increase in size.

This is because as we get into higher estimates,

we recognize that we really don't know how much effort something will take.

And in fact,

the item may need to be broken up into smaller parts in order to be estimated.

An example number series used for story points is the Fibonacci sequence.

The Fibonacci sequence is a series of numbers where each number

is the sum of the previous pair of numbers.

Don't worry too much about the meaning of the Fibonacci numbers.

There's a mathematical allure to the Fibonacci sequence,

which you may be interested in reading about.

But in this case,

we really just need a number sequence where each step is progressively greater.

That way, we can easily compare the effort of two product backlog items.

In fact, another sequence of numbers is also commonly used in Planning poker

based on powers of two, where each number is the double of the previous.

Again, the most importing thing here is to be able to compare the effort of

one item to another.

For example,

this story is twice the effort of another story because when team members display

their effort estimates in Planning poker, the team tries to reach consensus.

Often, the facilitator will ask team members with the highest and

lowest estimates to explain their reasoning.

For example, the Scrum master might facilitate by asking,

your estimate is lower than the others.

Is there anything about your thinking that you can share?

This is another opportunity to come to a shared understanding

on the product backlog item and the work it entails.