Skip to main content

Scrum Events – Backlog Refinement

Backlog Refinement isn’t an official meeting as defined in the Scrum Guide, although it does state

The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.

The meeting is held mid-Sprint, before Sprint Planning and the aim is to get the Product Backlog and its items into such a state that the highest priority items can be pulled into a Sprint. It ensures that the Sprint Planning is effective and efficient – team members can focus on selecting the PBIs for the Sprint, rather than trying to understand the PBIs.


The aim is to prioritise the Product Backlog so the items with highest priority are at the top and ready to be selected. Backlog Refinement also ensures that PBIs are of a good quality and are understood by the team. Ideally we want to conduct enough refinement so that we have PBIs to cover the next two Sprints. This ensures that even if the Product Owner is unavailable, or the Development Team has extra capacity, there are enough PBIs in a ready state.

Below are the steps that take place in the Backlog Refinement meeting:

product owner


Coming into the refinement meeting, the Product Owner should already have a good idea of which PBIs are the highest priority. Outside of the Scrum meetings they will meet with stakeholders in order to prioritise the backlog. They can use a variety of prioritisation techniques to achieve this, with assistance from the Scrum Master.



The Development Team must understand the PBIs so that they can successfully implement them. This can take the form of querying the Product Owner or the stakeholders. It may also require the team to go away and research a particular topic in order to improve their understanding of it. This research time should be included as part of the 10% Backlog Refinement time, to ensure that it doesn’t take over the time needed for development. Research tasks shouldn’t be added to the current Sprint, as they’re not adding any business value.



Once the team has an understanding of what a PBI requires, they must ensure it’s of a good quality by using INVEST. This ensures that an item is Independent, Negotiable, Valuable, Estimable, Small and Testable.

If the item doesn’t meet all of these criteria then it must be refined so that it does. This involves splitting the item into thin vertical slices that cover each of the architectural layers i.e. database, server, client.vertical slice

Each slice covers a level of functionality right through from the front-end to the back end. It might only offer one particular feature, but that feature is completely throughout each level of the architecture. Importantly, a vertical slice allows us to deliver something of business value.


Acceptance Criteria

Once a PBI is appropriately sized and understood, the team define acceptance criteria for it. This allows them to define when an item is Done.


planning poker



Bearing all of the above in mind, the Development Team can now estimate each of the PBIs that we’ve been dealing with (2 Sprints worth). There are a few methods for doing this, which you can read about in my post Estimating Product Backlog Items.


You may find that once estimation has taken place, the Product Owner revises his prioritisation of the items. That ‘must have’ feature might not be so important when he discovers how much effort is required to complete it.



The Backlog Grooming meeting ensures your backlog is ready to go when it’s time for Sprint Planning. Done correctly the output will be a prioritised backlog with items that are understood by the team, of an adequate size and estimated. This means the Development team can more accurately select the appropriate number of items for their Sprint Backlog. This in turn means they should have a consistent Velocity, which leads to more accurate forecasting.

Estimating Product Backlog Items

The items in the Product Backlog each have an estimate of the amount of work required in order to complete them. This allows the Backlog to be effectively refined and managed.

Why Estimate?

  • Allow the Product Owner to properly prioritise the Product Backlog – they can only do this when they have a proper idea of the relative cost of items.
  • It enables high level forecasts to be made. The proposed story points can be plotted in the burn down chart.
  • The Product Owner can make better decisions around scope and schedule – i.e. how important is that ‘must have’ feature, now that it’s been estimated to have a large effort required to complete it.

planning poker


When to Estimate

Our team performs estimation of Product Backlog Items during the Backlog Refinement meeting.

The earlier you estimate, the earlier the Product Owner has information that can be used to prioritise the Product Backlog. You’re not held to the estimate – if more information comes to light, or the item changes, then the estimation can also change. It may also be useful to confirm that estimations are still accurate when items are pulled into the Sprint Backlog. Even though the time between the Backlog Refinement Meeting and Sprint Planning may be short, there is still the potential for Product Backlog Items to change or be clarified.


Why we estimate in points

Story Points provide relative values for the level of effort needed to complete a Product Backlog Item. They take into account:

Effort – the amount of work to do.

Risk and Uncertainty – how much or how little we know about the item.

Complexity – how complex is the logic that we have to work out or the code we have to write.


The final estimate will be a combination of these elements.

Have you ever given an estimate in hours and then overrun, even if only slightly? I’ll bet the next time you gave an estimate, you added on some extra time as ‘wiggle room’.
The issue with hours is that they’re absolute and provide a false sense of certainty.

With story points, the estimates are relative, so we don’t say how long a particular item will take, just that it requires, for example,  double the effort of another item.

It doesn’t matter what values we use, as long as they are relative. So an item with 2 story points is double the effort of an item with 1 story point.


Deciding on a scale – Fibonacci

Although you could just use 1,2,3, etc, this doesn’t really reflect the increasing effort required as the numbers are close to each other. Instead, we can use the Fibonacci numbers, where each number is the sum of the previous two e.g.

1, 2, 3, 5, 8, 13, 21…

Don’t pick too many numbers for your scale, but you might also want to include a large number such as 987 or infinity, for assigning to items that are too large to estimate.


How to estimate

Before you can start estimating all your PBIs, you need to establish a base story. This is the most basic item that you can find on the Product Backlog and one that everyone understands well. This item is assigned a story point value of 1.

You can also assign points to a number of other items, in order to give a range of base stories from the simplest to the most complex – these stories can be real or can be created specially for this task.

Below I’ll detail some techniques that you can use to estimate.


Planning Poker

Probably the most popular technique for estimating is Planning Poker.

First, decide on a ranking scale for items – as previously mentioned, the Fibonacci sequence is popular (1,2,3,5,8, etc).

In a group, every person has card for each of the ratings. You might also have cards with images, such as a cup of coffee – to represent when someone wants to take a break. Or something to denote when the discussion has gone off topic – I’ve seen a cartoon rat used, as in ‘going down a rat hole’.

The item to be ranked is read out to the group and each member selects a card based on their perceived estimation of the work involved. They must keep their card hidden until everyone has chosen. planning poker

Once every member of the group has selected a card, they are all revealed simultaneously.

If the selected estimates are all similar, then the group is in agreement. If there are outliers, then the differences must be discussed in the hope of aligning everyone’s views on the required estimate.

The same item is then estimated again by repeating the steps above in the hope of achieving consensus. If consensus still can’t be reached it may be that the item needs refining into smaller items or that an average (median) score is used.

Alternatively the group may need to decide not on the ‘perfect’ estimation, but one they can support.


T-shirt sizes

As an alternative to using numbers, some teams use t-shirt sizes (S, M , L , XL) to estimate. This can provide an easier way to get started, especially if teams are afraid to commit to a number as they are even more abstract. However they can cause some issues:

  • They will need to be converted to numbers at some point if you want to plot burn down charts.
  • People may have different views of the relative effort required for a particular size. So, is a Large item twice as big, or ten times as big, as a Medium task?

t-shirt sizes



Each member takes a card representing a Product Backlog Item from the pile and adds it to the table. They position in it relation to how large they estimate the item to be – largest items go at one end of the table and smallest at the other end. The next person takes a card and places it on the table, in relation to all other cards. Or they can choose to challenge the position of an existing card. If they think it requires relatively more effort, it goes higher up the board, above the lower effort items.

Once all the cards are placed and the team are in agreement, the items are assigned an estimate using the Fibonacci scale. Starting at the smallest item, assign the card an estimate of 1. Repeat this for the next item up the table. Move up the table until you reach items that you would estimate as 2, then 3 and so on.



Once you’ve estimated the Product Backlog Items, the Product Owner can use those estimates to help them order the Product Backlog.

Over time, the teams’ estimates will become more accurate and they will have a better idea of what can be fit into a Sprint. This process can be sped up by utilising the Sprint Retrospective. The team looks at the estimates they gave for items on the previous Sprint and compares them to the actual amount of effort required. Using this knowledge, they can Adapt their estimation for the next Sprint.