I have been in several different companies, and they have the same approach to their backlog: their backlog is a junkyard of ideas, thoughts, problems, and discussions that happened a long time ago. Someone, diligently cataloged those ideas, reviewed them, possibly, but it never left the depths of the unprioritized wasteland that is their backlog. Is this a problem? Possibly. It depends on the problems you are having.
An archaic and overwhelming backlog can mean a few things.
1. No one is Saying No
One cause of an unwieldly backlog of past ideas is an uncontrolled funnel. Gathering feedback and ideas is a great thing in the world of software development (well, even in general). However, what are you measuring that feedback against? Does that feedback line up with your product’s vision? If so, then that may be a springboard for some great features that will end up moving the product forward. If not, are users aware of what your vision is for the product? Do you have someone actively monitoring that funnel and pruning back the ideas so that the ideas that have a certain value are held in there. The backlog should be a treasure trove of great ideas and possible direction that you can take the product instead of a mess of incoherent ideas and one-off work. Someone has got to say no and why to ideas. Otherwise, things that don’t matter will fill your backlog with noise. Software can solve problems, but it isn’t meant to solve everyone’s problems. Sometimes, there are other avenues to solve things. If you have someone attentive to the funnel, are they exploring those options to find where leverage with technology make sense and where manual improvements can provide more value.
Have someone say no and filter out the feedback. But do it in a way that you share the vision and objectives of the program with that person giving feedback. If you can get them aligned with that vision, feedback will align with that goal or vision and would inherently hold more value.
2. A lack of direction or Focus
This is somewhat related to the first reason that a backlog may be overwhelmingly large; being unclear about the priorities of a company leads to work item sprawl. The better your value stream is defined and understood, the better your discovery work can be focused on delivering solutions to that value stream. The work leveraging technology has to be in line with delivering meaningful solutions to that value stream. If those strategically setting the direction of the company don’t agree on that value stream, or even do not understand what the value stream is, it will lead to various paths and turns for discovery. With that directionless discovery comes a backlog of conversations, placeholders that never become a meaningful set of work for development teams.
Be clear on what your value stream is in your business. The company exists to solve a problem. The solution to that problem is your value proposition. The delivery of that proposition is your value stream. You can make that delivery more efficient, more valuable to your end users by leveraging technology in a focused manner to iterate on that delivery or solution. When you are adding items to optimize that value stream, you need to have a baseline of what that change may do in the overall system and the investment required for that change. Not understanding your value stream leads you to a backlog that lacks focus.
Not all changes are good; some may even reduce the value of your solution. There needs to be an understanding of that value stream followed up by focus on delivering those features that contributes to that stream in the greatest way possible. If you want to kill your team, then give them busy-work or features that will not make an impact on the company.
3. A lack of commitment
Another reason that backlogs can get unwieldly is due to a lack of commitment to the objectives or features you are trying to deliver. Not every feature in development finishes in a neat, short sprint. Some work is going to be larger and take more time. If there is no commitment to the feature and the amount of time it is going to take, you will find your stakeholders getting impatient, and changing priority to get something else done that comes up will happen.
You need to establish a pattern of identifying value. What are the criteria used to estimate an idea’s worth or value? That may be different according to each business, but value requires a definition, agreement, and consistent review for every idea that comes into the discovery funnel. That way, when you are working on a larger feature, and another idea comes up, you can “objectively” score that new idea’s value and compare it to what you are currently doing.
Software development should not be a death march. If there is a change in a current feature’s value compared to something else, then you are free to change up what the team is working on. Just know that you should be cognizant of the amount of waste that the change creates as well as the social consequences (drop in team or individual morale, context-switching, etc.).
4. A Lack of Maintenance
A final cause of an out-of-control backlog may have nothing to do with stakeholders, prioritization, or shifts in business; rather, this reason is obvious: no one is maintaining the backlog. Even if your input process is super clean and orderly, a backlog still has the propensity to atrophy into chaos. Development is sometimes a messy process. Work items can be created last-minute, technical problems may cause a shift in what makes sense to work on, and documented work may become obsolete. With all that possible churn, ignored, orphaned, or needless items created will eventually need attention.
It is not exciting to prune back things that clutter up a backlog, but it must happen. It is a basic responsibility of someone within the organization. Often you will not find this in a job description, but as a person supporting a development team that responsibility will probably fall to you. It is an under-appreciated and barely noticed activity, but it does help in keeping a backlog easily searchable and useable. Sometimes leadership is just good organization skills and paying attention to the little things.
Why Does This Matter
A backlog reflects the company, its processes, resource capacity and general management. Unfortunately, the likelihood of your backlog being unruly is high; it is a common problem. So, do not worry about the state your backlog is in, but take steps to fix it. The backlog does not have to be perfectly tidy and organized. But, it can be better than its current state. Take some time to evaluate why it might be the way it is, then commit to fixing those items. An organized backlog is a great support to people supporting development teams. You can find things easier, conduct better research and planning, and offer insights into where future value can be realized with less effort.
Agile Insights In Your Inbox!
Get the latest tips, information, and tools to help you succeed in your job right in your inbox. Use the form on the left to sign up!