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
Backlog Refinement Automated
10x Your Backlog Refinement
ScopeMaster automates the following analysis activities
- Detects the user in each story
- Detects the object types involved
- Detects the probable functional meaning
- Checks for potential ambiguities
- Checks for common language ambiguities
- Determines the functional size (CFP)
- Highlights potential inconsistent user terms
- Highlights potential inconsistent object terms
- Automates CRUD analysis
- Determines potential duplicate functionality
- Determines potential missing functionality
- Generates a suggested data model
- Generates Use Case Model Diagram
- Determines a quality score for each requirement
- Determines a quality score for a set of requirements
… and more. Discover all the features
Other articles on this topic will discuss story splitting and story elaboration. We consider these terms to be a bit vague. We have been more specific because it is important to be so. A wrong word in a requirement can lead to it being misinterpreted and potentially hours and hours of waste, if the code needs to be rewritten.
Further reading from external sites
I struggled to find many articles that I can strongly advocate. I do recommend this book Software Requirements, by Karl Wiegers and Joy Beatty