Scrum or Kanban: Not a Methodology, the Way Work Arrives

The wrong question: “Which one is more agile?”

That Friday evening I walked into the retro with a proposal: “Scrum does not fit us. Let’s move to Kanban.” Two days earlier I had read half of a Kanban book, and I had the answer ready. I was asking the wrong question. Scrum and Kanban are not in a race. They are designed for two different shapes of work.

In the first part of this series I made a rough split. Scrum is for product development with high uncertainty. Kanban is for work that flows all the time and whose priority comes from outside. When I wrote that table, I had not noticed that my own team was doing both at once. Our problem was not choosing the wrong framework. It was pushing two kinds of work into one framework.

The whole promise of Scrum rests on one deal. The priority stays fixed for two weeks. In return, the team shows something that works at the end of the sprint. This deal works well when the work can wait two weeks. An escalation from the call centre saying “the customer’s order is not on the screen” cannot wait two weeks. If you put it into the sprint, either the customer waits or the sprint breaks. For us, the sprint broke every time.

Count first: 131 requests in 12 weeks

We did not discuss the Kanban idea in the retro. Instead, one action came out of it. Take the last six sprints (12 weeks) and sort every item that entered the board outside the sprint plan. Selin, our Scrum Master, and I exported the data from Jira one afternoon and labelled each item by hand. This is what we found:

Three things became clear. First, the volume was not an accident. On average, 22 requests arrived every two weeks, and the number never fell below 17 in any of the six sprints. Calling this “unplanned” was fooling ourselves. The work was not unplanned. Our plan was.

Second, all 58 escalations (44%) expected an answer on the same day. None of them could wait for the next planning. Third, report requests were different. They could wait a week, and some of them were a few days of work. They fit into a sprint; they were just coming in through the wrong door.

So there was no single “support work”. There were three ways work arrived, and each one needed a different answer.

Decision table: how work arrives → framework

After that table, we stopped deciding by framework. We started deciding by two properties of the work: how long it can wait, and how early we know about it.

We also set a ratio rule. If unplanned work is below 15% of capacity, a buffer inside the sprint is enough. Between 15% and 30%, you need a buffer plus a daily triage. Triage means a short check where someone sorts new requests by urgency. Above 30%, the work is no longer a deviation from the sprint. It is a separate stream of work, and it needs its own lane. Our ratio in the last six sprints was between 31% and 52%.

The third row of the table got the least attention, but it gave the cheapest win. Report requests used to arrive on Slack, sent directly to one person. That person would squeeze them in as “a five-minute job”. Of the 24 report requests, 9 took one to three days, not five minutes. Now they all come through one form. The PO collects them every Thursday and takes them to refinement. The requester waits a week, but knows when the answer will come. The wait got longer, and the complaints went down. People did not mind waiting. They minded not knowing how long they would wait.

From the field: two failed attempts and one model that worked

Attempt 1: make the buffer bigger

In October 2024, long before we counted anything, this was our first reflex. We left 40% of the plan empty. The logic was simple: support work will come, so let’s make room. It lasted two sprints. Plan completion looked better, because the plan was smaller. But the sprint goal lost its meaning. If almost half the capacity is unknown, nobody takes “this sprint we deliver X” seriously. We had less to show in the review. In the PO’s words, we were doing “full ceremonies for half a sprint”.

A buffer absorbs predictable variation. It does not absorb work that flows all the time. It only makes the plan smaller.

Attempt 2: a fixed two-person support lane

We set up the Kanban lane on 3 February 2025. In the first design, Can and Barış moved to operations permanently. The other four stayed in the sprint. The first week was great. The average time to answer an escalation dropped from two days to six hours.

In the middle of the third sprint, Barış said this in our one-on-one: “Did I just move to the support team?” He was right. While the new order type was being built, neither of them was in any design discussion. They did not know the new part of the product. So to solve escalations about that part, they kept asking the sprint team. We had built two teams, and the bridge between them broke every day. That was our mistake, and mostly mine. I split the work and did not see that knowledge would split too.

What worked: a rotating one-person lane

From 17 March, we turned the lane into a rotation. Each sprint, one of the six people sits in the operations lane. In busy weeks, a second person leaves the sprint, and we remove that capacity at planning time. After six sprints, everyone had sat in the lane at least once. These are the rules:

Classes
  Urgent    same day        (call centre, customer impact)
  Standard  2 working days  (data fix, reconciliation gap)
  Planned   goes to sprint  (report request, work > 1 day)

Rules
  1. The person in the lane does not touch sprint work.
  2. Work longer than 1 day leaves the lane: it becomes a story in the backlog.
  3. If the same category arrives a 3rd time, open a root-cause item.
  4. Order comes from the class, not the PO: Urgent > Standard > Planned.
  5. If the lane is empty, help the sprint; do not pull new work.

Rule two was the most important one. The lane only does short work. Work that takes longer than a day is real development work, and it must go through refinement. Without this rule, the lane would become a back door around the backlog.

Rule three removed a large part of the work. Of the 37 data fix requests, 22 came from the same two reconciliation gaps. We opened two root-cause items and fixed them in two sprints. That category went from 37 to 14 in 12 weeks.

One warning. The first three sprints of the “after” column used the fixed two-person model. The numbers after the rotation are a little better. But I did not want to build a separate table from only three sprints of data.

What stayed, and what changed?

Moving to Kanban did not mean leaving Scrum. Most ceremonies stayed. Only their meaning changed for the operations lane.

The change in the review was more valuable than I expected. Before, support work was invisible in the review. The team spent a third of its two weeks on work that it never showed anyone. Now the lane reads three lines in every review. How many requests came in, which category repeated, and which root-cause item went to the backlog. For the first time, the PO’s priorities started to include the support load.

How does it break?

The hybrid model has its own illnesses. Here is what I saw, and what we did about each one:

• The lane becomes a back door. The PO tried to push an urgent feature in: “It’s small, let’s give it to the lane.” Rule two caught it. The work took more than a day and went back to the backlog. Without a written rule, the discussion would have become personal.
• An empty lane pulls new work. On a quiet day, the person in the lane pulled a new item from the sprint. The next day two urgent requests came in, and the item stayed half done. Rule five came from that day: an empty lane helps, it does not take ownership.
• Rotation hides uneven knowledge. The two people who knew the accounting integration were away, and those requests waited a day. The fix was a one-line “how I solved it” note on every closed request. Three months later, those notes were the start of a runbook.
• Unplanned work goes down, but the lane stays. As root causes get fixed, volume drops. If the ratio falls below 15%, you should close the lane and go back to a buffer. We check this at the end of every quarter. We have not closed it yet.

What to watch

• Unplanned work ratio (time spent on outside work / total capacity). Decision points: 15% and 30%.
• Median waiting time per class. If urgent work goes past the same day, one person is not enough for the lane.
• Number of repeating categories. The same request arriving a third time is a product bug, not support work.
• Sprint plan completion. If it drops after the lane is set up, something is leaking: lane work is moving into the sprint.

Checklist

Conclusion

On 31 January I walked into the retro saying “let’s move to Kanban”. If I had won, the whole team would have moved to flow. We would have lost the rhythm of the sprint for long, uncertain work like the new order type. Because I asked the wrong question, it took two failed attempts to find the right answer.

Today five of the six people work in Scrum and one works in Kanban. That is not inconsistent. Work arrives in two ways, so we meet it in two ways. The methodology debate is over. Every quarter we look at one number only: the unplanned work ratio.

Choosing a framework is easy. Counting how work actually reaches you is the hard part.