Flow of work

Introduction#

The path a team’s work items take from idea to production is sometimes called the team’s workflow or Software Development Life Cycle (SDLC). Each item passes through a set of stages, each with exit criteria that must be met before an item moves on. A good workflow helps the team deliver quickly and reliably.

Agile SDLC vs Waterfall SDLC

An agile SDLC defines stages through which each work item must pass. In contrast, a traditional waterfall SDLC defines stages through which the entire project must pass. While the stages may appear similar, the result is very different.

Most pages in this handbook recommend one good default and explain why. This page is different, because there is no single good workflow. The right choice depends on things that vary between organisations: who is available when, where work has to pass between people or teams, how releases happen, and how stable priorities are. A workflow that suits a team with an embedded Product Manager and Continuous Deployment would be wrong for a team with a part-time Product Manager, a separate test function, and monthly releases.

So rather than prescribing a workflow, this page offers a deliberately minimal starting point and the vocabulary to talk about it, then works through the situations that most often push teams to change it, with good ways to respond to each. It finishes with how to make work in progress (WIP) limits actually work, and how to evolve the workflow over time.

Principles#

When designing a workflow, keep these principles in mind:

The board should reflect reality. If work passes from one person or group to another, the board should show it. A board that shows the process you would like rather than the one you have hides problems and makes it harder to fix them.
Keep it as simple as possible. Add stages to solve specific problems you have now, not for some theoretical benefit.
Every stage needs a definition of done. If you cannot say what it takes for an item to leave a stage, the stage isn’t well defined, and items will drift through it inconsistently.
Done means deployed. Nothing has any value until it is in production. An item that is merged but not deployed is still in progress.
The team owns the process. The workflow should be changed by the team, usually in response to a problem identified in a retrospective. Leaders who support teams may provide guidance, but the process should not be handed down to the team without discussion.

A starting point#

The team defines stages for specific activities. A good minimal workflow has just four:

Backlog

Elaboration

Implementation

Deployed

Backlog: an ordered list of items, each described at a high level: what is needed, for whom, and why.
Elaboration: where items are enriched and refined to get them ready for implementation.
Implementation: where the item is built, tested, reviewed, and accepted.
Deployed: the item is in production and there is nothing left to do.

This is a good conceptual model to start with. It builds on the simplest possible workflow (“To do / Doing / Done”) by adding the Elaboration stage. Realistically, all backlogs contain some items which are half-formed ideas rather than something that an engineer could start work on. The Elaboration stage is where the acceptance criteria are defined and the questions about what exactly will be implemented and how are answered.

Terminology: elaboration vs refinement

Some teams use the term refinement instead of elaboration but both mean the same thing: enriching a work item so it’s clear exactly what the aim is, roughly how it will be done, and how it will be validated. This page uses elaboration throughout as it more accurately describes the process of adding information and detail.

Don’t skip elaboration

Teams who skip the elaboration step often run into problems.

They get half-way through implementing an item before realising they aren’t clear exactly what they’re trying to achieve.
Or they implement something only to find that a tester or Product Manager had a different idea of what the aim was.
Or the item turns out to be far bigger than realised and should have been split.

We’ll discuss various competing factors that may require additional stages to be added in later sections.

Iterations or continuous flow?#

Teams typically work in either iterations or continuous flow. Both approaches are good choices in different circumstances.

Iterations: the team works in fixed timeboxes, typically two weeks, which Scrum calls “Sprints.” At the start of each iteration, the team plans what it aims to achieve and selects the top elaborated items. Items are selected up to the team’s expected capacity, based on their story point estimates.
Continuous flow: there is no fixed timebox. Team members pull items each time they have capacity to start something new, working item by item, rather than in batches. This process is sometimes called Kanban, though strictly speaking that term only describes part of the process.

When working in a continuous flow style, it’s good practice to maintain a regular pattern of running events such as planning, retrospectives, and demos every two weeks. A regular cadence ensures the team gives attention to these important events and prevents them from slipping. These events work just as well whether work flows continuously or in batches.

Many organisations default to a process based on Scrum with two-week iterations. But it’s worth pausing to consider what the best fit is for your specific circumstances.

Iterations	Continuous flow
Can give more predictability over short time periods, provided the team has established a predictable capacity.	Less clear what the team expects to deliver over the next two weeks.
Can protect the team from continuously changing priorities by providing stability during each iteration. Pivoting mid-iteration when necessary is more disruptive.	Works well if priorities frequently change with good reason.
Many teams find forecasting several weeks or months ahead easier with the iteration construct in place.	Although forecasting is equally possible, teams are less used to using the relevant metrics and tooling is less geared towards doing this.
A ready-made structure can help a team adopt more disciplined ways of working.	Little imposed structure, so creates less friction for teams already working in a disciplined agile way.
Introduces terms and concepts that force immediate changes to ways of working.	For a team used to low process discipline, allows discipline to be built up one change at a time, rather than big-bang.
Without required discipline, iterations create overhead without benefit, with work drifting from iteration to iteration.	Minimal structure creates less process overhead.

What an iteration fixes#

Some teams treat the exact work items selected for an iteration as the definition of that iteration. Historically, this was what Scrum advocated, calling it the sprint “commitment,” but the Scrum Guide now tells us instead to fix the sprint goal and allows flexibility on what work is needed to deliver that goal. However, the guidance is vague:

Scrum Guide: The Sprint

During the Sprint: No changes are made that would endanger the Sprint Goal; … Scope may be clarified and renegotiated with the Product Owner as more is learned.

In practice, many teams struggle to form a single sprint goal, and resort to either skipping setting any goal, or simply listing the contents of the sprint, which isn’t useful. Where a single goal can’t be found to capture the essence of the sprint, it’s OK to choose a main goal and one or two secondary goals. This is a lot better than no goal in helping the team clarify priorities within the sprint and acts as a guide on what to work on first if things don’t go to plan.

Treating the exact set of items selected for the sprint as fixed, no matter what, hampers the team’s ability to respond to change. But the scope should only change with proper consideration. Before adding or removing items, ask:

“If we take on this extra item, what do we need to remove to make space for it?” Just adding work to the pile won’t magically create more capacity. Having more work planned for a sprint than you realistically expect to be able to deliver simply dilutes priorities and loses focus on delivering the most important thing right now.
“Before we remove this item, have we done everything we can to make it deliverable in this sprint?” Teams that freely punt items forward sprint after sprint find it hard to predict what will be done when.

When to elaborate?#

Every workflow has work in three high-level states:

To do: items that are waiting to be worked on.
Doing: items that are being actively worked on.
Done: items for which no more work is needed.

Elaboration can either be done up-front or just-in-time, and whether elaboration is considered part of preparing work or doing work depends on when it is carried out.

Up-front elaboration	Just-in-time elaboration
Elaboration is considered part of preparing work, not part of doing it.	Elaboration is considered part of doing work.
A buffer of fully elaborated and estimated items is maintained in a new Ready for Implementation state. Teams who use iterations generally work this way, because items need to be elaborated and estimated before they can be planned into an iteration. Some teams who use continuous flow also benefit from doing this if they don’t always have easy access to product and design input. The person leading the elaboration may be different from the person who later implements the item.	Elaboration is done item by item as they are pulled into flow. There is no need for a Ready for Implementation stage because the person leading the elaboration will start implementation as soon as the item is ready.
To do Backlog Elaboration Ready for Implementation Doing Implementation Done Deployed	To do Backlog Doing Elaboration Implementation Done Deployed

Where it is practical, just-in-time elaboration has real advantages. Items are enriched when the most is known about them, no effort is spent enriching items that are later deprioritised, and the person who elaborates an item carries that understanding straight into implementing it. But it depends on the people elaboration needs, particularly the Product Manager, being available at short notice. Where they aren’t, or where the team works in iterations, a buffer of elaborated items keeps work flowing. Keep the buffer small, with a WIP limit of around one iteration’s worth or what the team gets through between elaboration sessions, so it doesn’t drift back into detailed design weeks ahead of implementation.

Work stages and wait stages#

Most stages are work stages: someone actively does something to items in these stages. Elaboration and Implementation are work stages.

Some are wait stages: holding areas for items that have finished one stage and are waiting to be pulled into the next. Nothing is done to items in a wait stage. Ready for Implementation is a wait stage.

Wait stages are useful for two different reasons:

As a deliberate buffer, such as a small stock of elaborated items kept ready for when the team has capacity. The Ready for Implementation stage is a good example of this.
To expose waiting, typically at a hand-off, so that the time items spend waiting can be seen, measured, and reduced. A wait stage added to expose waiting is a symptom made visible, not a solution. It is worth having because it shines a light on a problem, and the aim should usually be to remove the waiting. For example, if your team has to wait for an external test team to test your work items, introduce a Ready for test stage to represent this reality. You may not like this hand-off, but pretending it doesn’t exist doesn’t make it go away, and admitting it does makes it visible and its cost measurable.

Separate test stage?#

Backlog

Elaboration

Implementation

Testing

Deployed

Is testing done by a separate team?

The simple model presented in A starting point works well if testers are fully embedded in the product development team. In this case, work items are tested as part of implementation, and testing is treated as an intrinsic part of telling if the item meets the acceptance criteria, and so is “done.”

But if the current reality is that work is passed from a development team to a test team, then this should be represented in the workflow. Otherwise, it will be difficult to have visibility of where work really is and measure the impact of this hand-off. (See Principle 1.)

Don’t create unnecessary divides

If testing is handled within the team, don’t introduce an unnecessary split between development and testing: do both in a single Implementation stage. This encourages shared responsibility for quality, engineers writing more of the tests, developers and testers pairing, and short cycles of building and testing throughout each item. Issues are found earlier, when they are cheaper to fix, testing stops being a bottleneck, and the team thinks about the user experience and business value rather than just whether the code matches the specification.

Separate user acceptance testing stage?#

Backlog

Elaboration

Implementation

UAT

Deployed

Do expert users need to verify changes?

In many cases, acceptance of work items is handled by the Product Manager as part of the definition of done. But in some situations, a separate user acceptance testing (UAT) stage is beneficial. For example:

Internal products whose users are part of your organisation.
Business to business (B2B) products with key strategic clients.

In each of these cases, it can be valuable to have expert users who work closely with product teams to inform priorities, input into designs, and validate whether the built features meet user needs. A dedicated acceptance stage is valuable here to discover anything missed in earlier stages before it impacts users. This testing also helps these expert users act as advocates for communicating any required changes to ways of working through their teams.

Another situation where a separate acceptance stage is sometimes introduced is to meet regulatory or compliance needs. This is usually not the best way to handle this, leading to unnecessary delays. In most cases, such needs are validated against the intended behaviour of a feature rather than by duplicating the testing that the product team has done to validate that intended behaviour has been correctly implemented. This is a good candidate to shift left, so that the regulatory or compliance assessment is done against the acceptance criteria before implementation begins. This is often less disruptive to the flow of work.

Addressing common challenges#

Work is handed off#

SYMPTOMS

Items pass to people outside the team before they can proceed, such as a code review by a senior engineer, a security review, a release approval, or a platform team that provisions infrastructure. Items sit waiting while the team starts something else, increasing the work in progress.

Backlog

Elaboration

Implementation

Approval

Approved for deployment

Deployed

APPROACH

Start by making the hand-offs visible. Add a stage for the work the other group does, and a wait stage for items it has finished with, so that the board reflects what really happens and the time items spend waiting on others can be measured. The other group’s stage is often a black box to the team, which can’t tell whether an item is queued or being worked on, so treat all the time spent there as waiting on others. The wait stage after it holds items that have come back but that the team hasn’t yet picked up. Where the other group pulls from a queue the team can see, a wait stage before their stage, such as Ready for test, makes that waiting visible too.

Over time, work on reducing or removing the hand-offs, because they are expensive. The diagram shows an example with a separate approval stage and a wait stage for items that have been approved.

Hand-offs cost more than they appear to:

Waiting. Time spent in queues usually dwarfs the time spent on the work itself. An hour of review can easily cost two days of elapsed time.
Lost context. Knowledge does not fully transfer between people. Questions bounce back and forth, and tacit understanding is lost.
Diluted ownership. When someone else is responsible for the next step, it is easy to throw work over the wall and treat quality as their problem.
Batching. People receiving work from several sources batch it up to use their time efficiently, so items wait longer and changes grow larger.
Late rework. Problems found downstream reach the original author after they have moved on, forcing a costly context switch back.
Someone else’s priorities. A group serving several teams will work to its own order, not yours.

There are several good ways to reduce hand-offs:

Own all of the testing. The team takes responsibility for all of its testing, including load, performance, and security testing, mostly automated and run in the pipeline. Specialist testers are members of the team rather than a separate function. See Testing.
Become more full stack. The team takes on at least some of the platform and infrastructure work its software depends on, using infrastructure as code and self-service tooling, and runs what it builds. A platform team can still provide a well-supported paved road, but the team should not need to raise a ticket and wait for routine changes.
Keep code review within the team. Peer review by team members, or pairing and ensemble working as a form of continuous review. Where an architect or other authority needs oversight, agree standards with them, involve them in design up front, and review a sample of changes asynchronously, rather than gating every item.
Embed design review. The designer reviews the built result as part of Implementation, rather than in a separate stage.
Replace approval stages with continuous compliance. Many approval gates exist to provide assurance that controls were followed. Most of those controls can be automated in the pipeline instead: mandatory peer review enforced by branch policies, automated tests, static analysis, dependency and security scanning. The pipeline then produces the evidence as a by-product, with a traceable link from each change to its work item, review, test results, and deployment. An approver who can see that evidence can usually agree to treat routine changes as pre-approved, reserving manual approval for the genuinely unusual.

The aim is to collapse the workflow back towards the starting point, with a single Implementation stage owned by the team.

Some hand-offs can’t be removed without first investing in meeting the needs they serve in other ways. Examples include a regulatory requirement for independent review, or a dependency on a genuinely separate team. Start by keeping the wait stage and giving it a WIP limit. Measure the time spent in it and work with the other group to reduce it or remove the hand-off entirely, often by shifting left and building it into what happens in implementation.

Work queues in a wait stage#

SYMPTOMS

Items pile up in a wait stage, or in a work stage where most of them are not actively being worked on. The daily meeting keeps finding the same column full.

APPROACH

A queue identifies a bottleneck where capacity can’t keep up with demand. Pushing more work in upstream only makes the queue longer and the wait for every item in it worse.

Introduce a WIP limit that caps the number of items allowed in the wait stage. When the queue builds up, the team rallies around doing what is needed to reduce the queue. They stop starting new work and instead help clear the bottleneck, such as by reviewing or testing items. If this is a recurring problem, look at why demand is higher than capacity and explore ways to reduce demand or increase capacity.

Work takes too long to cross the board#

SYMPTOMS

Items take weeks to get from start to production, cycle time is rising, or items regularly sit in progress for much longer than their size suggests.

Two metrics describe how quickly work flows:

Cycle time is the time an item spends in Doing, from when work on it starts to when it is deployed. It is a good measure of the team’s delivery effectiveness.
Lead time is the time from an item entering the backlog to being deployed, sometimes described as “from idea to production.” It is what stakeholders experience.

Short and predictable cycle and lead times mean the team can respond quickly to changing priorities, which is one of the most valuable indicators of agility. Most delivery tools can chart these over time. It is also worth watching work item age: how long each item currently in progress has been there. An item that is already older than most items take to finish needs attention now, rather than showing up in the cycle time figures once it is too late to help.

APPROACH

The main ways to reduce cycle time are:

Make items smaller. Small items flow faster and get stuck less. Aim for vertical slices of 5 story points or less.
Limit work in progress. For a given throughput, average cycle time rises in direct proportion to the amount of work in progress (this is Little’s Law). Fewer items in flight means each one finishes sooner. See WIP limits in practice.
Remove hand-offs. Where items have to wait at a hand-off, this often dominates cycle time. See Work is handed off.
Finish before starting. Walk the board right to left in the daily meeting, and have people with capacity help finish existing items before pulling new ones.
Pair or swarm. Two or more people on one item finish it sooner, and spread knowledge as they do.
Understand the work before starting. Agree acceptance criteria and split unknowns out into spikes to stop items stalling part way through.
Automate the path to production. Automated tests and deployment remove manual steps and the waiting that comes with them.
Deploy more often. See Releases are batched or scheduled.

Tip

Watch out for using cycle time to judge individuals, or turning it into a target. People will meet the target, whether by splitting items in ways that deliver no value or moving cards before the work is really done, and the metric will stop telling you anything. Use it as a team-level trend that highlights where to look.

Excessive context switching#

SYMPTOMS

One person’s name is on several cards. There are more items in progress than people. People say they started something new because they were waiting on something else. Interruptions are frequent.

Every switch between tasks costs time and focus, and an item worked on in fragments takes longer to finish and is more likely to contain mistakes.

APPROACH

Limit WIP across the board. Keep the total number of items in progress below the number of people in the team. This forces people to work together on items rather than each working individually.
Limit WIP per person. One active item each, or two at most if one is blocked.
Pair or swarm. When someone has capacity, the first question is what they can help finish, not what they can start. See Who needs help, who can help.
Reduce the waiting that drives switching. People mostly start new work because their current item is waiting for something. Removing hand-offs and chasing blockers addresses the cause.
Protect the team from interruptions. See Urgent work keeps interrupting.

Items get blocked#

SYMPTOMS

Items can’t proceed until something else happens, such as a decision, a dependency on another item, or something from outside the team.

Part of the purpose of elaboration is to find the unknowns that would cause an item to stall, but impediments still happen.

APPROACH

Indicate blocked items with a flag, tag, or similar, not with a separate Blocked column. A blocked column loses information about which stage the item was in, and makes it easy to park items out of sight.

Blocked items still count against WIP limits. This keeps the pressure on to resolve them, rather than freeing up space to start something new.
Every blocker has someone chasing it. The flag should say what the item is waiting for, and the daily meeting should check that someone is actively working to unblock it.
Recurring blockers are a process problem. If items keep getting blocked on the same thing, take it to the retrospective. It usually points to a dependency that needs managing differently, or a hand-off that could be removed.

Items keep moving backwards#

SYMPTOMS

Items are sent back from review, testing, or acceptance, sometimes more than once.

Each trip backwards means rework, a context switch for the people involved, and an item staying in progress for longer. It usually means the team’s understanding of the item wasn’t shared before work started, or that feedback came too late.

APPROACH

Agree acceptance criteria before starting. The Product Manager, tester, and developers should agree what “working” means before implementation begins. See Acceptance criteria.
Get feedback early. Show the Product Manager work in progress. Involve reviewers early, by pairing or by sharing a draft pull request, rather than presenting them with a finished change.
Keep items small. There is less to get wrong, and less to redo when something is wrong.
Separate fundamental problems from improvements. Send an item back only if it doesn’t meet its acceptance criteria. Capture enhancements as new backlog items.
Look for patterns. If items keep bouncing for the same kind of reason, discuss it in the retrospective and fix the earlier stage that should have caught it.

Releases are batched or scheduled#

SYMPTOMS

Items are finished but wait days or weeks for the next release, because production deployments are manual, happen in scheduled windows, or need a change board’s or other external approval.

APPROACH

Add a Ready to deploy wait stage for items that are finished and waiting for the next production deployment, so that the board doesn’t claim they are done when they aren’t.

Backlog

Elaboration

Implementation

Ready to deploy

Deployed

Then work on making the wait shorter:

Automate deployment. A deployment that is a single, reliable, automated step is cheap enough to do often. Build each change once and promote the same artefact through every environment.
Deploy more often. Smaller, more frequent releases are lower risk than large, infrequent ones, because each contains less that can go wrong and any problems are easier to find and fix.
Decouple deployment from release. Feature flags let changes be deployed to production without being visible to users, so a feature can be released when it is ready rather than when the deployment schedule allows. Deployed then means the code is in production, whether or not the feature is switched on, and this can happen continuously. Items only get Released (by enabling their feature flag) when approved, but this is separate from the delivery process and does not hold it up.
Replace change board approval with continuous compliance. See Work is handed off. Many change processes allow routine, low-risk changes to be treated as pre-approved standard changes, once the controls around them are automated and evidenced.

Tip

Teams practising Continuous Deployment deploy every merged change to production automatically, so items go straight from Implementation to Deployed. Many teams instead practise Continuous Delivery: changes are deployed automatically to test environments, but production deployment is triggered manually.

Priorities keep changing#

SYMPTOMS

Items are abandoned part way through. The top of the backlog is reordered daily. New work keeps being pushed into the current iteration. The team feels it never finishes anything.

APPROACH

Start by asking whether this is due to genuine change or unnecessary churn.

Genuine change comes from new information that matters: what users did with the last release, a shift in the market, a new opportunity. A team early in delivering a new product or major feature will see a lot of this, and responding fast is the point. Mature products see less of it, but rarely none.
Unnecessary churn comes from stakeholders reacting to the latest request by default, several people setting priorities, or the absence of a clear strategy. The changes are real to the people making them, but the team gains little by responding immediately.

For unnecessary churn, favour iterations, and agree that new requests wait for the next planning session unless they meet the criteria for urgent work. That session is never more than a couple of weeks away, and the requester has to make the case for their item against everything else in the queue. That conversation alone often filters out the noise. The team can still adjust its own plan as it learns, while being protected from new work being pushed in from outside.

For genuine change, favour continuous flow. There is no fixed commitment, and the next item pulled is simply whatever is at the top of the backlog at that moment. Elaborate just in time, or keep any Ready for Implementation buffer short, so that reordering wastes little.

Whichever you choose, small items and low WIP are what make changing direction cheaper. When items take a couple of days, the team can almost always finish what it has started and then pick up the new priority. Abandoning work part way through wastes everything invested in it, so reserve that for the genuinely urgent, and use the expedite route described next.

Urgent work keeps interrupting#

SYMPTOMS

Production incidents, support requests, and urgent asks from senior stakeholders arrive regularly. They are often handled without being represented on the board, quietly eating capacity while the planned work slows down for no visible reason.

APPROACH

Put it on the board. Urgent work is still work, and the daily meeting can only manage what it can see.
Give it an expedite lane. A separate swimlane, with a WIP limit of one, for work that may jump the queue and take priority over everything else. The limit of one stops everything from becoming urgent.
Agree what qualifies. A serious production incident clearly does, while a stakeholder wanting their feature sooner usually doesn’t. Agree the criteria with the Product Manager so the team isn’t arguing case by case.
Track how much capacity it takes. If urgent work is rare, the expedite lane is all you need. If it is frequent or growing, raise it in the retrospective. Look at the causes, such as quality problems generating incidents or missing self-service generating support requests, and consider a support rota, where one or two people absorb interruptions in turn so the rest of the team can focus.

Different kinds of work need different routes#

SYMPTOMS

Items that aren’t user stories don’t fit the workflow, and the team either forces them through stages that make no sense for them or keeps them on a separate board.

There are four main types of work item:

User story: new or changed behaviour that delivers value to users.
Bug: behaviour that doesn’t match what was intended.
Enabler: a purely internal change, such as refactoring too large to fit inside a user story, upgrading components to fix security vulnerabilities, or an improvement action agreed in a retrospective.
Spike: exploratory work to find out how best to do something, or whether it is possible at all.

In a product delivery team, most items should be user stories or bugs. Enablers and spikes do contribute to user value, but the connection is too distant to write them as proper user stories. Instead, describe enablers in terms of the risk they reduce or the opportunity they enable, terms borrowed from the Weighted Shortest Job First (WSJF) prioritisation technique, and spikes in terms of the question they need to answer.

APPROACH

Not every item needs every stage. A spike ends with findings rather than a deployment, with its size used as a timebox. An enabler may not need the Product Manager’s acceptance. Prefer one board, with stages that certain item types skip by explicit agreement, recorded alongside the Definition of Done. Separate boards split the team’s visibility of its work, and make WIP limits meaningless.

WIP limits in practice#

Limiting work in progress (WIP) is the single most effective way to improve the flow of work. It shortens cycle time, exposes bottlenecks, and forces impediments to be dealt with rather than worked around. It is also one of the practices teams most often adopt in name only. Delivery tools such as Jira can enforce limits, or at least warn when a stage reaches its limit, but the tool is the easy part.

Setting limits#

Start lower than feels comfortable. A useful starting point is a total WIP across Doing below the number of people in the team, with individual stage limits that add up to roughly that. Then adjust based on what happens. A limit that never bites does nothing.
Limit waiting as well as working. Wait stages need limits too, or a combined limit across a work stage and the wait stage that follows it. Otherwise items simply pile up in wait stages, and WIP looks under control while lead time grows.
Count blocked items. A blocked item still occupies a slot. This is what makes unblocking it urgent.
Agree what happens when a limit is reached. Usually this would be an agreement that nobody starts anything new, and anyone with capacity helps downstream by reviewing, testing, pairing, or chasing blockers. A limit being reached is a signal to swarm, not a failure.
Apply them every day. The daily meeting is where WIP limits are enforced, by walking the board right to left and asking what can be finished before anything is started.
Review them in the retrospective. Treat the limits as an experiment, and change them based on what you learn.

How WIP limits fail#

Failure	Better
Limits set so high they are never reached.	Set limits from where the team is now, minus a little, and tighten them over time.
Limits routinely exceeded “just this once.”	If a limit is regularly broken, either it is wrong or a problem is being dodged. Discuss which in the retrospective.
Limits gamed with extra parking columns, a Blocked column, or by moving cards backwards to free a slot.	Keep the board truthful. If items need somewhere to wait, that is a wait stage, and it needs a limit too.
Only work stages limited, so queues grow in the wait stages between them.	Limit wait stages too, or limit each work stage together with the wait stage after it.
Limits imposed by a lead, or configured in the tool without the team understanding why.	The team sets its own limits, understands what they are for, and agrees what to do when one is reached.
Reaching a limit treated as a failure to hide.	Reaching a limit is the system working. It shows exactly where help is needed.

Making them work#

Attributed to Don Reinertsen

Watch the baton, not the runners.

WIP limits feel uncomfortable at first, because they sometimes leave people without an obvious item of their own to work on. That discomfort is the point. A team where everyone is always busy on their own item is usually a team with a lot of work in progress and long cycle times. The goal is to keep the work moving, not to keep the people busy. Once a team sees items finishing faster, and fewer of them going stale, limits tend to stick.

Evolving your workflow#

If your current workflow isn’t what you want, make the change deliberately:

Write down the current process as it really is. If your workflow isn’t how you would like it, start by recording what actually happens, hand-offs and all. This gives you a concrete, honest starting point to iterate from.
Pick the problem that hurts most. Use the situations on this page to find it, ideally starting from something the team has raised in a retrospective.
Change one thing at a time. The team can absorb it, and everyone can see what made the difference.
Treat each change as an experiment. Review it in the retrospective, and keep it, adapt it, or drop it based on how it worked in practice.
Write down the exit criteria for each stage. See the Definition of Done. Unwritten criteria drift.
Don’t blindly copy another team’s workflow. It was shaped by their constraints, not yours.

Culture

Process matters, but culture matters more. A team where people feel safe raising concerns will find and fix process problems on its own. A team where they don’t will hide them, however good its workflow looks on paper.

Key points#

There is no single right workflow. Start with a minimal one and add stages only to address problems you actually have.
The board should reflect what really happens, including hand-offs and waiting.
Wait stages are useful as deliberate buffers, or to expose waiting so it can be reduced.
Elaborate just in time when the people you need are available, and a little earlier, with a small limited buffer, when they aren’t.
Hand-offs are expensive. Make them visible, then reduce them: own all testing, become more full stack, keep review within the team, and automate compliance.
Acceptance is usually an exit criterion of implementation, not a separate stage. A separate acceptance stage can earn its place where expert users validate changes, but compliance checks are usually better shifted left, against the acceptance criteria.
Queues show bottlenecks, and WIP limits are how you deal with them.
Reduce cycle time with smaller items, lower WIP, fewer hand-offs, and an automated path to production.
Flag blocked items rather than moving them to a column, and keep them counting against WIP.
Choose iterations with a firm boundary for new demand to shield the team from unnecessary churn, and continuous flow to respond to genuine change.
Treat what is selected for an iteration as a forecast, not a promise.
Give urgent work a visible expedite lane with a limit of one, and track how much capacity it takes.
Set WIP limits lower than feels comfortable, limit wait stages too, and agree what happens when a limit is reached.
Evolve the workflow one change at a time, through the retrospective.

Mistakes to avoid

Overcomplicating the workflow. Every extra stage is another place for work to wait. Keep it as simple as your situation allows.
Showing the process you want rather than the one you have. A board that hides hand-offs hides the problems you most need to fix.
Adding stages to accommodate waste. A wait stage should make waiting visible so it can be reduced, not make it a permanent fixture.
Splitting development and testing. It creates a hand-off, a bottleneck, and a “throw it over the wall” culture.
Using a Blocked column. Flag blocked items in place, and keep them counting against WIP.
WIP limits that never bite. A limit that is never reached, or always overridden, is decoration.
Treating the Product Manager’s acceptance as a formal gate. Involve them throughout, so that acceptance confirms what they have already seen.
Treating an iteration’s forecast as a promise. It leads to padded estimates, cut corners, and a team that stops responding to what it learns.
Copying another team’s workflow. Shape yours to your own constraints.
Treating the workflow as fixed. Review it regularly and change it when it stops serving the team.