Stop Starting and Start Finishing: The WIP Principle That Changes Everything
Most delivery teams start too much. The structural reasons for this are clear, the costs are measurable, and the practice of finishing requires deliberate design.
In 1948, Taiichi Ohno observed an American supermarket and returned to Toyota with an idea that would eventually transform manufacturing. The insight was about pull: systems work better when they produce what is needed, when it is needed, in the quantity it is needed.
The Agile community absorbed this through Lean and crystallized it into a principle that most practitioners can quote and almost none fully apply: stop starting, start finishing.
It sounds obvious. The practice of it is not.
Why Teams Start Too Much
The pull to start new work is structurally reinforced in most organizations:
Starting feels like progress. When a team picks up a new story, estimates it, assigns it, and updates the board, there is a sense of movement. The work feels managed. It is not finished, but it has been handled. That sensation of handling creates false confidence.
Stakeholders reward starting. When a stakeholder asks about their feature, "we've started it" is a better answer than "we're finishing other work first." The social reward for starting is higher than the social reward for sequencing carefully.
Multitasking is normalized. Most delivery teams operate with team members assigned to multiple work items simultaneously. When work requires waiting -- for review, for a dependency, for clarification -- starting something else feels productive.
Work in progress is invisible by default. Unless a team has an explicit WIP limit and enforces it, the number of items in progress grows until the team has more items started than they have team members.
The Cost of Too Much In Progress
The cost of high work in progress is cycle time. The more items are in progress simultaneously, the longer each item takes to complete. This is not an opinion. It is a mathematical property of queuing systems, well-documented in Lean manufacturing and confirmed empirically in software delivery teams.
Beyond cycle time:
Context switching taxes. Every item in progress requires context. Returning to partially-completed work requires rebuilding that context. Research consistently shows meaningful productivity loss from context switching between unrelated work streams.
Blocking compounds. When a blocked item cannot move forward, teams typically start something else. That new item may also hit a block. The team accumulates started-but-blocked work. The board becomes a record of things that are not getting done.
Integration complexity. Multiple items in progress means multiple items that will eventually need to integrate. The longer they are developed separately, the more integration complexity accumulates.
Visibility loss. When a team has twelve items in progress and four team members, it is not clear what the team is actually committed to delivering this sprint.
What Finishing Actually Requires
Finishing requires choosing. Specifically, it requires choosing not to start a new item when the socially rewarding choice is to pick one up.
Practically:
Explicit WIP limits. Set a limit on the number of items in progress at any time. A common starting point is half the team size. One item per person is not a WIP limit -- it still allows everyone to have their own work stream. A team of six with a WIP limit of three has to coordinate who is working on what.
Definition of Done as a finishing gate. Use the Definition of Done as a signal that an item is genuinely complete, not just "done on our side." An item is not finished when it passes developer review. It is finished when it is deployed and the stakeholder can verify it works as expected.
Swarming on blockers. When an item is blocked, the default response should be to swarm on removing the block, not to start something else. The team's highest-leverage action when a high-priority item is blocked is usually to identify and remove the block, even if that means some team members are temporarily working on something outside their specialty.
Pull, not push. Team members pull the next highest-priority item when they have genuine capacity, rather than having items assigned to them at the beginning of the sprint. This creates natural sequencing toward completion.
The Retrospective Conversation
Stop Starting and Start Finishing is a productive retrospective topic. The questions that surface useful data:
- How many items were in progress simultaneously during this sprint?
- How many items were started but not finished?
- What percentage of our cycle time was waiting time versus active work time?
- What did we start that we should not have started?
- What did we not finish that would have had the most impact if finished?
The answers to these questions tell a clearer story about the team's delivery system than velocity metrics.
The Sprint Goal as a Finishing Mechanism
A well-formed sprint goal can serve as a WIP limit at the sprint level. When the team commits to a clear sprint goal, it is easier to say no to work that does not contribute to that goal. Stories that compete with the sprint goal become explicit distractions rather than invisible additions.
Teams that struggle with starting too much often lack a genuine sprint goal. They have a sprint backlog -- a collection of items -- but not a commitment to a specific outcome. The sprint goal creates the pressure to finish because the team has a definition of what finishing means for this sprint.
Frequently Asked Questions
What is the right WIP limit for our team?
Start with team size divided by two, rounded up. For a team of six, that is three. Run it for two sprints and measure the effect on cycle time. If you are finishing items faster, stay there. If the team is idle while waiting for blockers, the limit may be too low. The right WIP limit is empirically determined, not theoretically derived.
Does WIP limiting work in a Scrum context?
Yes, though it is more commonly associated with Kanban. Scrum does not prohibit WIP limits. Many teams run effective hybrid approaches: Scrum for iteration structure and sprint goals, Kanban-style WIP limits for workflow management within the sprint.
How do I convince the team to adopt WIP limits when they resist?
Show them the data first. Track cycle time for a few sprints without WIP limits. Then introduce limits and track the change. Teams that see cycle time improve are easier to convince than teams asked to accept constraints on faith.
Stay Current with Agile Pulse
Practical delivery intelligence for teams working on flow, WIP, and delivery system improvement. Weekly. Free.
AI-assisted delivery dashboards can make WIP visibility automatic, but the discipline of limiting work in progress remains a human coordination decision that no tool resolves.
