10 things your product backlog should contain, and 6 things it definitely shouldn’t.
What is a product backlog
The product backlog is a single ordered list of all the proposed changes or additions to a product.
Each product backlog item describes everything required by the development team to actually perform the work.
The product backlog is usually presented in expected delivery order, taking into account dependencies and other delivery constraints.
10 things your product backlog should contain
By the above definition, anything that is a change or addition to the product. Examples being:
- Developing a new web page
- Developing a new operator interface
- Developing a new API
But also:
- Upgrading a NuGet package
- Upgrading a database version
- Switching to use a different vendor API
- Refactoring existing code
- Reducing technical debt
- Modifying the CI/CD pipeline
- Changing a configuration value
(probably other things too)
6 things your product backlog should NOT contain
By the above definition, anything that is NOT a change or addition to the product. Examples being:
- Performing some analysis
- Putting together a presentation
- Attending team meetings
- Making a phone call
- Writing a requirements document
- Taking a lunch break (don’t laugh, I’ve seen this before)
How can I tell if something should go on the product backlog?
It’s not always clear cut and sometimes it’s a judgement call.
But if you are having trouble deciding whether something should go on the product backlog, here are some useful guidelines to keep in mind:
- Does it change the product?
- Does it involve checking something into source control?
- Does it require testing?
- Does it require release processes to be performed?
- Do customers or stakeholders need to be informed?
Answering “Yes” to one or more of these is a good sign you should create a new product backlog item for consideration by the team.
What happens if you include non-product work in the backlog?
You obscure the most valuable metric (throughput of product changes or additions).
Perhaps most importantly, you dilute the team focus away from shipping new and improved product versions to its users.
Which is the primary way that agile/Scrum teams deliver stakeholder value.
If you are unhappy with your development team, they may need more detailed guidance.
Better software requirements can help with this.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |