Most agile teams have a finishing problem disguised as a starting problem. The backlog is full. The sprint is populated. Every team member has tasks assigned. Yet the number of completed user stories at the end of the sprint is consistently lower than anyone expected. The work is happening. The output is not.
The phrase “stop starting, start finishing” is deceptively simple. It is the foundational principle behind Kanban’s Work in Progress (WIP) limits, rooted in Toyota’s Lean manufacturing philosophy and validated across decades of software development practice.
It is also one of the most consistently ignored principles in agile teams, because starting new work feels like progress even when it is not. This post explains what the principle means, why most teams violate it without realising, how it applies to both Kanban and Scrum, and how to put WIP limits into practice.
What Does “Stop Starting, Start Finishing” Actually Mean?
The principle is straightforward: before picking up a new task, complete the one you are already working on. Before starting a new user story, finish the one in progress. Before a team pulls a new ticket from the backlog, it swarms on clearing whatever is currently active. The underlying logic comes from Lean manufacturing. Work has no value until it is in the hands of the customer.
A partially completed feature, a user story that is 80 percent done, a ticket sitting in code review for three days, none of these have delivered anything to anyone. They represent investment without return.
The longer they sit incomplete, the more they cost. Cost builds up in context-switching overhead, in integration complexity as code diverges, and in the cognitive load of tracking multiple open threads at once.
WIP limits make this principle operational. By setting a hard ceiling on how many items can be actively in progress at any given time, for an individual, a team, or a workflow stage, WIP limits force the team to finish before it starts. They are not a constraint on ambition. They are a constraint on the illusion of productivity.
Why Most Agile Teams Ignore This Principle
Starting new work is psychologically satisfying in a way that helping someone else finish is not. Beginning a new task feels like progress. It produces something visible on the board. It generates the sense of momentum that agile rituals are designed to create. The problem is that this psychology is additive rather than completive.
Each new start adds to the total active workload without reducing it. A team that starts ten items and completes five has a backlog of five incomplete items that carry forward, along with context-switching overhead, integration risk, and delayed customer value. There are also structural incentives that work against finishing.
In many organizations, team members are evaluated on contribution to multiple work streams, not on the throughput of completed stories. In Scrum, sprint ceremonies focus on what each person is working on, not on what the team needs to close before anything new is pulled.
The social dynamics of the standup often reinforce individual task ownership rather than collective responsibility for completion. The result is what looks like a high-activity team but functions as a low-throughput one. Everyone is busy. Nothing is finished. The board fills up. The sprint ends with a cluster of almost-done items that carry into the next sprint, compressing capacity before it even begins.
The Real Cost of Too Much Work in Progress
The cost of excessive WIP is well documented and consistently underestimated. Context switching, the overhead of resuming a task after an interruption, costs roughly 20 to 30 minutes of productive time per switch, depending on task complexity. (Source: Mark, G. et al., “The Cost of Interrupted Work: More Speed and Stress,” CHI 2008, University of California Irvine; replicated in Leroy, S., “Why Is It So Hard to Do My Work?,” Organizational Behavior and Human Decision Processes, Vol. 109, 2009)
A team member managing five active work items and switching between them multiple times a day operates at a fraction of their effective capacity, even if the calendar looks full and the task list looks active.
The problem compounds at the team level. The more items in flight at once, the harder it is to coordinate. Dependencies between items multiply. Integration becomes more complex as code and work products diverge.
Communication overhead increases as more stakeholders need updates on more open threads. The standup gets longer. The board gets noisier. The sprint review has more half-finished items to explain. There is also a quality dimension.
User stories carried through testing quickly, with implementation context still fresh, are tested more thoroughly and fixed faster than stories reviewed weeks later. WIP limits that keep cycle times short from start to finish produce better-tested, more reliable output.
How “Stop Starting, Start Finishing” Applies in Kanban and Scrum
In Kanban
Kanban is where WIP limits were formalised as a practice.
David Anderson’s Kanban method makes explicit WIP limits at every stage of the workflow a core practice, not a recommendation. Each column on the Kanban board has a maximum number of items allowed at any given time. (Source: Anderson, D.J., “Kanban: Successful Evolutionary Change for Your Technology Business,” Blue Hole Press, 2010)
When a column reaches its limit, no new item can enter that stage until one exits it. This creates a pull system. Work is pulled forward when there is capacity to receive it, rather than pushed forward when someone decides to start it.
The visual signal is immediate. A column that has hit its WIP limit turns red in most Kanban tools, signalling that the team’s priority should be clearing that column, not starting something new. Without WIP limits, a Kanban board is, as one practitioner puts it, just a colorful to-do list. The visualization tells you where things are. The WIP limits tell you what to do about it.
In Scrum
Scrum practitioners often assume fixed-length sprints solve the WIP problem. They do not. They just frame it differently. A sprint with 40 story points of work pulled in and 25 story points delivered still has 15 points of incomplete work, partial implementation, and accumulated technical debt.
The sprint boundary does not make unfinished work disappear. It forces a decision about what to carry forward. The standup is where “stop starting, start finishing” is most easily applied in Scrum.
The default standup format, where each person reports what they worked on yesterday, what they are working on today, and what is blocking them, is individual-centric. It optimizes for individual visibility, not collective throughput. A more effective approach shifts the standup’s focus from people to user stories.
The team walks the board from right to left, starting with items closest to done, and asks what it would take to complete them today. If an item is stuck in code review, the question is not who is responsible for reviewing it but how the team can clear it right now.
This swarming behavior, where the team concentrates effort on finishing the nearest-to-complete items before pulling new work, is the practical application of the principle in a Scrum context. The primary measure of progress in Scrum, as reflected in the sprint burndown chart, is work completed, not work started.
A team that is 60 percent through its sprint and has completed 40 percent of committed stories has a problem. The standup and backlog refinement practices should be oriented toward resolving that problem, not toward creating more starts.
High-WIP vs Low-WIP Teams: What the Difference Looks Like
| Dimension | High-WIP Team | Low-WIP Team (WIP Limits Applied) |
| Board state | Many items in progress; hard to see what matters | Few active items; clear priority visible at a glance |
| Standup focus | Each person reports individual task status | Team walks the board; focuses on unblocking nearest-to-done items |
| Context switching | High; team members juggling 5 to 8 active items each | Low; individuals limited to 1 or 2 active items at a time |
| Sprint end pattern | Cluster of almost-done items carrying into next sprint | Most committed stories reach done; carries are rare and small |
| Collaboration | Each person owns their own tasks; limited swarming | Team swarms on blocked items; collective ownership of sprint success |
| Customer value | Delivered in large batches at end of release cycle | Delivered incrementally; small working increments reach customers faster |
| Code review quality | Reviews batched; context lost; integration complexity grows | Reviews happen quickly; implementation context is fresh; quality is higher |
How to Implement WIP Limits That Actually Work
The mechanics of WIP limits are simple. The practice is less so.
WIP limits surface problems the team would rather not see, and the immediate response is often to relax the limit rather than fix the underlying issue.
Start with Observation, Not Prescription
Before setting WIP limits, observe the current state.
Monitor how many items are actively in progress in each workflow stage over several sprints or weeks. Track cycle time, the time from when an item enters “in progress” to when it reaches “done.”
This baseline tells you where the WIP problem is concentrated. You learn which stages are bottlenecks and how much work-in-progress is already too much.
Set Limits That Feel Slightly Uncomfortable
WIP limits that are higher than the team’s current average WIP change nothing.
The limit needs to sit below the current average. Close enough to current practice that it is achievable, but tight enough that it forces the team to change behavior.
A team currently running eight items in parallel per developer might start with a limit of four or five, not two. The goal is progressive reduction, not immediate perfection.
Atlassian’s guidance is to set the maximum WIP limit slightly below the number of team members. That way, when everyone is working, there is still room for someone to finish a review or swarm on a blocked item rather than start something new. (Source: Atlassian, “WIP Limits: Why You Should Set WIP Limits in Kanban,” atlassian.com/agile/kanban/wip-limits)
Treat a Full Column as a Signal, Not a Problem
When a column hits its WIP limit, the correct response is to ask why, not to raise the limit. A blocked code review column means the team is not reviewing fast enough relative to the rate of development.
That is information about the team’s process. Maybe code review is under-resourced. Maybe items are too large to review in a single session. Maybe the definition of done does not include peer review as a prerequisite. The WIP limit surfaces the problem. The team’s job is to fix the process, not circumvent the limit.
Apply Limits at Multiple Levels
WIP limits can be applied at several levels:
Individual level: One person, two active items maximum.
Workflow stage level: The “in review” column, maximum three items.
Team level: The whole sprint, maximum 12 active items at any time.
The most impactful starting point is usually the workflow stage that creates the most visible bottlenecks. That is typically code review or testing, where items pile up because downstream capacity is smaller than upstream production rate.
Reinforce in the Stand-up
The stand-up is the daily mechanism for enforcing the principle. Walk the board from right to left. Ask what needs to happen to move each near-complete item to done before pulling anything new.
Make swarming an explicit expectation. A developer waiting for a design input should, by default, help someone else finish rather than start a new feature independently. The standup is where the team’s collective commitment to finishing over starting is either reinforced or eroded, one day at a time.
Common Objections to WIP Limits, and Honest Answers
| Objection | Why It Feels Valid | The Honest Answer | What to Do Instead |
| “People will be idle” | If no new work can start, team members sit unoccupied | Idle time means you have found a real bottleneck. That is information, not a failure | Use idle time to clear blocked items, improve documentation, or fix technical debt |
| “Emergencies override limits” | Urgent work arrives and WIP limits cannot hold | True. But most emergencies are habits of urgency, not genuine crises | Create an explicit emergency lane with its own WIP limit; protect the main flow |
| “Our work cannot be parallelized” | Some items genuinely cannot move forward without external input | Blocked items should be marked blocked and not counted against WIP | Define explicit blocked status on the board; swarm to unblock, do not start new work |
| “The limit is too restrictive” | WIP limits slow the team down; throughput drops | A drop in apparent starts does not mean a drop in throughput. Measure completions | Track cycle time and throughput over 4 to 6 weeks before judging the limit’s effect |
Beyond Software: Where Else “Stop Starting, Start Finishing” Applies
The principle is not limited to software development teams.
It applies wherever knowledge work is managed as a flow of tasks, which is most of modern professional work. Marketing teams running too many campaign workstreams see the same pattern: high apparent activity, slow delivery, quality that suffers from divided attention.
Data teams maintaining too many open pipeline projects accumulate technical debt and deliver nothing reliably. Product managers with too many open feature threads lose the context to make good decisions on any of them.
The mechanics are the same regardless of domain. Visualise the work. Set limits on how much can be active at any stage. Walk from right to left to prioritize finishing over starting. Treat a full column as a process problem to be solved, not a constraint to be bypassed.
The data teams and analytics organizations that Data Pilot works with consistently encounter this pattern. Projects proliferate. Pipelines go half-built. Dashboards get created but not maintained. Governance initiatives launch but never complete.
The antidote is the same as it is in software. Stop starting. Start finishing. Deliver one thing well before picking up the next.
Final Thoughts: Finishing Is a Team Decision
The “stop starting, start finishing” principle is culturally demanding because it runs against the instinct to show effort through activity. Starting a new task feels productive. Helping a colleague finish theirs, especially when it is not in your immediate skill set, feels like a detour. The teams that adopt WIP limits successfully are the ones that re-frame their definition of productivity. Productivity is not a task started. It is value delivered.
A sprint that completes eight out of ten committed stories has delivered more than a sprint that started twelve and completed five, even though the second sprint has higher apparent activity. The standup is where this re-framing happens, or does not. Walk the board right to left. Ask what the team needs to finish today, not what everyone is going to start. Make swarming on near-complete items an expectation, not an exception. Set WIP limits that force a choice between starting and finishing. Consistently choose finishing.
If your team’s data delivery is suffering from the same pattern of too many projects in flight and too little completed on time, Data Pilot’s delivery consulting helps data teams apply these principles to analytics, pipeline, and governance work.