What to do When Your Product Backlog Runs Dry

It’s happened to us all. You stare smugly at your backlog. It’s perfect. It’s a work of beauty and you’re all set for sprint planning tomorrow. You pat yourself on the back, grab a coffee and make a few little tweaks to some of the user stories. A warm feeling inside is a mixture of self-congratulation and eagerness to get started. You’re awesome.

Then you get an email. That the thing you had so beautifully scoped out and prepared is now no longer able to start; there’s been some hold up from legal or some other annoyance which means you’re going to have to pause the work until further notice. WTF.

Panic sets in. Sprint planning is tomorrow and that thing you thought you could start working on suddenly isn’t happening. The board of execs haven’t decided what they want to do next. You’re doomed.

You’ve officially reached a moment every PM dreads: the backlog has run dry and you’re not sure what to do next. Your engineers need feeding and you’ve run out of food.

It’s something product people rarely speak about but it’s a surprisingly common phenomenon where you’re super busy but the backlog isn’t quite ready with things that can be worked on just yet because something shifts or gets pushed back or another part of the business is holding up an approval process which prevents you from starting. This means your engineering team are, quite rightly, looking for things to do, the business is pressuring you into deadlines and wants constant updates but the work you thought was ready to go has now been stalled and you’re going to have to come up with a plan B. In 1 day.

So what do you do when this happens?

The truth is, this shouldn’t happen. You should never reach a point in your backlog where 1 feature / project is the backlog! You should ideally have 2 or 3 sprints of work well defined in advance so that even if 1 feature / project is delayed you have a bunch of other bits that can be picked up in the meantime. That’s the ideal textbook scenario. The reality of life as a PM, as we all know, is different 🙂

We’ll look at the solution to this in 2 parts:

1. The short term – what to do in the immediate term before your next planning session.
2. The long term – what to do to prevent this ever from happening again.

Short term solutions

These things typically happen with 1 day’s notice before your next planning session so you don’t tend to have much time to put together a plan B. It’s time to think on your feet and make sure your team are productive and you’re still getting stuff done that’s both high priority and valuable to the business.

1. Re-engage with your goals and your business backlog

Take a step back from the panic of the moment and spend a few minutes re-engaging with your goals and your business backlog. Close down Jira, Pivotal Tracker, Trello or whatever it is you’re using to manage your project and pull out your goals instead, and start writing on a piece of paper.

What are your goals for the next few months? What are your key results?

With your goals and key results specifically in mind, take a look at your backlog again and decide what key pieces of work can be tackled now.

Taking a fresh look at your goals can help you to re-prioritise quickly and ensure the work you’re doing aligns with your vision.

2. Move planning until you have tangible things that are ready

If there really is nothing that can be started on immediately, move your planning session back a day or 2, buying you some time to put together some well scoped out pieces of work that add value to the business and get you closer to your goals.

As a product manager, you’re in control of the planning process and if you need more time, you get to decide when the next session is.

3. Pick up some tech debt

If you’re not in a position to get started on the feature that you had in mind, ask the engineering team to conduct an analysis of tech debt that’s been accumulated over the past few sprints and to clearly define what impact this is having on current and future development efforts.

When it comes to tech debt, ask the team to be as specific as possible about what the nature of the technical debt is and decide together what it is important to tackle it now, based on the impact it might have on future iterations.

On a practical level, your backlog should be clearly tagged with filterable labels so that you can tag tech debt tasks and prioritise them accordingly.

If there’s a window of opportunity, it’s always a good idea to do some housekeeping and pick up some tech debt.

4. Fix bugs

The other aspect of house cleaning that can be looked at is bug fixing. OK, your product shouldn’t be filled with bugs and you should always fix bugs but there are cases when bugs are deemed to not to be a high priority for one reason or another. If you’ve got some time, prioritise some of the bugs you have sat in your backlog.

5. Address some low hanging fruit

If you re-engage with your business backlog you’ll no doubt see a few things in there that are high impact and low effort which have been lower in the priorities because of that project that now can’t be started! It could be a small request from your sales team to make a change to the backend tool that your enterprise customers have been using, an email formatting change or some other simple but effective change that has been requested a few times but you’ve had to push back in the past.

Now could be the perfect opportunity to take a look at some of these low hanging fruit.

A note here: I often find it worth sharing with your engineering teams the impact that small changes like these can have. If it impacts stakeholders or customers, be sure to let the team know that a small tweak has had a profound impact on X or Y metric. Your team will be surprised and motivated that their work, no matter how small, does actually have an impact.

6. Check action items from your last retro

Were there action items from your last few retrospectives that you didn’t get round to implementing? Agile teams should be documenting their action items from retros and this is a good opportunity to check in with your team and ensure that the agreed items from the previous retro are being implemented.

7. Have a grooming session with the team

OK, so you can’t actually start work on the thing you wanted to do. Get over it. Instead, sit down with your team and have a spring clean. You’ll no doubt have accumulated some rubbish which can be binned and needs to get off the backlog.

Grooming, a word typically reserved for stroking dogs with brushes, is a great habit to get into once in a while. It’s essentially taking some time out of your typical planning routine to ‘groom’ the backlog and ensure it’s in tip top condition and junk free. The best way to keep your backlog is to keep 2 separate backlogs; one for the business which can be a dumping ground for ideas and inbound requests and 1 which is more neatly defined and scoped out for the engineering team. However, even with this distinction in place, your engineering backlog can still get clogged up with useless crap.

Grooming is a great way to identify the things which are out of date, no longer relevant or should never have been on the backlog in the first place. Let your engineers tell you which technical chores can be binned and which ones need to stay and why. Prioritise accordingly.

8. Speak to fellow product managers

In smaller organisations there might be a few separate product teams who are ultimately working towards the same goals but with feature sets distributed between the teams to ensure all the work gets done. If you’re not ready with your work just yet, there could be scope to help out with another team’s work. This is rarely possible since both engineering teams would need knowledge of the codebase but it is worth exploring with your fellow product managers if you’re genuinely struggling.

9. Revisit user research recommendations

Remember those old usability testing videos you did a few months back with a bunch of recommendations that you never got round to implementing? Perhaps now is the time to bite the bullet and implement some of the concrete recommendations the UX guys told you you should do but were not prioritised until phase 2.

You’ve officially reached a moment every PM dreads: the backlog has run dry and you’re not sure what to do next. Your engineers need feeding and you’ve run out of food.

Longer term solutions

OK, now that the immediate panic is over, and your team are engaged with work to do over the next 2 weeks which isn’t what you originally had in mind but is nonetheless valuable and aligns with your goals, it’s time to do a post mortem on why you ended up in such a precarious position in the first place. A sudden shift in priorities on 1 project shouldn’t push you off track so easily, so it’s time to take some action to prevent it from happening again in the future.

1. Build your vision, set your goals, build your backlog

If there’s genuine lack of product direction, address it, and put a direction in place. If you’re the leader, take the lead. If you report to a Senior PM or Head of Product, speak to them and figure out what the vision is and what your priorities are for at least the next 3 months.

An excellent way to put a strategy together is to get out of the building. Take yourself and your team away from your building and re-engage with your business goals. A business without goals is like a bee hive without pollen; lots of busy bees buzzing around the place but not knowing why they’re doing what they’re doing and making a lot of noise in the process. It’s remarkable the number of businesses who actually fail to put goals in place and the result is a mess.

In product management, you cannot exist without goals. You need to be working towards goals and measuring your success against those goals. Your overall strategic direction needs to be defined and your roadmap should be built around the goals set.

You and your team should be able to reel off your quarterly goals and objectives from memory. Stick them up on the wall and force feed them to everyone you meet.

2. Get answers on the things that are blocking you

Too often, especially in larger companies, projects float around in no man’s land with no one quite sure what’s holding up the process, who is responsible and what needs to be done next.

You are responsible for your product and if development is being held up you need to figure out:

1. What exactly is blocking you
2. Why
3. Who is responsible for ensuring this gets resolved promptly and a decision made where appropriate

Apply pressure wherever necessary to get answers to the things that are blocking you. If you don’t get the necessary answers, speak to as many people as possible and escalate the problem as far as you can. Applying pressure doesn’t mean being an arsehole; it means clearly articulating why you need it resolved and what the downstream implications of not having this resolved are.

3. Speak to stakeholders to understand why sudden shifts happen

If things suddenly veer off-course with little warning or visibility, it’s a good idea to get to understand why this might happen in the first place.

Speak to your stakeholders to get a deeper understanding of the forces in play that affect that part of the business. What is it that caused this shift and how can it be made more visible earlier on in the future?

Operations, sales, marketing, legal and 3rd parties all influence the direction of a project / feature and a cross functional approach to product development can help identify problems earlier on in the process.

4. Have multiple streams of work prepared

If you have a clear strategy in place, your roadmap will undoubtedly contain a bunch of projects, features and initiatives and you’ll have prioritised a few of them in any given quarter. Try and get as much of the details of each of these items nailed up front so that you’re not in a position where 1 project is your backlog.

Sometimes, when you’re in the middle of a large project you don’t want to think about the horizon and what’s coming up next but in order to stay a few sprints ahead you’re going to need to set aside some time now so that the future is more manageable. Put in the meetings with your stakeholders, UX / design teams and get the ball rolling on the other work streams so that your discovery phases are nearing completion and can move quickly into delivery once your current iteration is over.

However, that isn’t to say that you need to plan the next year of your product in advance! The whole point of being agile is that you have the agility to shift direction quickly and adapt to changing business requirements. If a sudden shift does happen, take a deep breath and calmly evaluate your options for a plan B. You’ll soon discover that there’s plenty of them.