Data backlog triage when the team just went remote

I have spent the last two weeks helping teams figure out what to do with their data work now that normal planning routines have collapsed. Every team has a backlog. Almost none of them have a framework for deciding what to do with it when capacity drops suddenly and priorities shift.

This is not about methodology. It is about making a usable decision fast, under conditions where both demand and supply have changed.

What changed that makes the backlog wrong

Most data backlogs were prioritised under two assumptions: the business would continue operating roughly as before, and the team would remain roughly the same size. Neither is true right now.

Some reporting that was important a month ago now measures things that no longer matter. Some infrastructure work that was deferred is now urgent because remote operations expose dependencies that the office masked. Some analytical projects that looked valuable are now serving a strategy that has paused.

Before triaging, it is worth spending one hour answering: what does the business actually need from data in the next six weeks? The answer to that question is likely different from what the backlog contains.

A simple three-bucket sort

I use three buckets. They do not require a scoring model or a committee.

Keep running - work that directly supports current operational decisions. Anything that gives management visibility into what is actually happening: cash position, orders, headcount, operational continuity metrics. This is not the time to let operational reporting degrade.

Pause explicitly - projects tied to plans that have been suspended or strategies that are on hold. Do not abandon them silently. Record where they stopped, what the decision-point was, and what it would take to restart. A paused project with a clean record is far easier to resume than one that just went quiet.

Drop - work with no plausible path to relevance in the next quarter. This is harder to do than it sounds, but it is the right call when team capacity is reduced. Every item you keep alive has a carrying cost: questions, context, mental load, partial states that need maintenance.

The remote coordination piece

The main thing that breaks when a team goes remote is the ambient information flow that happens in an office. People overhear things, questions get answered in passing, priorities adjust informally. In a distributed setup, the backlog takes on more weight because it is one of the few shared artefacts the team has.

This means the triage decision needs to be written down, not just announced on a call. Each item that is paused or dropped needs a one-line rationale. Each item that is kept needs a clear owner and a definition of done that can be understood asynchronously.

One practical step

If you have not triaged in the past two weeks, set a two-hour block this week. Take the top twenty items in your data backlog, run the three-bucket sort, and write a one-paragraph note explaining the new priorities. Share it with whoever in the business depends on data work from your team.

That note becomes the working contract for the next sprint. It will need updating, but starting with something written is better than operating on informal assumptions that vary by person.