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

Prioritise

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.

 

Understand

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.

 

INVEST/refine

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

Estimate

 

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.

 

Conclusion

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.

Definition of Done

When a product Increment is completed, we say it is Done. These are criteria that must be met before an increment can be released.

To know what Done really means, the Scrum Team must have a shared Definition of Done (DoD).

  • Separate teams that are working on the same product should share the same DoD
  • Separate teams working on separate products can have different DoD’s.

It may be that the organisation already has standards and policies which can be used as the DoD. But if these standards don’t already exist, then the Scrum Team must create one.

 

Example Definition of Done

  • Code compiles
  • Code Peer Reviewed by one other Developer
  • Tested by the Development Team
  • User Acceptance tested

Only when all of the above points are true, can the increment be called Done.

As the Scrum Team matures and adapts, it is likely that their DoD will change – it is likely to become more stringent, resulting in higher quality increments. See our teams’ current DoD.

 

Done vs Acceptance Criteria

Acceptance Criteria are used to define when a specific Product Backlog Item is complete – each PBI can have different acceptance criteria. While Done covers all PBIs in the increment.

 

Scrum Glossary – INVEST

How do we know if a Product Backlog Item is of a good quality? We need to make sure it’s not too large to be implemented in a Sprint and that it can be tested in order to say that it’s Done.

To help us ensure a PBI is of good quality, we can use INVEST:

Independant – the PBI should be self-contained and not depend on other PBIs.

Negotiable – the PBI is not an explicit contract and should be open for discussion.

Valuable – it must deliver some form of value to the business

Estimable – the development team must be able to estimate how much effort it will take to implement the PBI.

Small – the PBI must fit within a Sprint.

Testable – we must be able to define tests/acceptance criteria for the PBI so that we know when it is Done.

Scrum Glossary – acceptance criteria

Acceptance criteria are used to define when a task is completed. They allow you to meet the Testable aspect of user stories when using INVEST.
They can cover both functional and non-functional criteria.

 

Example Acceptance Criteria

If we take the following as our user story:

As a registered user, I want to book onto a training course of my choice.

 

Some possible acceptance criteria could be:

  • Send confirmation email to user when booking is saved
  • Display correctly on PC, tablet and mobile phone.
  • The form cannot be submitted without entering all required data.

Acceptance criteria are specific to a user story, while the Definition of Done covers all stories.