Mid-Sprint Work: A Budget, Not a Ban

Where did the ban come from?

In September 2025, on day 3 of a sprint, two urgent requests came from the customer one after the other. One was a report bug and one was a permission problem. I cancelled the sprint. My logic was simple: the plan is broken, so let’s make a new plan. The new planning took a day and a half. To keep the calendar, the new sprint ended on the same day as the old one. On day 4 of the new sprint, a third urgent request arrived.

I learned the wrong lesson from this. I made a rule: “no new work in the sprint”. If something urgent came, it would go into the next sprint. Bugs in our own code in production were the only exception; customer requests were not. The rule looked clean on paper. For two months it seemed to work. No outside cards entered the board.

The message on 5 November showed me why. The customer had learned the rule, and they had also learned how to get around it. Urgent requests no longer went to the Product Owner. They went to the phone of the developer who had solved a similar problem once. In the next morning’s daily, Ahmet’s card had not moved for a day, and nobody knew why. In the same sprint we had also set the WIP limit to 3, so two rules were stacked on top of each other. This was one of the “five pieces of work off the board” from the WIP limits post. The sprint started with nine items and ended with seven done. In the retro someone said: “Our estimates are bad.”

What is an unplanned work budget for?

In Sprint Planning, I wrote that you should take a buffer for unplanned work out of your capacity. I also wrote that the buffer should be based on the real share from the last three sprints. When I wrote it, I thought this was easy. When I sat down to measure it, I found nothing to measure. Most unplanned work had never reached the board. I had suggested a buffer, but there was no data to support it.

The budget idea accepts one fact: work will arrive in the middle of the sprint. A customer will hit a bug in production. An auditor will ask for a report. An integration will break. This work is not the enemy of the sprint. It is part of the team’s job. The question is not “Will it come?” The question is “How much will come, and where will it go?”

A budget gives you two things. First, the commitment becomes realistic, because capacity kept for unplanned work is not promised to planned work. Second, decisions get easier. When urgent work arrives, the discussion is not “Should we take it?” It is “Is there room in the budget?”

How it should work

1. Every interruption gets a card

We turned the rule around: work can enter the sprint, but not without a card. From 10 November, every piece of unplanned work became an “interruption card” in a different colour on the board. In the same sprint we had set our WIP limit to 4, and the rule “no work off the board” started on that day too. Interruption cards count toward the WIP limit. One card that is urgent “today” may push the limit over by one.

INTERRUPT-007
Requested by    : customer accounting (A. Kaya)
Channel         : phone -> forwarded to PO
Arrived         : 18.11.2025 10:20
Urgency         : TODAY | THIS SPRINT | CAN WAIT
Triage decision : TODAY  (decided by: PO, 10:35)
Time spent      : 4 hours  (written when the card closes)
Removed from sprint: -    (filled only if the budget is used up)

# Rule: "Time spent" is written when the card closes. It is a measurement, not an estimate.

2. Triage: three boxes, one decision owner

Every interruption card goes into one of three boxes. Today: if it waits, the customer loses money or reputation. This sprint: it is important, but waiting two days does not break anything. Can wait: it is really a backlog item, and it goes to the next refinement.

The PO chooses the box, within 30 minutes. If the request came to a developer, the developer politely forwards it to the PO and opens the card. The developer’s job is not to decide how urgent it is. The developer’s job is to make it visible.

3. Measure the share, then set it

For the first three sprints we did not set a budget. We only counted. We committed the old way. The goal was to see the real number.

The “could have waited” column surprised me the most. 9 of the 34 cards, 4 person-days, were not really urgent. Someone had just asked loudly. We took them out of the budget. The other 18 person-days make 6 per sprint. Our team’s plannable capacity is about 39 person-days, so 6 / 39 = 15.4%.

In the example in Sprint Planning I had written 15% for the buffer. The measured number was close, but that was luck. In another team it could be 5% or 35%. Do not copy the number from someone else. Count your own cards.

4. When the budget runs out, swap

The budget is 6 person-days. A “today” request that arrives after the 6th person-day still gets done, but it is not free. A piece of work of the same size goes out of the sprint and back to the backlog. The team does not choose which item goes out. The PO does, because ordering is the PO’s job. The team only gives the size.

The opposite is also true. If less than half of the budget is used by day 7 of the sprint, the team pulls the next item from the backlog. The buffer is not free time. An unused buffer becomes data for a smaller share in the next sprint.

Cancelling a sprint: the only valid reason

I need to go back to my mistake in September. When I cancelled that sprint, its main work was still valid: the first version of the refund flow. The only thing that had changed was the load. Cancelling did not reduce the load. It added a day and a half of planning, and the urgent work arrived in the new sprint too.

The only valid reason to cancel a sprint is that the sprint goal no longer makes sense. If the customer dropped the feature, a regulation changed, or the product changed direction, there is no point in running toward that goal. Then continuing the sprint is waste. The decision belongs to the PO.

If the load is high, the answer is a budget, not a cancellation. If the load goes over the budget every sprint, the answer is still not cancellation. You need to ask a different question: should this team really work in sprints? If 40% of the work arrives unplanned, it is time to ask Scrum or Kanban again.

How it breaks

From the field: not more work, the promised work

From 22 December we planned with a budget. The capacity on paper did not change: the 15% buffer from the Sprint Planning post was already taken out, and we still committed 33 person-days. What changed was the rule for the buffer. Before, it was a guess, and every sprint went over it quietly. Now it was a measured budget, and going over it meant a swap. The first reaction came from the PO: “If the capacity is the same, what will change?” My answer was: “The work we promise and do not finish. We will stop promising it.”

We need to be honest about these numbers. In the budget period we did not finish more items: 20 against 19. The number of committed items per sprint also fell from 8 to 7, but the reason was not the budget. It was the production layer we added to the Definition of Done in December. Time spent on unplanned work also stayed roughly the same. What changed is this: we finished 91% of what we promised. Of the 2 unfinished items, the PO removed 1 on purpose, with a swap. In the sprint of 5–16 January, interruptions went up to 8 person-days. We were 2 person-days over budget, so the PO moved a two-day reporting story to the next sprint. Nobody was surprised in that sprint’s review, because the decision was made on 15 January and the customer was told the same day.

The 9 cards in the “can wait” box went to the backlog. 4 of them were dropped in the next refinement. So one in four “urgent” requests turned out to be not worth doing once it cooled down.

A message like the one on 5 November came again. This time Ahmet forwarded it to the PO. The PO said “today” within 15 minutes, and a card was opened. In the next morning’s daily, everyone knew why Ahmet had spent half a day on other work.

The budget is not a cure

Interruption cards had one more benefit: we could see where the work came from. When I grouped the cards from six sprints by source, the table pointed to one place. About a third of the interruptions came from the reconciliation report: rounding errors, missing rows, wrong date ranges. The message on 5 November had also come from there.

The budget made this work manageable, but it did not reduce it. Every sprint, we spent person-days on the same kind of bug in the same report. We opened a story to rewrite the report’s calculation layer, and the PO put it at the top of the order. It became the first item of the sprint that started on 2 February. I do not know yet if it will really reduce the interruption share. I will measure it with the same table after three sprints.

A budget measures the fever and keeps the team working. It does not cure the illness. If interruptions come from the same source every sprint, that source also deserves a place in the backlog.

What to watch

• Interruption person-days per sprint. This is the share itself. Look at the three-sprint moving average.
• Box distribution. If the “today” share grows, either the product is fragile or triage is loose.
• Share of commitments kept. This is the real measure of the budget, not the number of items done.
• Number of swaps. If you swap every sprint, the share is too small.
• Source. If half of the interruptions come from one module or one person, the problem is not the budget. It is that module.

Checklist

Conclusion

On the evening of 5 November, Ahmet did the right thing: he solved the customer’s problem. What was wrong was that he had to hide it. The rule that forced him to hide it was mine.

The ban gave me a feeling of control, but it made me lose control. The budget accepted mid-sprint work, counted it and gave it a price. We did not finish more work. We finished the work we promised.

Unplanned work is not the enemy of the sprint. Invisible unplanned work is.