Do You Write Product Backlog Items?
Writing Product Backlog Items (PBIs) is a very common responsibility of Agile Business Analysts. However, it’s often a task which varies widely from one Business Analyst (BA) to another. It’s like asking 100 people, “Do you work out?”. Even if each person answers “yes”, the way everyone does so can vastly differ from one person to the next. Chances are many of you reading this “write product backlog items”, but that statement is largely ambiguous.
Why is this important? Writing consistent and well-structured PBIs significantly improves your teams’ odds of building the right solution the first time. Can you imagine how difficult it is for our project sponsors or product owners who go from one Business Analyst to the next and must adjust to a completely different approach? How are they going to be confident that the team will continue to hit their key milestones? It can feel like switching from an automatic transmission vehicle to a manual one; it’s quite the change (albeit you’re still in a car and can still get around town).
Another key consideration is the phrase “junk in, junk out”. If you provide poor, inconsistent, and / or inadequate requirements to your development team, what kind of outputs do you think they’ll produce? Lastly, applying a standardized approach to documenting PBIs builds consistency in how your product owners, stakeholders, technical teams, etc. will review and implement on them. This can improve the overall efficiency and effectiveness of the team.
3 Core Components of PBIs
There are three core components to product backlog items that I’ll detail below and share an approach which has served me well across projects, clients, and industries. They contain helpful tips you can start applying to your PBI authorship.
1. Title
The title field is meant to be brief but informative (to both business and IT audiences) and should hint towards the deliverables of the product backlog item. These should always be written in terms of business value (and not in “tech speak”). A good way to think about your title is to relate it to a newspaper headline. It should be short and sweet but also have enough information to attract your user to be interested in diving deeper. Whichever approach you use, be consistent in applying it so looking at the backlog from a macro level can be easily understood. This is especially true for prioritization efforts. I recommend writing or finalizing your title last after the description and acceptance criteria (detailed below) have been completed.
2. Description
The description field is used to define the background context of the deliverables and why those deliverables are being considered valuable.
The description should always include documentation of the current state, the need (otherwise known as the problem or opportunity), as well as the desired future state. Too often Business Analysts only document the latter and omit the former two items. For example, it’s not valuable to automate an accounting process for the sake of automation. Rather, it’s valuable because the Accounting team invests 60 hours each month in repetitive and manual steps which delay the sending of invoices – as well as the distribution of employee paychecks. It’s only within the context of the time investment on the Accounting team and the implications of that investment each month does the value of automating those processes become evident.
This field can and should contain storytelling elements which highlights the need to be addressed. Without the Accounting team story I told above, the expected value is harder to picture. Include those stories like Jim in Sales who lost 10 deals this last quarter due to an inability to send a statement of work from his phone, or about Jane in Marketing who has fielded customer complaints about the complexity of an intake form but does not have user analytics to measure conversions nor drop-offs. Use the description field to tell their stories.
Lastly, this field doesn’t need to be lengthy. My sweet spot is normally half of a page in MS Word. Don’t write a novel. Focus on telling a story, depicting the current state, documenting the need, and defining the desired future state.
3. Acceptance Criteria
The Acceptance Criteria (AC) per the BABOK are “used to define the requirements, outcomes, or conditions that must be met in order for a solution to be considered acceptable to key stakeholders”. This is the most importation part of the product backlog item as it defines how successful implementation will be measured. This will prove (or disprove) that the deliverables from the PBI will solve for the need which was identified in the description. This is not a copy of the description, but rather a result of sifting the description’s contents down to its key outputs to be implemented.
I tend to utilize a blend of rules-oriented and scenario-oriented bullet points when documenting acceptance criteria (grammatically correct sentences aren’t necessary). Whichever approach you use can then serve as a starting point for test case creation and execution. Ensure your Acceptance Criteria is (reasonably) unambiguous on non-negotiables. What’s documented in your AC is what your product owner expects to be delivered. Be clear and specific with them – as well as with the implementation team – to improve your odds of successful delivery.
Attachments (Bonus Tip)
A recommended best practice is to include any email conversations, designs, screenshots, recordings, etc. related to your product backlog item as an attachment to it. These artifacts all serve as supportive documentation, even if somewhat crude or rudimentary. This helps ensure one source-of-truth regarding a given set of deliverables.
Conclusion
Enabling consistency in practice regarding the titles, descriptions, and acceptance criteria of product backlog items can reap many benefits. Here are several (but certainly not all):
- Your backlog items are easily understood at both a macro and micro level.
- Prioritizing (and re-prioritizing) the efforts can be more efficiently performed.
- The current state, need, and desired future state provided in the description will provide context for your technical team and can validate results after delivery.
- Acceptance Criteria can be reliably used to measure successful implementation of a given product backlog item.
- Auditability and traceability efforts become significantly easier to implement across the backlog.
I’m optimistic that you, too, will find that these tips result in improved odds of success for your teams.
