Some product backlogs seem to meld perfectly with their team while others are more of a detriment to productivity.
An ineffective product backlog will impact the team in many ways. Team sizing activities become challenging, creating tasks from backlog items takes twice as long as it should, and frustration and lack of trust will be directed at the product owner – impacting relationships, overall health and team flow.
How do you know if your product backlog is ineffective? Here are 8 symptoms:
Hidden. The old product backlog sneak attack. No one has access to the product backlog except the product owner. The product owner has created or updated the backlog in isolation and the first time anyone sees or hears about it is during a sprint planning session.
Stale. The backlog hasn’t been updated or refined in quite some time. I have seen backlogs littered with years worth of requests and defects. Many of the items are no longer valuable and become a distraction.
Coupled. All of the stories must be done or nothing gets delivered. This will often result in numerous sprints needing to be completed before anything of value is completed and deployed.
Unordered. If the product owner were unavailable the team would not know what to do next. There is no prioritization or sequence.
Vague. No one knows what the backlog items are trying to accomplish. There are just a few words for acceptance criteria and the stories lack a connection to a real user need.
Unfocused. Similar to being vague, the overall backlog has a whimsical or half-hearted feel to it. Some of the “user stories” are actually focused on team roles. Ever see a story start with “As a product owner I need…”
Verbose. On the other hand, some backlogs include each item having 3 pages of acceptance criteria and a full requirements document. Find balance by using the retrospective for feedback from the team on the right amount of detail to build and test the story and nothing more.
Disconnected. Similar to being unfocused and vague, backlogs with this symptom have items with no connection to a broader product vision or even worse, from any mechanism to measure how the backlog item will deliver on expected results (a business case or key performance indicators).
In addition to these 8 symptoms here are 2 bonus product backlog “smells.” Depending on the nature of your product (legacy systems, new technologies, etc.) these smells may indicate a problem with the backlog but maybe not.
Lacking experimentation. There are no stories based on an assumption or a hunch. This aligns with the disconnected symptom. We shouldn’t expect a product owner to have all the answers so their backlog may include items like A/B tests to see if key performance indicators can be influenced with a small subset of users.
Low feature/fix ratio. This is only a “smell” as there may be times when a team will need to focus on fixes or removing technical debt. This becomes a symptom of an ineffective backlog when this is ALL the team does and an indicator of a bigger symptom of poor craftsmanship or a complex architecture.
Do you have any tips or techniques to share on how would you resolve these product backlog symptoms? Have you noticed other symptoms of an ineffective product backlog? Please share below.
One reply on “8 Symptoms of an Ineffective Product Backlog”
[…] outlines eight signs for which the backlogs seem to be ineffective and should be actively managed. 8 Symptoms of an Ineffective Product Backlog (Illustrated […]