Kanban for Software Projects: Make Work, Delays and Priorities Visible

Kanban helps a team make its work and flow visible. A board can show where each item is, what is blocked and where too much work is accumulating. Its usefulness comes from the working policies behind the columns, not from moving cards around a screen.

For a client, the board should make priorities and delays easier to discuss. It should not become a substitute for demonstrating software or explaining what the business can now do.

Map the actual workflow

Choose columns that reflect meaningful stages such as ready, development, review, testing and ready for release. Define what must be true before an item moves between them. If “done” sometimes means coded and sometimes means live, the board will mislead stakeholders.

Show blocked work with a reason and an owner for the next action. An item waiting for payment-provider access is different from one still being implemented. Keeping that distinction visible helps the business resolve dependencies.

Limit unfinished work

Starting many tasks can create the appearance of activity while delaying completion. Work-in-progress limits encourage the team to finish or unblock existing work before taking on more.

The limits should reflect the team's actual capacity and be reviewed with evidence. A bottleneck in testing is not solved simply by producing more development work. The team may need to help clear the queue or change how items reach it.

Make prioritisation explicit

Agree who orders incoming work and how urgent incidents are handled. A maintenance team may need a clear emergency path, but every ordinary feature request should not become an emergency merely because someone asks loudly.

Record tradeoffs when urgent work displaces planned delivery. This gives the client a realistic explanation of why a forecast changed rather than hiding the interruption inside a busy board.

Use flow information carefully

Review how long items take, where they wait and which types of work repeatedly become blocked. Use this information to improve the process and forecast similar work with appropriate uncertainty.

Do not compare individual productivity using card counts. Work items differ in complexity and value, and such comparisons can encourage people to split or avoid work to improve a number.

A practical example

Imagine a team maintaining a customer portal. It receives access issues, small improvements and integration failures. Separate the urgent incident process from ordinary enhancements, define acceptance criteria for each change and show items waiting on customer information.

This is an illustrative workflow, not a claim that a named Exceed IT project used Kanban. The useful outcome is that the team and client can see what will be completed next and what is preventing progress.

Connect the board to real delivery

Review completed behaviour with users and keep a clear release record. A card reaching the last column should correspond to the agreed definition of completion, including relevant verification and documentation.

Read our Agile client guide, user-story guide and maintenance planning article for the practices that make a visible workflow useful in operation.