Lean backlog handling
Having a high-quality backlog is a cornerstone of lean-agile development. The backlog is a central part of agile software development. Whether you’re doing Scrum, Kanban, or any of the scaled agile approaches, virtually all methodologies have a backlog as the central artifact of storing upcoming and current work. Because of its central role, handling the backlog well and keeping it lean is a necessity to unlock the possibilities of agile development.
Having well formulated and concise items in the backlog is a must, but it is just the start. Keeping the backlog itself lean and useful is equally important. After all one has to be lean to be agile. If a backlog too much irrelevant or outdated information it becomes unwieldy and a nuisance to those working daily with it.
Keep it short
Running a lean software development means refining just enough backlog items to the ready state to never run out work and rigorously tracking what is currently work in progress. The benefit is that people work on what they consider to generate the most value from today’s standpoint. Keeping a short backlog shortens the cycle time from story1 inception to delivery. Having frequent conversations between the developers, the product owner, and even the stakeholders to define what currently brings value is a must and is a very effective way of enabling frequent delivery.
Everything in the backlog that is not important for daily work is a distraction
Lean backlogs are short. Ideally, anybody on the team should be able to recall 80% of the items in the backlog at any time. A rough idea about what the story is about is good enough, no need to remember all the details of a story all the time. After all, we write the details down so we don’t need to remember them constantly. Anything that is beyond the mental capability to keep in active memory goes into the product vision or if needed in an agile roadmap. The backlog is a working document on which the team works every day. Everything that is not important for daily work that is in there is just a distraction.
I like to have at most a few weeks of work in a backlog at any time. Enough to not be surprised by what comes up, but also not so much stuff that I feel overwhelmed by it. A good practice is to frequently go over the backlog trying to put a date for further refinement on any item in the “new” column. Anything that is not “ready to work on” or anything that the team can’t put a date for refinement on is thrown away. If a story is important, the team should be willing to put in effort into it now (or at least very soon). If not it is not important.
Intentions instead of ideas
A good backlog contains actionable items, not rough ideas. The tendency to keep anything that comes to mind into the backlog, because “we might do it later” is counterproductive. Rather sooner than later the “we will do it later”-items will clutter the backlog and it will become confusing. Having an endless “todo”-list in front is very demotivating, especially if most of the todos are very vague and are very unlikely to be done anytime at all. The goal is that the backlog is a valuable list containing only relevant items.
There is no problem with putting a quick note as a reminder into the backlog if a new idea pops into mind during a daily conversation, but then refine it to a ready-to-do story as soon as possible or discard it. Lack of time or lack of will to put a date for refinement onto an idea is an indicator that this idea is not as important right or good as it might have been felt when it came up. Delete it - if it is really important it will either come up again. If in doubt make the sponsor of the idea responsible for bringing it up again at a later when there is more time or energy at hand.
Are we willing to put in effort into this item now?
Frequently ask your team “are we willing to put in effort into this backlog item now?”. If the answer is no, discard the item. Else have that conversation now or schedule it to happen very soon. This removes the mental load of discussing things that “might come up eventually” over and over again and it gives the team and customers some reliability on what is going to be done and what not.
Outcomes instead of tasks
A backlog is not a todo-list for developers, it is a list of problems and intents the team is trying to solve. Describing what to do instead of what the outcome of an item is is a common mistake. This often prematurely narrows down the solution options and curtails the discussion about what problem the software is going to solve. Knowing what problem the software solves is of much more value than knowing what to do. There is nothing more expensive than doing the wrong thing.
The backlog is a central piece aiding the communication between stakeholders, the product owner, and the developers. Putting only technical tasks in it, will make its contents often incomprehensible for the stakeholders or the PO, whereas putting the problem in will make the intended outcome of a feature more accessible for the developers who will have to do it.
Having outcomes or problems to solve in the backlog is a good way to shift the discussion to what benefit a software brings instead of what the development is going to cost. A much more productive way for looking at software development than always thinking of it as an expensive chore.
Tame your backlog
A well-handled backlog is a great enabler for teams to create a constant value stream. So if I only get 5 minutes to talk to people who struggle with lean-agile software development, I ask about their backlog-handling. Often I can already point out some improvements within minutes. Organizing a backlog well is a skill a team can and should train and the best time to start is now.
The initial effort of reducing a “backlogzilla” to usable size might be a bit of effort, but iterations for improvement can be very fast. Everybody uses the backlog daily so spotting improvements should be easy. Don’t hesitate to bring it up in a daily sync meeting.
-
In this article I use the term “story” and “backlog item” interchangeably, no matter if an item follows the “user story” pattern or not ↩