Backlog refinement – Do you groom your user stories?

Sometimes words make us feel a little uncomfortable. I have found in my position as a business analyst going into different types of organisations who are embarking on technology projects for the first time, that “grooming” tends to be one of those words. Whether or not you like the word, it has a very important function for agile product development teams.  “Product backlog refinement” which is also referred to as “product backlog grooming” is a method to keep your user stories updated, orderly and ready to build.

It is still widely documented that approximately 70% of technology projects fail to achieve their intended objectives.  There are many issues encountered in the delivery of technology projects.  Some of these might be catastrophic to your timeline and unavoidable, for example the illness of a key project member. However, some of these issues are completely avoidable.  Allowing time for backlog refinement to a point where you are satisfied that each user story meets the agreed criteria for “ready to build” can ensure your sprints are delivered on time and with minimal disruption.  A crucial guideline in Scrum is that five to ten percent of every Sprint must be dedicated to product backlog refinement.

What is a Grooming Score?

A grooming score is a score based on an agreed definition of what it means to make a requirement ready to build. Grooming of a requirement backlog is often carried out by the business analyst or product owner but they might do this in rigorous consultation with the technical leads or a combination of people within a project team.

Grooming, which is more increasingly referred to as requirement or backlog refinement, typically involves the following

1. User Story – a user story typically sets out the user who is performing the required function, the required function and the problem that it solves;

2. User Story Description– more detail surrounding the requirement;

3. Acceptance Criteria – the business definition of complete. The requirement will be tested against the acceptance criteria;

4. Dependencies – anything that a requirement is dependent on for the build;

5. Priority – assessing and then re-assessing the relative priority of stories regularly;

6. Estimation of Effort – an estimate of the effort (in hours) that it will take to design and build the requirement;

7. Reference Data – any business logic, physical templates required to build the requirement.

If all of the above were defined for each backlog item, a user story would need to get to a grooming score of 7 before it was ready to build. Your project might require more, less or different criteria defined from the above list. A defined grooming score should be elected well in advance of the start of the build.

Why is backlog refinement so important?

There is a grooming technique called the ‘Building Man’ coined by international firm, Nagarro, that sets out very clearly what rewards are gained through rigorous backlog refinement, but conversely what to expect if you leave part or all of your backlog refinement out of your agile build process.

The first step is called ‘Strawman Grooming’. As you can imagine from its name, it involves looking at the bare bones of the requirement and gaining minimal understanding of what is required to build it, but no guts. Essentially this involves categorising the user story into an Epic. At this point you can expect to have around 20% assurance that the feature built matches its intended design. 20% is not a whole lot of assurance in my opinion. Performing strawman grooming only will almost always result in extended timelines to fight the fires caused, which will in turn impact your project costs negatively.

The second step is called ‘Woodman Grooming’. This involves sub-categorising the user stories into features so that features may be grouped to be built together. Dependencies, user experience flows, the technology being used to build the feature would be considered in detail in this step. At this point you can expect to have around 50% assurance that the feature built matches its intended design. Not grooming to this level will result in duplication of work and could result in building one function is direct opposition to another function. Sounds bad, right?

The third step is called ‘Steelman Grooming’. Once again as the name suggests, this is a very robust level of grooming. This step includes getting into the guts of the requirement from every angle including business rules required, scope of any automation and negative and exception scenarios. At this point you can expect to have around 80% confidence that the feature built matches its intended design. Grooming to this level ensures there are no nasty surprises that could cost your project big in time and money. Considering 70% of technology projects fail, why risk it?

If I had to choose one of these grooming items as being the most important, I would choose the effort estimation. I understand how time consuming it might seem to define this for every user story, however, it will pay off in the long run. It will be your crystal ball and save you time and money and a lot of headaches in the long run.

When should I perform backlog refinement?

Ideally backlog refinement should be conducted 2-3 sprints in advance.

Refine to stay within the timeline

It may be that you think you already are grooming your user stories before building, however without structure to the backlog discussion such as above, it will often be very difficult to deliver the user stories within the committed schedule or sprints.

Don’t think that once you’ve groomed your requirements that you need never speak of them again either. In an agile world, the backlog is an ever-fluid landscape. The project team should be constantly removing user stories that are no longer relevant, creating new user stories in response to newly discovered needs and re-prioritising user stories still in the backlog.

Now take a moment to think about the technology projects that your organisation has previously embarked on. Were they successful?  Was backlog refinement completed consistently? If not, do you think it would have produced very different results? My experience tells me that it would!