Top Five Reasons You’re Wrong About Needing a Large Backlog
Most of these happen because people are confused about what, exactly, a backlog should be in an Agile environment.
But we have a lot of work to do! – You are confusing activity with value. Backlogs measure value, not activity.
The old way to do project management was to use a Work-Breakdown Structure (WBS). It took a lot of work and broke it into smaller pieces which would be assigned to individual team members to accomplish. This was great if one person was able to completely understand everything required to breakdown the work, but that is not true in technology development. In fact, the reason you hire people instead of robots is that you can’t predict how they will solve certain problems. So you give them the problems and let them work it out. Instead of a Work-Breakdown Structure (WBS), you need to create a Goal-Breakdown Structure (GBS). If that sounds like the same thing just with different words? Then you don’t get it.
Goals are tests that describe value, not actions. They are the problems you are giving people to solve. So a backlog is a series of progressively-described tests. When the tests pass, the goals are met. How the tests get to the passing state is up to the workers. Your job as backlog owner is to create tests with more and more detail the closer you get to actually doing the work, not pre-digest work. Remember: the backlog is about useful things you’re providing the users, not useful things you’re doing. If your focus is on yourself, it’s in the wrong place.
Without a huge backlog, we’ll lose track of important details! – You make this mistake when everything is a blade of grass, but nothing is the lawn. It stems from the belief that lots of tiny things have more value than one big thing. If your backlog is goals, not tasks, then goals have natural hierarchies, right? A lot of detail about those goals goes higher up in the hierarchy so it doesn’t have to get repeated everywhere. (In fact, if you think about it, the only extra information needed for the backlog item should be the last few bits of information to make this goal different from similar ones under the same parent. The rest of the information is already in place. DRY.)
You can store as much detail about anything you like, just not in the backlog. That’s not what it’s for. People stick all kinds of crap into their backlogs: database tables, to-do lists, design notes.
Another way of looking at it is this: the backlog exists to easily let the people-solving-the-problems work with the people-they’re-trying-to-help to make sure they’re solving the right problems in the right order. Once it becomes incomprehensible because of size, it ceases to fulfill its mission. Instead it becomes an artifact, a deliverable, a paperwork tiger, an obstacle, not a facilitator to rapid value delivery. Backlogs, like all the rest of your tools, are supposed to make you go faster, not slower.
How else can I keep track of what people are doing? – I don’t know. Maybe ask them? A lot of teams do a daily standup where they talk about how the value delivery is going. (Poor teams focus on “Important stuff I did yesterday”. Good teams focus on “I am trying to deliver this value and I could use some help”.) Hang out there and listen to what’s said.
There are a lot of Agile folks who will wave their hands around and say something like “Stop being a micro-manager”, but I get it: somebody should be looking at how big teams are, where teams should be formed or shut-down, who should go to which division, and so on. There is a people management skill that’s required in businesses of any size. It’s just backlogs aren’t the tool to do people management. There’s a recurring theme here: the minute you stop focusing on value delivery and start focusing on activity, you end up with a lot of activity and very little value delivery.
So whatever your management needs are, you should handle them in some other way. (Which is outside the scope of this essay)
But we need to coordinate at a low level with Team X! – In a lot of corporate environments, the work is both pre-digested for the teams and then split out among several “expert” teams.
Wow, does that create a mess. Nobody can do anything without coordinating with another team. It’s all one big hunk of work.
At some point, your job is either to create value or go down a to-do list. If they’re giving you a to-do list, do the to-do list. You will find no value in this essay. But remember: if your job can be done by robots? It will be done by robots. Having a job where everything can effectively be broken up 3 months ahead of time by one really smart person should be setting off alarm bells. Something is wrong somewhere.
But we have this huge list of bugs/defects/change requests/feature requests/…! – Yes. I understand. You have this big list of stuff, right? And you also have this tool that handles big lists of stuff! How cool is that?
Aside from the fact that you’ve destroyed the entire purpose of a backlog by making it incomprehensible en toto, here are a couple of things to consider.
Perhaps a big list of anything is just going to lead to endless boring meetings, loss of morale, and a feeling that things are hopeless. Perhaps big lists of things fit naturally into a simple and easy-to-understand hierarchy along with everything else. Perhaps the only things you should be worried about are the things you’re working on and the things you’re getting ready to work on — the rest is useless overhead. Perhaps the entire purpose of a managing a backlog is to prevent this very scenario.
In 1963, a U.S. President stated that he wanted to see, in that decade, a man walking on the moon. Did he deliver the specifications to the Saturn V moon rocket? Of course not. Do you think every week he received details on how hard the guidance team down in Huntsville was doing? Of course not. He stated a test, a high-level goal he wanted accomplished. He received periodic updates as new goals were accomplished: man living in orbit, capsules docking, and so forth. People followed along as each of these sub-goals were met, knowing that with each new capability the moon came closer.
Backlogs can be easy, intuitive, fun, and positive motivators for a team! Yay! Or they can be a micro-management death march. It all depends on what you’re willing to learn — and what you’re willing to un-learn.
Interested in learning more? I wrote the book on effective information management in your project. As it turns out, looking at your processes and workflows in terms of information management can help you figure out where things are going wrong. It’s called “Info-Ops”.
July 4, 2018