Product backlog refinement (PBR) is the continuous process of improving the list of (software) work to be done. PBR is the cornerstone to deciding what must be done and in what order. In this article we describe the main activities of product backlog refinement and how they can be accelerated with ScopeMaster®’s intelligent requirements analyser.
Product Backlog Refinement
Product Backlog Refinement is the regular activity carried by most or all of the team in a meeting with the goal of preparing activities for the upcoming iteration(s). The key activities are:
- Clarifying user stories, so that the team has a common understanding of them.
- Splitting stories that are too large to fit in an iteration.
- Creating new user stories and removing others according to new knowledge.
- Assigning estimates to stories
- Assigning priorities to stories
Product backlog refinement is a very time- consuming and costly activity, typically consuming 5-15% of the teams’ entire work time. Yet it is absolutely essential as it is the key step in ensuring that the team works on the right things. If insufficient time an effort is spent on this, the team will waste time on the wrong activities, which can be even more costly.
Let us look at each of these PBR activities in a bit more detail and see how automation can help.
What Goes in the Product Backlog?
A product backlog generally contains user stories (that describe functionality) , high granularity epics and more detailed user stories. The product backlog should exclude other tasks that may be involved but not directly delivering user functionality..
Activities of Backlog Refinement:
1. Clarifying user stories
The English language is immensely flexible. We have many alternative words for the same thing. We can change word order to alter the meaning and change how the story will be interpreted. The variations are nearly infinite, even a 12-word user story has 87 billion permutations of word order. With each variation the reader’s interpretation is likely to be slightly different. And even then, each individual’s interpretation of a user story depends on their own vocabulary and language ability. It is more than likely that any two people reading a user story will have different interpretations.
If the members of the team do not share a common understanding of a backlog item, it is likely that those who subsequently work on it will waste time building/testing the wrong thing. A consistent understanding by the entire team is therefore essential to minimise wasted effort.
According to scrum.org “Typically a Product Backlog item goes through three refinement meetings before it is considered to be in a ready state.” To make this discussion fruitful, the better the quality of the story entering the meeting, the less time will be wasted.
The majority of backlog items describe functional intent, the Who and What of the user story. This is where ScopeMaster can completely eliminate ambiguity in a fraction of the time, cutting out lengthy discussions.
2. Splitting stories to fit in a sprint
Agile user stories should be completed within a single iteration or sprint (typically two weeks). Completion of a single story should not be allowed to span two sprints. Completion should also include all unit testing. If a story is too large, it needs to be split down into bite size chunks. Typically a developer will be able to build (including unit tests) about 8 COSMIC Function Points (CFP) per sprint. This estimate of individual productivity varies significantly, but if a single story exceeds 8 CFP, it should either be shared across more than one team member and/or split into smaller “bites” each of which can be completed within a sprint/iteration.
ScopeMaster’s ability to detect functional size it gives an immediate estimate of whether a story needs splitting.
3. Creating new user stories and removing others
Software teams need to adapt to the changing demands of the business. During backlog refinement there will be a need to split some stories, create new ones and remove others. This ensures that the work being done is targeting the business need as it is currently known. Creating new stories to meet changing demands is fine, but change should be kept down wherever possible, as excessive levels of change disrupts the team. Many “unknowns” are in fact “knowable”. The changes should be limited to those things that were initially unknowable. Wherever possible it is helpful to anticipate the overall requirements as early as possible. This helps to plan the team’s work most efficiently.
ScopeMaster’s ability to analyse a set of user stories looking for missing and duplicate functionality, allows the team to get a better understanding of overall scope much earlier.
4. Assigning estimates to stories
Estimating stories is perhaps one of the most time consuming aspects of product backlog refinement. Typically this involves playing games of “story poker” where the team participants guess the effort required to deliver the story in t-shirt sizes or later in (arbitrary) story points. Not only is it time consuming but it is tiresome, subjective, inconsistent and of little use for project management, especially on a large scale project. Furthermore story point estimates are usually “gamed” to achieve a particular outcome.
ScopeMaster’s ability to instantly estimate the functional size user stories (in COSMIC function points) means that the team needs spend very little time in the meetings discussing the size of story. The functional size of the refined story is a consistent, standardised and immutable value. This frees up team time to discuss the best ways of how to deliver the story most efficiently.
5. Assigning priorities to stories
Prioritising stories is a consequence of how important they are to the business, what other stories depend them on and how much effort they will take to deliver. If the other backlog refinement activities have already been partially or mostly automated, the team can spend more time discussing this in the backlog refinement meetings. This will help ensure that the team does the most important things in the right order.
