Prioritising project tasks alongside business as usual
A practical guide to balancing long-term project work with the steady stream of support tickets, maintenance requests and day-to-day obligations that keep the lights on.
The pressure no sprint board shows
Picture the scene: the team has a well-groomed backlog, a clear sprint goal and a delivery date that's already been shared with the business. Then Monday morning arrives and with it comes three support tickets flagged as urgent, a content change the marketing team needed yesterday, and an email chain that ended with "can someone just fix this quickly?"
By Wednesday the sprint goal is quietly slipping. By Friday, nobody is quite sure whether they achieved anything at all.
This tension between the planned project work that drives the business forward and the unplanned BAU demand that keeps it running is one of the most common sources of frustration in delivery teams. Personally, i've found handling it well is less about finding the perfect framework and more about making the invisible visible and the unpredictable manageable.
Why both streams genuinely matter
It's tempting to treat BAU as noise in the system: a distraction to minimise so the real work can flow. For the vast majority of cases, that framing is a mistake.
Project work shapes where the product is going. BAU work reflects where users and the business are right now. Neglect either one long enough and you pay for it in technical debt, strained relationships, or a product that no longer fits the people using it.
The goal is not to eliminate BAU demand. It's to give both streams the right amount of attention, in a predictable way, without constantly asking the team to improvise.
Name the two streams clearly
Before any prioritisation conversation can be productive, the product team needs shared language. "Project work" and "BAU" mean different things to different people. Left undefined, they create confusion about what belongs where.
A useful starting point is to separate tickets by their origin and time horizon:
- Project work drives planned change. It has a defined goal, a measurable outcome, and typically feeds into a roadmap or OKR. Examples include new features, refactors, integrations, and research spikes.
- BAU work maintains existing value. It reacts to what's already live; bug fixes, content updates, configuration changes, compliance tasks, third party issues and operational requests that don't fit neatly into a project.
Once the team agrees on definitions, they can be applied consistently to tickets, conversations and planning sessions. Ambiguity will always be the nemesis of prioritisation.
Reserve capacity before you plan
The most reliable way to protect project work is to allocate BAU capacity before the sprint starts and not after things break.
Track how much unplanned demand the team absorbs each sprint over two or three cycles. Even a rough average is enough to work with; If roughly 30 percent of completed points historically come from BAU tickets, reserve a rough 30 percent of velocity for BAU before committing to project stories.
This approach has a few benefits:
- Sprint goals become honest commitments rather than aspirations subject to constant interruption.
- The team stops starting each week feeling behind before anything has gone wrong.
- Stakeholders get a realistic picture of what the team can actually deliver.
If the BAU buffer goes unused in a quiet sprint, that capacity rolls into project work. If it's consumed, the sprint goal is still protected. Either way, planning starts reflecting reality more closely.
Use a simple scoring model to make hard calls
When several tickets are competing for the same slot, a lightweight scoring model removes the politics from the conversation. Two frameworks work well in most contexts.
ICE scoring rates each item on three factors, each from one to ten:
| Factor | Question to ask |
|---|---|
| Impact | How much does this move the metric or resolve the pain? |
| Confidence | How certain are we that this will achieve that impact? |
| Ease | How quickly can we deliver this given current capacity? |
Multiply the three scores to get a single number, then sort descending. High ICE items rise to the top regardless of whether they came from the project backlog or the support queue.
Urgency versus importance is a quicker filter for the moment a ticket lands. Urgent and important work gets done now. Important but not urgent work is scheduled. Urgent but not important work is delegated or batched. Neither urgent nor important work is removed from the queue entirely.
The right model is whichever one the team will actually use. Consistency always matters more than sophistication.
Give BAU a home in the ceremony structure
BAU tickets become invisible when they live outside the normal workflow. Teams that handle them best tend to discuss them first in planning and review meetings.
A few adjustments that can make a practical difference:
- Keep a dedicated BAU column on the board. Separate visibility helps the team see the true cost of unplanned demand without it blending into project progress. When BAU fills up, the team and stakeholders can see why project velocity has slowed and then have a databacked conversation about it if required.
- Review BAU tickets in sprint planning, not as an afterthought. Spend the first fifteen minutes of planning triaging anything that arrived since the last sprint. Categorise, size roughly and slot against the buffer. What doesn't fit then waits in the backlog.
- Report both streams in sprint review. Showing what the team did across project and BAU tells the whole story. Teams that only celebrate project deliverables in reviews unintentionally signal that BAU is invisible toil which then tends to affect morale over time.
Protect flow with a BAU rotation
Context switching between a complex project story and an urgent support request is expensive. Every interruption adds recovery time and repeated interruptions accumulate into hours lost across a week.
A BAU rotation assigns one or two team members each sprint as the first point of contact for incoming BAU demand. Those people triage new tickets, handle quick fixes, and escalate anything that needs the wider team. Everyone else stays in project mode.
The rotation has two effects. First, it keeps a small proportion of the team shallow and reactive, so the rest can stay deep and focused. Second, it distributes the BAU load fairly across the team over time and nobody is permanently in reactive mode.
For very small teams a full rotation may not be practical but even agreeing "today Jane takes BAU lead" is better than having everyone drop what they're doing when a ticket arrives.
Talk to stakeholders before they talk to you
Most BAU pressure arrives with a sense of urgency attached. That urgency is often real to the person raising it, even when it isn't real in an absolute sense. The fastest way to defuse the tension is to have a standing conversation with the people who most frequently generate BAU demand.
A short fortnightly check in with key stakeholders covering what's in the queue, what the team has capacity for, and what will need to wait does more to manage expectations than any amount of reactive communication. When people know there is a process and that their requests are visible, they tend to escalate less.
If certain stakeholders consistently raise high priority BAU items, work with them upstream. Can content changes be batched? Can configuration requests be self served? Can a recurring task be automated? Reducing the volume of BAU demand at source is always worth exploring before simply absorbing more of it.
Watch the signals that BAU is winning
Teams under chronic BAU pressure develop recognisable patterns. If more than one of these sounds familiar, the balance has likely tipped and it's worth pausing to diagnose why:
- Sprint goals are rarely met in full, even when the team works hard.
- The backlog contains stories that have been "in flight" for multiple sprints.
- Team members describe feeling busy but not productive.
- Retros surface themes of interruption, context switching and unclear priorities.
- Roadmap commitments are regularly renegotiated.
None of these signals is a failing. They're information. They usually mean the reserved capacity is too low, the BAU triage process is leaking, or stakeholder expectations need resetting. Each is solvable once named clearly.
A cadence that holds both streams together
No single meeting or tool fixes the project versus BAU tension permanently. What works is a lightweight cadence that creates regular touchpoints for both streams without adding unnecessary overhead:
- Sprint planning — Reserve BAU buffer, triage new tickets, confirm sprint goal.
- Daily stand-up — Flag BAU items that risk consuming more than expected. Surface blockers early.
- Mid-sprint check-in — A quick five minute temperature check on buffer consumption. If it's running hot, revisit scope before the end of the sprint.
- Sprint review — Report both streams. Celebrate progress in each.
- Retrospective — Review the balance. Was the buffer right? Did anything slip through? Adjust for next sprint.
This cadence keeps the conversation honest without turning every day into a firefighting exercise. The team sees the whole picture, stakeholders get regular visibility and the balance adjusts incrementally rather than lurching sprint to sprint.
The underlying principle
Prioritising project work alongside BAU is ultimately about respecting two truths at once: that the business needs to move forward, and that it also needs to stay standing right now.
Teams that handle this well don't treat it as a zero-sum fight between new and existing work. They name both streams clearly, protect each with deliberate capacity decisions and review the balance often enough to catch drift before it becomes damage.
The planning overhead is small. The return in delivered projects, stable operations and a team that finishes Fridays feeling like they actually got something done is significant.