backlog refinement

Backlog Refinement

Backlog refinement is the activity of preparing work items for your software team to work on. Your backlog of user stories, developer tasks and epic ideas is the queue of potential work items to work on in upcoming weeks (sprints). To keep a steady flow of work for the team, a list of refined backlog items should be ready for the team to start working on at any time. There should be slightly more ready and prioritised than the team needs for the upcoming few sprints.

What does Backlog Refinement Mean?

Backlog Refinement (aka backlog grooming) means working on the validity and details of the requirements/ideas/tasks so that the key questions are answered correctly such that the developer/tester will do the right thing first time. User stories should be refined and ready before coding and testing work starts.

To shorten your backlog meetings, you want your input to be as high quality as possible. This means get your business analyst or product owner to refine the user stories as much as possible before the meeting. Automated analysis can really help with this, as it will help you get your stories into good shape before the refinement meeting.

What does “ready” actually mean?

Ready, or definition of ready, means that sufficient verification, questioning, rewording, reviewing and analysis has been completed BEFORE the coding, so that the coding work can be done right first time. This means that the user’s goals are fully understood, clear, ideally measurable and certainly unambiguous before a line of code is written. (Nb prototyping is often a useful means of verifying requirements, but prototyping is not necessarily coding).

A refined user story should be:

Simplified

Your user stories should be short pithy functional statements that completely describe the functional steps of a complete user requirements. Such that the system is in a steady state before and after the steps have taken place.

Clarified

Your user stories should be clear, succinct and unambiguous. The ideal is that if several members describe their interpretation of each user story. Each interpretation is the same. Now this is hard with the English language, sometimes even if all parties were present during the conversation that described the user story. The goal is to achieve that consistent interpretation by all team members ie. a shared understanding.

User-oriented

We see a lot of user stories begin with “as a developer…” This does not describe the requirement from the user’s perspective, it is instead a task. Before you create developer tasks, you must first have user story that describes what the user needs to achieve and why. Then and only then can you break that down into developer tasks, if necessary.

Consistency Checked

It is vital that you use consistent terms throughout your user stories for each user persona. It is also vital that you use identical words for each object type. This problem is very common when two or more people are authoring the user stories, but can even happen which just one person is doing the work. Inconsistent use of object names or user personas will lead to inconsistent interpretations and mistakes.

Completeness Checked

Is your user story complete, does it describe all the functionality needed to deliver the user experience or necessary functionality? Have you “buried” actual functionality in your acceptance criteria (this is a very common mistake).

If you are maintaining data within a system it is common practice to perform CRUD Analysis, create a CRUD matrix. This will help you to ensure that all data is created, read, updated, and deleted by at least one process. CRUD analysis is an efficient and effective means of ensuring that your user stories are compete in themselves. Eventually, all data needs to be fully maintained by a system. Performing CRUD analysis early will give a better appreciation of the eventual scope of your project.

Sized

It is important to size each user story, epic or task in your backlog. Why? So that you can plan and prioritise the work. Although many teams will use the idea of t-shirt sizes or story points, these are of limited use as they are inconsistent and have no absolute meaning. We recommend:

Tasks are sized in staff hours or staff days.
User stories, specifically functional user stories are sized in COSMIC Function Points (CFPs).
Epics can usually be estimated in CFPs.

Nb. CFPs for a team are usually readily convertible to estimated hours. For more on COSMIC Function Points.

Prioritised

Backlog items should prioritised. Priority (and sequencing items of similar priority) should be determined with at least the following considerations:

Value of the functionality to the business, including likely usage
Size (determines the likely effort to deliver).
Impact on the business of delaying this. Cost of Delay.
Technical relationship of this functionality to others, ie technical dependencies
Risk of unknowns that might lead to a significant change in other work done.

A common technique for mapping some of these considerations to a numerical value is called Weighted Shortest Job First (WSJF).

Colin Hammond, 2022