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