Anyone who has led a data team past a single quarter will recognise the picture. The request queue keeps growing, the analysts keep complaining that nothing ships, and the engineers insist they are working flat out. Dashboards are late, a handful of tables break every Monday, and the roadmap has quietly become a list of apologies. When a team finally audits the mess, the cause seldom traces back to weak people. It traces back to an undifferentiated queue in which a legally required report sits next to a pet visualisation, both marked “high priority”.
This post treats that situation as a diagnosis problem. We look at the evidence you can gather in a day, name the underlying cause, and then walk through a remedy: a ranking that puts a short list of non-negotiable data needs ahead of everything else, and demotes the remainder to tie-breakers. The aim for a DataOps practitioner is faster decisions with less regret, not a prettier backlog.
Symptom: a queue where every row is urgent
Export your ticket tracker for the last ninety days and look at the priority field. In many teams the distribution is lopsided: the large majority of items carry the top two labels. If most of the queue is “urgent”, the label has stopped carrying information. Requesters learned that unlabelled requests get ignored, so they escalate by default, and the team learned to discount the labels, which pushes requesters to escalate harder.
Three further measurements usually confirm the picture.
- Age of the oldest “high” item. If something flagged urgent has sat for two months, the flag is decorative.
- Work-in-progress count per engineer. A person juggling six “critical” tasks is context-switching, and throughput drops with every switch.
- Rework rate. Count requests that came back with “that is not what I meant”. High rework suggests the underlying need was never separated from the proposed solution.
Root cause: no distinction between needs and preferences
Dig into the individual tickets and a pattern emerges. A finance lead needs a reconciled monthly extract by a fixed date because auditors will ask for it. A product manager would like a cohort chart with six filters. A data scientist wants a feature table rebuilt from scratch because the old one is untidy. All three arrive with similar urgency language. Only the first is a hard requirement; the others are wishes with advocates.
Without a rule for telling them apart, the team defaults to first-come-first-served or loudest-voice-first. Neither correlates with consequence. The result is that real obligations compete for attention with comforts, and sometimes lose.
Remedy: a short, written list of non-negotiables
The remedy is a two-tier policy agreed with stakeholders before the next planning cycle.
- Tier one: musts. A request qualifies only if missing it would cause a compliance breach, a contractual penalty, a customer-visible error or a stoppage of a downstream job. Each must is written with its reason and a named requester.
- Tier two: tie-breakers. Everything else. These are ranked among themselves by effort and reach, and they are scheduled only after tier one is covered.
The cap matters. If tier one grows beyond what the team can deliver in a cycle, you have discovered a capacity problem, and that is a conversation about hiring or scope, not about relabelling.
A worked ranking, using a prioritisation vocabulary
Teams that like established vocabulary can borrow the “must, should, could, won’t” scheme from product work. Applied to data requests it looks like this.
- Must: freshness and completeness guarantees on tables that feed regulated reporting.
- Should: documented ownership for each production table, so incidents have a first call.
- Could: a self-serve metric catalogue with search.
- Won’t, this cycle: a rewrite of the legacy staging layer that nothing currently depends on.
Notice how the ranking ties to consequences. The “must” is defined by who gets hurt if it fails, not by who shouts. If you want to see how checks on data quality are usually expressed in practice, a hands-on tutorial on declaring validation rules with Great Expectations shows the mechanics. Those checks are the technical expression of a “must”.
Evidence the remedy works
Do not take the policy on faith. Define a small before-and-after comparison and run it for two cycles.
- Share of the queue labelled top priority: expect it to fall sharply once labels require a stated consequence.
- Median time to deliver a tier-one item: expect it to shrink as work-in-progress shrinks.
- Rework rate on tier-one items: expect it to fall because the reason is written down at intake.
- Stakeholder complaints about “ignored” requests: expect an initial rise as wishes are demoted openly, followed by a decline once people see where their items sit.
That last point deserves honesty. Demotion is uncomfortable at first. The policy only survives if the demoted requests remain visible, ranked and revisited, so that a “not yet” is never mistaken for a “no”.
An analogy from outside data teams
The same sorting step turns up whenever people face an overwhelming set of choices. International patients exploring heart care, for instance, are pointed to BestCardiacHospitals, an educational site that lays out how to compare care options, and the site is explicit that it offers education rather than medical advice. The relevance for data teams is simply procedural: you cannot compare options sensibly until you know which conditions are fixed.
Common objections, with evidence-minded replies
“Stakeholders will game the must tier.” They will try. Counter it by requiring a reason that someone else can verify, such as a clause, a deadline or a failing job, and by publishing the tier-one list so peers can challenge it.
“Our work is exploratory; nothing is a must.” Even exploration has limits: a budget, a data-access agreement, a date by which the finding is useful. Write those as musts and keep the open-ended curiosity in tier two.
“Priorities change weekly.” Then review the list weekly. The cost is ten minutes. The cost of an unreviewed list is a quarter of effort spent on items that stopped mattering in week two.
Where transformation work fits
Engineers sometimes ask where infrastructure upkeep sits in this scheme. The answer turns on consequence, as everywhere else. A model rebuild that protects a required output belongs in tier one; one that merely tidies naming conventions is a tie-breaker. If you want the practical side of keeping transformation logic tidy, a walkthrough of building transformations in dbt covers the mechanics, and the ranking above tells you when to schedule that work.
One more check before you adopt it
Run the policy past the people who will be demoted. Sit down with two or three requesters whose items land in tier two and walk them through the reasoning, showing the written definition of a must and where their request falls. People rarely object to a rule they can read; they object to a ruling they cannot explain. If a requester can show that their item meets the definition, move it up and note why. If they cannot, they usually accept the placement, particularly when the next planning date is visible.
Summary of the diagnosis
Symptom: a long queue, stale priority labels, rising rework. Cause: no shared rule separating obligations from preferences. Remedy: a written, capped list of musts with reasons, and a ranked tier of tie-breakers. Evidence: fewer top-priority labels, faster tier-one delivery, less rework. Try it for two planning cycles, measure the four indicators above, and keep the policy only if the numbers move.
