Scrum, day 30: too much started work

Today's objective: identify started work that needs attention and propose an explicit limit that helps the team finish without hiding blocked items.

Read alongside: Mastering Professional Scrum, chapter 3, focusing on work in progress. For an optional framework reference, see the Kanban Guide for Scrum Teams. Allow roughly five minutes for this companion, plus the book reading.

Count the work that still needs a finish

Imagine a later morning on the fictional ShiftSwap team. The pending-request slice is under verification. An outdated-action correction is waiting for a review. A filter improvement is partly implemented. A message adjustment is blocked by an environment problem. Two small interface changes have also started.

Everyone has something to report. The team nevertheless has six unfinished pieces competing for attention, and the oldest has been waiting since early in the Sprint. Starting another item would create another claim on the same limited capacity.

The Developers need to inspect the work as a whole. A question about what each person can start next may be less useful than a question about which current item can reach Done and what is preventing it.

Define what you are counting

The Kanban Guide describes work in progress as work started but not finished. Applying that idea requires clear boundaries. ShiftSwap chooses, for this experiment, to count product items from the start of implementation until they meet the Definition of Done.

An item waiting for verification remains in that count. So does a blocked item. Moving a card into a separate “waiting” column does not make the unfinished obligation disappear. The team can distinguish states without excluding the inconvenient ones from its picture.

This local boundary does not describe every kind of work in the organization. Upstream investigation may also need attention. The initial experiment is deliberately focused on the delivery flow where the team currently sees accumulating unfinished work.

Look at age as well as quantity

Six items in progress tells the Developers something about the amount of unfinished work. It does not explain which item needs help. They also inspect how long each has been in progress and why it is waiting.

The oldest item may be blocked by an unresolved question that nobody owns. A newer item may be close to Done but waiting for a brief review. Another may be progressing normally through difficult work. The same number of cards can therefore describe very different situations.

The team should use these observations to choose an action. A dashboard that accurately reports aging work but never changes anyone's next step has limited practical value.

Try a limit as an agreement about starting

The Developers propose allowing no more than three product items in their chosen delivery boundary at once. Three is an illustrative trial value for this fictional team, not a Scrum rule or a universal recommendation.

The agreement means they will normally start another item only when there is room and a credible ability to advance it. When the limit is reached, they first look for ways to help current work finish, remove a blocker, or clarify the next decision.

Because six items are already started, they do not pretend that three have become unstarted. They keep all six visible, stop adding ordinary work, and work down the excess. If an item is deliberately abandoned, that decision and its consequences should be explicit.

Help the work move without creating a crowd

The pending-request slice needs a check of the manager's actual interaction. A colleague who planned to start another visual change can help prepare and examine that scenario. The outdated-action correction needs a review from someone familiar with request state. The team can arrange that review promptly.

Not everybody can contribute equally to every item at every moment. The limit should provoke useful coordination, not force people to hover beside a specialist. Someone may use available time to learn a recurring task, improve a check, or clarify an upcoming item without secretly starting another implementation stream.

If the team repeatedly cannot help because a single person holds essential knowledge, that is important evidence. Raising the limit whenever the specialist is busy would preserve the dependency while increasing the queue around it.

Keep an honest path for urgent work

A production problem may require immediate attention even when the trial limit is reached. The Developers need an explicit way to handle that situation. They can identify the urgent work, discuss what it interrupts, and make the temporary exception visible.

The exception should include a recovery decision. Which existing item will wait? Who needs to understand the consequence? How will the team return within its limit? The product impact matters more than maintaining an attractive number at all costs.

If urgent exceptions happen every day, the team should inspect the pattern. It may need a different allocation of capacity, changes to product quality, or a conversation about what stakeholders call urgent. An exception policy cannot substitute indefinitely for understanding recurring demand.

Inspect the effect without promising a miracle

After trying the limit, ShiftSwap examines completion times, aging items, interruptions, and the effort required to coordinate. It also checks whether the completed work still meets the quality standard and advances the Sprint Goal.

Fewer started items do not automatically guarantee better outcomes. The team might discover that items remain too large, an external dependency dominates waiting, or the chosen limit obstructs useful work. Those observations can guide an adjustment.

The optional Kanban practices support Scrum's existing inspection and adaptation. They do not remove the Sprint Goal, replace the events, or turn a card count into a measure of user value. The team needs both a dependable flow of work and evidence that the resulting product helps people.

Choose one thing to stop starting

List the work your team has started and not finished, including blocked and waiting items. Choose a clear start and finish boundary. Identify the oldest item and the next concrete action that could move it toward completion.

Propose a small experiment with a work-in-progress limit. State what counts, what people do when the limit is reached, how urgent exceptions work, and when you will inspect the result. Use a number that responds to your actual situation rather than borrowing one as a universal rule.

Reflection: if nobody could start another ordinary item today, which unresolved dependency or habit would become impossible to ignore?

The next section examines quality, value, and planning. Start with day 31: quality throughout delivery.