What is Kanban Model in Software Engineering?

What is Kanban?

Kanban is a very popular framework for development in the agile software development methodology. It provides a transparent way of visualizing the tasks and work capacity of a team. It mainly uses physical and digital boards to allow the team members to visualize the current state of the project they are working on.

Kanban originated in Toyota in the 1940s. Kanban’s meaning in Japanese is “billboards.” The Kanban board has columns and story cards. The columns are nothing, but workflow states and cards are nothing but a demonstration of the actual task a team member is performing.

Those cards carried a just-in-time signal: a station requested parts only when it actually needed them, so nothing was built in advance. Kanban keeps that idea. It is a method laid over your existing process rather than a replacement for it, so it fits any software development life cycle model you already run.

When to use Kanban?

Kanban suits teams whose work arrives unpredictably and who need to release as soon as an item is ready. Here are the main reasons for using the Kanban method:

• Kanban can be used in any domain, and it can be used very effectively in software development. Kanban project management helps in improving the efficiency of the team.
• It is a pull-based system. Tasks are being pulled as soon as an individual is free.
• Kanban should be used when you want to release your work at any time. It requires git branching, but it is doable.
• Kanban should be used when you want to change the priorities on the fly. For that, all you need to do is to put this story on the top of the to-do queue.
• It should be used when you want to visualize your work, and you want to see the progress of your tasks visually.

Fit is one half of the decision; the payoff below is the other.

Benefits of Kanban Methodology

The strongest argument for Kanban is that it improves delivery without forcing a reorganisation. Nobody changes title and no sprint calendar is imposed, yet the board makes queues, blockers, and overloaded people visible on day one. A bottleneck everyone can see tends to get fixed.

Teams that run Kanban consistently report the following benefits:

• Shorter delivery times: WIP limits cut the time a card spends waiting, which is where most delay hides.
• Higher flexibility: An urgent item can go to the top of the to-do column at any moment, with no iteration to wait for.
• Better collaboration: When a column hits its limit, free members help clear it instead of starting something new.
• Employee empowerment: Individuals choose their next card and own its state, which removes approval bottlenecks.
• Predictable forecasting: Historical cycle time gives an evidence-based delivery estimate instead of a guess.
• Less waste: Nothing is started before the system has capacity to finish it.

These outcomes follow from four principles that govern every Kanban implementation.

The Four Principles of Kanban

Below are the main four core principles of Kanban:

1. Start with what you have now: Kanban system suggests working incrementally and start with what you have currently. Since one of its practice is to improve continuously, you must improve the system gradually.
2. Agree to Pursue Incremental, Evolutionary Change: Kanban recommends an incremental change in the process, and you must not make a big change in the process in one go.
3. Respect the Current Process, Roles & Responsibilities: Once again, start with what you have now and change the process, role, and responsibilities in an incremental manner.
4. Encourage Acts of Leadership at All Levels: Every individual can act as a leader and provide ideas to improve the efficiency of the overall Kanban system. You should not think that this is a management level activity, and even the youngest member of the team can act as a leader.

Principles describe the mindset. The six practices below describe the day-to-day behaviour that puts them into effect.

The Six Kanban Core Practices

Following are the main six core practices of Kanban:

1. Visualize the workflow: This principle suggests having a Kanban board (physical or digital) to visualize the workflow. Each individual of a team must see his card and cards of other team members. You can move your cards in different columns as per the board layout. It brings lots of transparency within the team and also makes it easier to resolve blockers.
2. Limit work in progress: Kanban is a pull-based system, and it improves the efficiency of a team to limit work in progress and have tasks that can be completed in the given time frame by the team. This WIP limit applies from the beginning to the end of the workflow. You can apply the limit on top of the column using a positive integer.
3. Focus on flow: This principle focuses on flow and on any interruptions. If there are interruptions or blockers, they must be fixed permanently.
4. Explicit Policies: Policies can be established in a team to reduce the rework and focus on the areas which require attention or where it is more effective.
5. Feedback Loop: Feedback loops are very essential in Kanban. It is not just within the team but between multiple teams, coaches, etc. This helps in improving the overall health of the Kanban system.
6. Continuous Improvement: This is the core principle of the Kanban system. It states that you can always improve the process, and that will result in better efficiency.

Practices need owners, which Kanban handles differently from other agile methodologies.

Kanban Roles and Responsibilities

Kanban prescribes no new job titles, and that is deliberate — the third principle asks you to respect the roles you already have. A developer stays a developer. In practice, though, two responsibilities emerge as a board matures, and mature implementations name them explicitly.

The Service Delivery Manager owns the flow of work through the board. This person watches for cards that have stopped moving, escalates blockers, keeps columns inside their WIP limits, and runs the review where the team inspects its own cycle-time data. The Service Request Manager owns what enters the board, representing the customers who raise requests, ordering the to-do column so the most valuable item sits on top, and making the selection policy explicit.

Both are responsibilities rather than extra headcount; one person often carries both. What matters is that somebody is answerable for flow and somebody for intake. The artifacts they manage come next.

Kanban Cards

The Kanban method recommends visualization of work. It suggests the use of the physical and the digital board, and the board below shows those columns with cards distributed across them.

The Kanban cards are essential pieces on the Kanban board as it represents the work that the team is working on. These cards will have

1. Priority
2. Owner
3. Type
4. Due date

A column in Kanban board represents the work stage, and you can place a WIP (Work in Progress) limit on the column. The WIP limit means the maximum number of cards that can stay on that column.

Since the Kanban method uses a pull-based system, as and when a developer is free, he/she can pull a card from the to-do column to the dev column. The board those cards live on deserves a closer look.

Kanban Board

Kanban Board is an agile project management tool that helps implement Kanban to manage projects for personal and business purposes. It is a physical or digital (JIRA) board designed to help teams visualize their work at different stages and processes. It also helps represent the stages of work with columns using cards.

It has columns that represent the status of the work like

1. To-do,
2. Dev
3. Testing
4. Done.

Each of these columns can have cards <=the WIP limit. The cards represent the actual work.

You can use positive numbers to limit work-in-progress, and this limit number can be placed on the top of the columns in both physical and digital Kanban boards. Any individual of the team can manage the state of his card, and the entire team can visualize the workflow. Digital boards such as JIRA add the same limits with automatic cycle-time tracking. Next, we will learn about the Kanban workflow those columns represent.

Kanban Workflow

Kanban Workflow is a set of steps that helps teams to define explicit policies and principles in Kanban. It represents the rules and procedures while the work is going on across various stages of development and delivery cycles. Kanban workflow consists of step-by-step processes between starting and the delivery of a particular task.

The basic principal Kanban follows is, “stop starting, start finishing”. With the help of WIP limits, it gets more work done. There are customizable Kanban workflows and states available in any modern tool like JIRA.

Below are the basic states that many software teams follow for their workflow management.

Notice that the “ready for” states are queues, not work. A card can sit in one indefinitely, so the rule that moves cards matters more than the states.

Pull Based System

Kanban is a pull-based method where tasks are being pulled rather being pushed. As soon as you have completed your current card, you can pull a new card from the previous column of the Kanban board.

With the WIP limit, Kanban helps in the improvement of Lead Time and Cycle Time. There should be the least possible gap between these two timings. For example, we have 5 developers and just 1 tester; what will happen in this case? There would always be many cards that require testing, and they will be sitting idle and waiting.

To overcome the issues mentioned above and improve efficiency, Kanban follows the pull-based approach with WIP limits, where there would be a limited number of cards to be pulled.

So, a tester will pull a task from the “ready for testing” stage when he has finished his current task in hand. With the WIP limit in Kanban columns (stages of development), you will not have many unattended cards in the Kanban workflow.

The pull-based system also helps in finding the correct velocity for the team. With the right velocity in place, the team will perform better. Everything here depends on one number: the WIP limit.

Limiting WIP(Work-in-progress)

In the Kanban method, WIP limits the number of tasks/cards which can be worked on by a team member or entire team at one time.

The WIP limits ensure that the team stabilizes their work and increases the predictive nature, which is essential in the pull-based system. Usually, the WIP limit decision is taken by the team itself.

Reason to set the WIP Limits

Here are reasons to set the WIP Limits:

• It shifts focus on getting things done as an individual focuses on a single task at a time.
• It helps teams to understand their capacity.
• It improves productivity lead and cycle time.
• It helps in avoiding the piling up tasks (in waiting mode).
• It improves the movement of the workflow so tasks keep moving.
• It also helps to resolve blockers as an individual does not switch between different tasks.

⚠️ Warning: A limit set too high is the same as no limit — cards queue and cycle time stretches. A limit set too low leaves people idle. Change one column’s limit at a time and watch cycle time for two weeks.

That is the last piece of theory; the section below turns it into actions.

How to Implement Kanban Step by Step

Kanban is easy to start: step one describes what you already do. Work through this sequence with the whole team present.

1. Map the current workflow. Walk one finished item backwards through every hand-off it passed. Each hand-off becomes a column, including the waiting states nobody officially owns.
2. Draw the board. One column per state, left to right, ending in Done. A whiteboard with sticky notes suffices for the first month.
3. Write the cards. Give every in-flight item a card carrying priority, owner, type, and due date, then place it in the column matching its real state.
4. Define “done” for each column. Write the exit criteria on the board. This explicit-policies practice is what stops cards bouncing backwards.
5. Set initial WIP limits. Pick a starting number for every column except To-do and Done using a method below, then write it above the heading.
6. Agree the pull rule. Nobody starts a new card while their column sits at its limit; they help clear the column to their right instead.
7. Walk the board daily. Move right to left, oldest card first, asking what blocks this card and who can unblock it today.
8. Measure, then tighten. After two weeks, cycle-time data shows which column holds cards longest. Lower that limit or add capacity, then repeat.

Step five is where most teams stall, so here are the three sizing methods practitioners use:

Treat the first number as a hypothesis. Pairing the board with formal agile testing keeps the testing column from becoming the bottleneck, and the two timings below show whether it works.

Lead Time and Cycle Time

In the Kanban method, lead time and cycle time are widely used, there is a difference between the two, and it is important to understand that to avoid the confusion.

Here it is also important to understand not to include the time it takes between ready for release and actual release.

Cycle Time = Work in Progress/Throughput

💡 Tip: Lead time is what the customer experiences; cycle time is what the team controls. A wide gap means work waits in a queue before anyone starts it, so fix intake before speeding up the team.

In the ideal scenario, the gap between lead time and cycle time should be minimal, and Kanban uses a cumulative flow diagram (CFD) to measure lead and cycle time historical data. That diagram is the subject of the next section.

Cumulative Flow Diagram (CFD)

CFD is a chart which is available in all leading workflow management tools like JIRA. This chart measures the total amount of work cards/tasks that entered the workflow and amassed completed cards/tasks over time.

It helps you to have an estimate of average lead time and cycle time for prespecified time.

CFD diagram will give you indicators or problem areas to fix. It will provide you with a clear picture, and based on this diagram. You can correct your team’s lead time and cycle time. The cumulative flow diagram below plots each state as a coloured band; a band that keeps widening is the bottleneck.

The chart is read through four quantities:

1. Lead Time: It is the duration between a new card’s arrival in your workflow and its final departure from the workflow.
2. Cycle Time: It is a duration between the card’s arrival in the working state and when the card is ready for release.
3. WIP: Work in progress (WIP) limits the maximum amount of work items in the different stages of the workflow.
4. Throughput: It is the actual performance, and it tells the actual number of cards delivered in a given timeframe.

Throughput = WIP/Cycle Time

That covers artifacts, mechanics, and metrics. The remaining question is how Kanban compares with Scrum.

Scrum Vs. Kanban

Here are the important differences between Scrum Vs. Kanban. For the wider picture, see Agile Vs. Scrum.

FAQs