5 Tips for a Better Product Backlog
Written by Josh Ettwein, Director of Software Engineering, MatrixCare
As a Product Owner, it is your job to maintain an up-to-date product backlog that the entire team can work from to produce the end product. Many Product Owners struggle with this, for a variety of reasons. Some have trouble conveying the product vision, while others may find themselves frantically working mid-sprint to get workable stories ready for the team.
1. Always Have a Long-term Product Roadmap or Charter
Well before writing any actual User Stories, plan out the major goals and features you would like to include in the product. For each major goal, make sure you are clear in the business value that each high-level feature provides. Oftentimes, these high-level goals will wind up becoming epics in your backlog, containing user stories. Building your product backlog using your roadmap or charter as a guide seems like an obvious strategy, but many Product Owners let the backlog drift away from the initial vision they created for the product.
2. Keep the Backlog Small
A common mistake that I see many Product Owners make is that they use the product backlog as a “dumping ground” for any and every idea that pops into their head. The net result of this is a backlog that has so many user stories and other product backlog items (PBIs) in it, that determining priority becomes almost impossible. It’s very difficult to prioritize a backlog with hundreds (or more) items, and refinement becomes a daunting exercise. Keep your backlog small, with only enough stories to cover 3 or so sprints worth of work. I find it much more effective to have a smaller, well-defined and organized backlog than to have a gigantic collection of user stories that are nothing but placeholders for ideas that may never even see the light of day as we get further into product development.
3. Vague Can be Good
Along the lines of having a small backlog of well-written stories, I also find it helpful when starting a major milestone to keep initial PBIs at a rather high level, rather than in the weeds in terms of detail. This helps you to align the backlog to the high-level goals in your product roadmap, and also allows you to convert many of these items into epics as needed when the individual item is too large to function well as a user story. Keeping the stories vague helps to avoid being prescriptive in regards to the “how”, and keeps you focused on the “what”. I prefer that user stories are written “for the team and by the team”, and allowing some of the details to come out during refinement helps the team create robust, well-thought-out features and the path to get there.
4. Involve the Developers Early Through Refinement
As mentioned above, stick to specifying the “what”, and not the “how”. Let the developers solve for the latter– it’s what they do best. Hold regular (we do this twice a week at MatrixCare) backlog grooming/refinement sessions, that are 2.5 hours long each. That may seem like a long time, but you’ll most likely find yourself at the end of many sessions wondering how you only refined 5 stories and ended up with more stories than when you came into the meeting. This is ok. When the team writes the stories, the team, and ultimately, the product is better off for it.
5. Don’t Forget the NFRs
Along the way, you will inevitably find yourself in the situation where you have non-functional requirements (NFRs) that you must take into consideration. Writing your NFRs as user stories, in the same format as your other stories will help remind you later what the reason for the qualitative requirement was. If you simply write the requirement up as, “Latency when saving patient data should be no greater than 500ms”, you may lose the reason that you had the requirement in the first place. Writing the same requirement up in the voice of a user story, where the reason for the NFR is clear, can help everyone remember why the NFR is important to the success of the product.
I hope you find these tips helpful when working with your product backlog!