What did 50 Business Analysts Say Were their Biggest Challenges with Backlog Management?

Our May 8th 2023 BBC Workshop : The Backlog is Broken – Here is How We Can Fix It

During our Rock Crusher workshop at Building Business Capability (BBC) we asked 50 Business Analysts to call out the challenges they were experiencing managing their backlogs. This is the raw data, and it is revealing:

    • Hard to prioritize among 3 different departments
    • Not enough developers or QA
    • Backlog is more about the process than business value
    • No clear goals
    • No fully transformed projects coming in with long end dates [that are] years out
    • No understanding or definition of ready
    • Too much work coming in
    • Doing work the old way
    • Fractured resources
    • No clear leadership for backlog
    • Siloed Dev/QAs
    • Never know what is enough or too much detail
    • Things change, and updates to are had to do in most places
    • Organizing takes thought
    • Scope changes and additions
    • Establishing priorities.
    • Large teams, greater than 20 “resources.”
    • Hybrid approach and not doing either well
    • Developers dictating code writing
    • Our products are small, and we don’t have a deep backlog. We work on multiple products at a time
    • Unnecessary user stories
    • Obsolete stories
    • Using Kanban instead of sprints
    • Loose prioritization
    • No discipline to follow the backlog and limit WIP
    • Not enough leadership support
    • User stories with end dates estimated poorly / unrealistically.
    • Making sure acceptance criteria is on user story
    • Changing priorities and assigning priorities
    • The external to do list that does not get proper prioritization or discovery work
    • Fluff in the backlog to justify needing more resources
    • Cross team planning and prioritization creates conflicting priorities
    • Lack of backlog grooming and clean up
    • So many parties involved with pulling from the backlog with lack of collaboration or prioritization.
    • Fear of forgetting a great idea
    • Many “shell” cards
    • Help find the “walking skeleton” and be confident it’s a good start
    • Too old not accepted as a reason to delete
    • Who owns the backlog? Makes the decisions? Too many cooks in the kitchen
    • Nice to have versus must have, MVP mis-understanding
    • Backlog not cohesive
    • Switching resources in the middle of projects
    • Prioritization! How?
    • Team maturity, some do not know where to start. Some don’t want to be told what to do
    • Tech debt sticks around
    • Prioritize once and don’t revisit
    • Backlog tool, new and different tools across company. Different ways to use it
    • Maturity
    • We say “later” and not “no”
    • Priority by line of business but value lost at solution level
    • Dependency management
    • Articulating the business value…who? Why?
    • Lack of discipline in ceremonies
    • How to stack up the non value add stories against the value add
    • Story writing
    • Prioritizing key items
    • Size of stories , right sizing for consumption
    • The requirements are not correct

I want to thank all our workshop participants for sharing with us. My first sad reaction to this data is there is nothing new here. I have seen this data before. I suppose there is some comfort in knowing colleagues from across the industries are experiencing similar challenges, and we are not some outlier.

There are numerous themes in this data, from too much WIP (Work In Progress), lack of discipline, to no clear priority. It’s the “no clear priority” theme that really concerns me because this is pretty much why the backlog exists. The backlog is the single source of prioritized work the team pulls from. Prioritizing work means the team is working on the most valuable backlog items. Pulling work balances the limited capacity of the team with the demand for work by the enterprise. Pull systems avoid the coordination delays associated with high levels of work in progress and congestive collapse. For organizations that know their priorities, it is a system that predictably delivers superior economic value.

Unfortunately, this data suggests that most of these enterprises do not know their priorities, and the backlog is just a reservoir of un-prioritized pre-committed work for the team. What is worse is the data reveals numerous examples of where backlog items are pushed into the team rather than the team pulling the work (e.g., too much WIP, not enough team members, unrealistic due dates). The backlog is just a Gantt chart in disguise. As one participant called out, “…hybrid approach [waterfall and agile] and not doing either well”.

Here is the bottom line: if our enterprise is not capable of saying “this before that” and is not capable of saying “no,” and if our enterprise cannot work as a pull-based system, then you will not gain any economic advantage from agile practices. Our workshop offered the Rock Crusher as a modern model for better backlog management. However, if an enterprise is incapable of deciding its priorities, then there is no agile framework or methodology that will do that for them (outside of a random number generator). After all, the Rock Crusher and agile practices in general, provide fast learning cycles that can help you make better decisions. But they cannot make the decisions for you.