How to Design a Kanban Workflow for a Software Team

A software team can have a Kanban board, daily standups, and a clear sprint plan—and still struggle to get features shipped.

One common reason is that the board tracks where tasks are, but doesn't explain how work should move between stages.

A developer finishes a feature, but it waits for code review. The review is complete, but testing hasn't started. Testing finds a bug, and the task moves backward. Meanwhile, new tickets keep entering the workflow.

The team isn't necessarily short on effort. Its workflow may simply be hiding where work gets stuck.

Here's a practical way to design a Kanban workflow that reflects how software actually gets delivered.

1. Start with the real path from idea to release

A basic board might use:

To Do → In Progress → Done

That's easy to understand, but it can hide important handoffs. For a software team, a more useful starting point could be:

Backlog → Ready → In Progress → Code Review → Testing → Done

Treat these as examples, not universal rules. If your team deploys continuously, has a separate QA team, or doesn't require formal review for every change, your workflow should reflect that.

The key question is: Where does work wait between being started and being delivered?

If code review is a frequent bottleneck, make it visible. If testing happens as part of development, a separate testing column may add unnecessary administration.

The board should describe the actual process, not an idealized one.

1. Define what it takes to enter each stage

Column names alone don't establish a workflow. Team members also need to know when a task is ready to move.

For example:

Ready

Requirements are clear enough to begin.
Dependencies are identified.
The task has an owner.

In Progress

Someone has started the implementation.
The current status is kept up to date.

Code Review

The change is available for review.
The reviewer knows what needs attention.

Testing

The change is ready for the agreed testing process.
Known limitations or relevant test instructions are documented.

Done

The team's definition of completion has been met.
Any required checks or approvals are complete.

These are sample policies. Adapt them to your team's engineering practices.

Without clear entry and exit criteria, one developer's "done" might mean code written, while another person's means tested and released.

That difference creates confusion even when everyone is updating the board.

1. Make waiting time visible

Suppose a feature takes two days to implement but spends another three days waiting for review.

Looking only at implementation time makes the process appear faster than it really is.

Track where work waits. Review queues, testing queues, external dependencies, and approval delays can all affect delivery.

You don't need to introduce a complex measurement system immediately. Start by identifying cards that have remained in the same stage longer than expected.

Ask:

Is the task actively being worked on?
Is it waiting for another person?
Is a dependency unresolved?
Does the task need to be smaller or clearer?

This helps distinguish slow execution from a workflow that creates unnecessary waiting.

For a related perspective, see How to Build a Kanban Workflow That Shows Delivery, Not Just Activity.

1. Use work-in-progress limits carefully

A team can have five developers and twenty tasks marked In Progress. That doesn't mean twenty tasks are moving forward.

Context switching, review queues, and unfinished dependencies can leave work scattered across the board.

Work-in-progress (WIP) limits help teams control how much work occupies a stage at one time.

For example, a team might decide that only a small number of tasks should be waiting for code review simultaneously. When that limit is reached, the team focuses on reviewing existing work before sending more tasks into the queue.

The right limit depends on team size, task complexity, and the workflow. Start with a reasonable boundary, observe what happens, and adjust it based on evidence.

A limit isn't a reason to stop helping teammates. It's a signal to investigate why work is accumulating.

1. Don't confuse moving cards with delivering software

A board can show plenty of movement while releases remain unpredictable.

To understand delivery, combine workflow visibility with a few useful measures:

Throughput: How many work items are completed in a given period?
Cycle time: How long does work take from the agreed start point to completion?
Work in progress: How much work is currently unfinished?
Blocked work: Which tasks cannot proceed, and what is preventing them?
Overdue work: Which commitments have passed their expected dates?

Use consistent definitions when comparing these measures over time. A change in how the team defines "Done," for example, can make historical comparisons misleading.

Avoid using these numbers to rank individual developers. They are more useful for understanding the workflow and identifying recurring problems.

You can also read What Should a Good Project Delivery Report Actually Tell You? for more on connecting project tracking with delivery visibility.

1. Review the workflow, not just the tickets

A short weekly review can reveal problems that individual task updates won't.

Look for patterns:

Does work regularly accumulate in one stage?
Are tasks frequently returned from testing?
Are reviews waiting on the same few people?
Are large tasks difficult to finish within a reasonable period?
Are priorities changing so often that started work gets abandoned?

Choose one recurring issue and test a small improvement.

For example, if code reviews regularly become a bottleneck, the team could agree on review expectations or reserve time for reviews during the day. If testing repeatedly reveals unclear requirements, improve the definition of readiness before development begins.

Then check whether the change helps.

A workflow should evolve as the team learns—not become a rigid process that nobody questions.

Final thoughts

A useful Kanban workflow doesn't need a dozen columns or a complicated set of rules.

It needs to show how work moves, make waiting visible, establish clear expectations for each stage, and help the team finish what it starts.

Begin with your actual delivery process. Make one bottleneck visible. Agree on one improvement. Review the result.

That is a practical way to make a Kanban board more than a collection of tickets—and make delivery easier to understand.

If you're comparing ways to manage this process, Otper is a Kanban project management tool with task ownership, due dates, a Gantt view, and reporting analytics.