Kanbrum: Agile for businesses that change their minds

Businesses change their minds.

A customer escalates something. A commercial assumption falls apart. A competitor ships first. A security issue appears. Something that mattered last month suddenly does not matter at all.

Pretending those changes will politely wait for the end of a sprint is a recipe for disaster.

This is why I use Kanbrum.

Kanbrum is my opinionated version of Scrumban. Scrumban tends to start with Scrum and borrow some flow ideas from Kanban. Kanbrum goes the other way. It is Kanban first. I keep continuous flow, a pull system, work-in-progress limits and a properly ordered queue. From Scrum, I steal the few recurring practices I find genuinely useful: refinement and estimation.

There are no sprints. There are no daily stand-ups. There is no ritualistic planning session where everyone agrees what the business will care about for the next two weeks, despite knowing that may change by Tuesday.

The central idea is simple:

Most engineering teams do not need sprints. They need one honest queue, disciplined flow and just enough recurring collaboration to keep work ready.

This is not a universal framework. It is the approach that has worked for me, the teams I've ran and the businesses I have worked in. Take what is useful. Bin what is not.

Why I stopped using sprints

The question I am regularly asked is: "When can you do this?"

In a sprint-based process, the answer is often "next sprint". That sounds precise, but it usually is not. It might mean the item enters a sprint in two weeks. It might sit behind six other stories. It might roll into the following sprint. The sprint boundary gives everyone a comforting date while hiding the queue underneath it.

With Kanbrum, my answer can be "next".

That does not mean immediately. It means this is the next item the team will pull when it has capacity. Its position is visible. The work ahead of it is visible. If the business changes its mind, the queue can change with it.

Once someone starts a normal piece of work, however, we commit to finishing it. Changing priorities rearranges what comes next. It does not create a trail of half-finished tasks across the board.

The only exception is a genuine incident. Production is down. Customer data is at risk. There is a material security, compliance or revenue problem. Shit's on fire. That can interrupt active work.

"Someone important asked loudly" is not an incident.

TL;DR

Kanbrum gives the business flexibility without turning engineering into chaos.

Product can reorder future work whenever business value changes. Developers finish what they have started, clear down code reviews before pulling more work, then take the next item from one authoritative queue. Leaders get forecasts based on actual throughput rather than the false certainty of a sprint boundary.

In practice:

One exactly ordered queue per delivery team. There can only be one "next".
One active delivery task per developer. Reviews come first, and the team swarms bottlenecks instead of starting more work.
Work reaches Ready for Dev only when it has clear context, acceptance criteria, an estimate, no blockers and a deployable vertical slice.
Blocked is a tag, never a status. Stuck work stays visible in the stage where it is stuck until the team unblocks it.
Weekly refinement creates shared understanding. Weekly estimation exposes ambiguity and splits oversized work.
Daily peer programming replaces status theatre with real problem-solving, knowledge sharing and unblocking.
Done means deployed and validated. "Ready for Release" is still unfinished work.
Delivery is forecast from queue hours and a six-week rolling throughput average, then reforecast without blame when reality changes.
Flow is measured through cycle time and throughput. Success is measured through the business KPIs the work was meant to improve.

The queue can change. The commitment to finish does not.

That's Kanbrum in a nutshell, but if you want to know the detail - read on.

One queue per team

Each delivery team has one ordered queue.

If you have one engineering team, you have one queue. If teams are split by product, each product team has its own queue. The boundary can vary, but the rule cannot: developers should not have to choose between competing priorities.

If several Product Managers feed the same team, they resolve priority between themselves. If they cannot agree, the decision moves to whoever is accountable above them, such as a Head of Product. Ultimately, business value decides.

Developers should be able to finish a task, check whether anything needs review, then take the next item. They should not need a meeting, a manager or a debate in Chat to know what matters.

Exact queue position is authoritative. Priority labels can provide context, but two things cannot both be next.

Prioritisation needs a shared language

Kanbrum depends on a prioritisation method that everyone understands and applies consistently.

The exact method is up to you. One example I use is:

Priority score = Impact + (Urgency x 2)

Impact and Urgency are each scored from 1 to 10, where 1 is highest. This produces a normal range from 3 to 30, with lower scores taking priority mirroring the P1 or P2 we typically see used.

Scores 1 and 2 are reserved as overrides. They mean: drop everything, shit's on fire.

The formula is not Kanbrum law. The important part is having agreed criteria across the board, then using exact queue position to settle the final order. Technical debt, security and maintenance work compete in the same system, using business value, risk and future cost.

Priorities will move. That is a feature, not a failure. A Product Manager might add work that will matter in three months and initially place it low in the queue. As the deadline approaches, it is their job to raise it before it becomes an emergency.

Forecasting without sprint theatre

Kanbrum forecasts delivery using queue hours and observed throughput.

I use a six-week rolling average of estimated hours that actually reached Done. It is measured at team level, not used as a stick for individual developers. Known capacity changes such as leave, hiring or a major operational commitment should be factored in.

Imagine a fictional team called Northstar. Over the last six weeks, it has completed an average of 120 estimated hours per week.

A new feature sits behind 180 hours of ordered work. The feature itself is estimated at 36 hours. Assuming the queue and capacity remain broadly stable, work on it is likely to begin in roughly one and a half weeks and finish around two working days later.

That is a forecast, not a promise. If the business moves the feature higher, the forecast changes. If an incident interrupts the team, the forecast changes. If the team learns that an item ahead is larger than expected, the forecast changes.

This is more honest than saying "next sprint" and hoping nobody asks what that means.

Forecast accuracy is worth observing because it helps improve planning. It should not be used to punish people for discovering complexity. Punishing honest reforecasting only teaches teams to hide bad news.

The board

My default workflow is:

Idea / Backlog
Ready for Refinement
Estimating
Ready for Dev
In Development
Code Review
QA
Ready for Release
Done

The names can change. The meaning should not.

An idea can sit in the backlog without being fully formed. Once Product believes it is worth the team's attention, it moves to Ready for Refinement and receives a priority. Refinement starts at the top and works down. Estimation starts at the top and works down. Engineering starts at the top and works down.

This means low-priority work may wait a long time for refinement or estimation. Fine. Spending hours polishing work that may never be built is not good planning.

I do not impose an arbitrary maximum backlog size. If Product has identified valuable work, I want to see it. A large valuable backlog can be evidence that the business needs more engineering capacity. A tiny backlog with idle engineers can show that Product needs more capacity. Hiding either signal behind a made-up backlog limit helps nobody.

Product should still tidy the backlog regularly. If an idea no longer has value, delete or archive it. A backlog is not a museum.

The board is the truth

Product Managers and Product Owners should look at the board.

The task tatus is there. The queue is there. The blocker is there. The estimate is there. If the board cannot answer a specific question, ask it asynchronously in Chat. Do not create a recurring call so people can read the board out loud.

This requires discipline from everyone. Developers update work as it changes. Blockers are flagged. Remaining estimates are corrected. Product keeps priorities ordered. QA moves work honestly. If the data is stale, the entire system becomes fiction.

"No task, no work" is a blunt rule, but a useful one. Side quests destroy visibility, forecasting and prioritisation.

What makes a task ready

A task cannot enter Ready for Dev because someone wrote a title and added a vague paragraph.

It needs:

Clear context and a defined outcome.
Acceptance criteria that describe what success looks like.
An hour estimate covering all work through deployment and validation.
No unresolved blockers.
Enough shared understanding that any suitable developer could pick it up without another meeting.
A deployable vertical slice of value.

That final point matters. I do not want separate frontend, backend and database tickets moving through separate queues and eventually hoping to meet in production. A task should represent something that can be delivered and validated.

If the slice crosses the stack, the developer works across the stack.

I like full-stack engineers. People will naturally have deeper expertise in particular areas, and that expertise is valuable, but ownership stays end to end. If the owner needs help, they pair with the specialist. They do not throw part of the task over a wall and wait for it to come back.

Keep the slices small

Anything estimated above three working days gets challenged. Can we split it into smaller, independently deliverable slices?

Seven working days is my hard ceiling, except in genuinely extreme cases.

This is not because larger work is automatically bad. It is because large tasks hide ambiguity, delay feedback and spend too long as invisible risk. If a piece of work genuinely cannot be split, fine, but "we couldn't be bothered to find the seam" does not count.

A useful vertical slice does not have to contain the whole feature. It needs to produce a coherent, deployable change. Feature flags make this much easier because deployment and customer release no longer need to happen at the same time.

One active task per developer

The default work-in-progress limit is one active delivery task per developer.

Before pulling a new task, developers check for code reviews. Reviews come first. Finishing work already in the system is more valuable than starting more work. This also goes for the morning, when you start your day or come back from lunch - check for code reviews.

The same principle applies when work piles up in QA or Ready for Release. Stop pulling. Swarm the bottleneck. Local productivity means very little if nothing reaches Done.

"Ready for Release" is not Done. Merged is not Done. Development complete is not Done.

Done means deployed and validated against the acceptance criteria.

Continuous deployment is the default, although a Product Manager may choose to bundle related changes. Feature flags often make that decision much less painful. Code can be safely deployed while the customer-facing release waits for the right moment.

Blocked is a tag, not a status

I hate blocked statuses.

A blocked status is where work goes to die. It moves out of the stage where the problem occurred, disappears from the team's immediate flow and becomes somebody else's future archaeology project.

Blocked is a condition, not a workflow stage.

If a task is blocked in development, it stays In Development and receives a blocked tag or flag. If it is blocked in QA, it stays in QA. The work-in-progress limit continues complaining at you every day until someone gets it unblocked.

That discomfort is useful. The board should make stuck work impossible to ignore.

The owner records the blocker and actively escalates it. They only pull another ticket if they are genuinely waiting for somebody else and cannot make progress themselves. Even then, the original item remains visible in its real stage.

What I steal from Scrum

Kanbrum keeps two weekly sessions: refinement and estimation. I usually run each for one hour.

Refinement

Refinement ensures everyone understands what is being built.

Product, developers, QA and any relevant design or domain experts discuss the task together. They clarify the ask, remove fluff, expose dependencies, challenge assumptions, improve acceptance criteria and split the work where a different slice makes more sense.

The output is a task that is clear enough for anyone suitable to pick up, once it has been estimated.

Refinement is not Product reading tickets aloud while everyone else waits for lunch. It only works when the people in the room are focused and willing to challenge the shape of the work.

Estimation

Estimation exposes ambiguity and splits oversized work.

Developers and QA lead the estimate. Product attends to answer questions and clarify scope, not to negotiate the number down. If credible estimates differ, discuss the assumptions and use the higher credible estimate rather than averaging away the risk.

I estimate in hours because that is what the business needs.

Story points are intentionally abstract. That can protect teams from false precision, but it also forces somebody to translate points back into time whenever the business asks about cost, capacity or likely delivery. I would rather make the uncertainty explicit and use hours as a forecast.

An estimate is not a commitment. It is the team's current best forecast based on what it knows.

If new information appears, update the remaining forecast without blame. The old estimate does not become more useful because everybody agrees to pretend it is still correct.

Peer programming instead of stand-ups

I replace daily stand-ups with a one-hour peer programming block.

This is genuine working time. The team pairs on problems, reviews code, shares knowledge, teaches unfamiliar parts of the stack and helps unblock active work. People join by default because there is nearly always something to learn. If someone genuinely needs to skip, they can.

The stand-up outcomes happen naturally.

Someone says: "I'm working on this and I'm stuck on Y. Who can help me?"

Now the team knows what they are working on, knows where they are blocked and, more importantly, starts solving the problem. We get the useful signal of a stand-up without taking turns reciting yesterday, today and blockers to people who could have looked at the board.

Status is a by-product of doing the work. It is not the purpose of the session.

Use ceremonies when they are useful

Kanbrum does not ban meetings. It bans meetings that exist because the calendar says so.

I run demos when there is something genuinely useful to show and when the audience benefits from attending. Otherwise, release notes, change logs or an automated Chat channel are enough.

I also like weekly tech office hours. Anyone in the business can join, ask questions, see something demonstrated or get help understanding a technical issue. It creates access without filling every engineer's calendar with speculative meetings.

Retrospectives happen after meaningful milestones, difficult delivery periods or when the flow data shows a problem worth examining. A retro after launching a whole product makes sense. A retro because another fortnight passed may not.

The ceremony must earn its place.

Measure flow, then measure the business

Cycle time and throughput tell me whether work is flowing. Ageing work and blocked time help diagnose where it is not.

They are operational measures, not the final definition of success.

Engineering is a team inside a business. Its job is to move that business forward. If the agreed objective is increased conversion, reduced operational cost, improved reliability or lower customer churn, engineering ultimately succeeds when those measures improve.

A team can complete a lot of tickets and achieve absolutely nothing useful.

I do not measure individual developer utilisation or ticket output. That creates incentives to start work, avoid difficult problems and optimise personal numbers at the expense of the team. Kanbrum is designed around team flow and business outcomes.

Where Kanbrum breaks

This approach is flexible, but it is not loose.

It needs an agreed prioritisation method. It needs exact ordering. It needs strong Product Managers who can distinguish value from noise and raise future work before it becomes urgent. It needs engineers and QA who engage properly in refinement and estimation. It needs clear acceptance criteria, deployable vertical slices and a board that reflects reality.

It also needs empowered cross-functional engineers. If every change requires several departmental hand-offs, one active task per developer will expose that pain very quickly. That may be uncomfortable, but hiding the problem would not fix it.

Kanbrum also relies on everyone accepting that forecasts change. If leaders demand certainty where none exists, people will pad estimates, hide problems and manipulate the board. You will get nicer reporting and worse delivery.

Finally, it requires discipline around finishing. Without WIP limits, reviews-first behaviour and swarming bottlenecks, "pick next" becomes an excuse to start interesting work while boring work rots in QA.

A copyable setup

If you want to try Kanbrum, start here:

Create one ordered queue for each delivery team.
Agreea shared prioritisation method and make exact queue position authoritative.
Use the nine board stages listed above.
Treat blocked as a tag, never a status.
Set one active delivery task per developer.
Make code reviews the first priority before new work.
Require clear context, acceptance criteria, an hour forecast, no blockers and a deployable vertical slice before Ready for Dev.
Challenge tasks above three days and cap them at seven except in extreme cases.
Run one hour of refinement and one hour of estimation each week, always from the top of the queue.
Run a daily one-hour peer programming block as genuine working time.
Stop pulling and swarm whenever review, QA or release becomes a bottleneck.
Define Done as deployed and validated.
Forecast using queue hours and a six-week rolling throughput average.
Reforecast remaining work when reality changes, without blame.
Use demos and retrospectives when they provide value, not because a template demands them.
Measure cycle time and throughput to understand flow, then judge success using business KPIs.

That is Kanbrum.

It gives the business the freedom to change its mind without asking engineering to abandon work every few days. It gives Product a visible, honest way to express value. It gives developers a simple answer to what they should do next. And it keeps just enough structured collaboration to make sure the next task is actually ready.