How the kanban methodology applies to software development

Browse topics
Jira board

Get started for free with Jira’s kanban template

Maximize efficiency by seeing and moving forward the work that matters most.

Use template

What is kanban?

Kanban is a popular framework used to implement Agile and DevOps software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.

Kanban articles


Optimizing software development with Kanban flow

Kanban flow, a cornerstone of agile and DevOps methodologies, drives efficiency by orchestrating seamless task progression through visualized workflows. Kanban flow mirrors the streamlined inventory management of supermarkets, ensuring tasks move through development processes precisely when needed.

Visualized on Kanban boards, tasks represented as cards enable transparent progress tracking and swift identification of bottlenecks. By limiting work-in-progress (WIP), teams optimize resource allocation and maintain a steady workflow. Kanban's focus on continuous improvement is facilitated by metrics like control charts and cumulative flow diagrams, empowering teams to refine workflows iteratively.

In software development, kanban flow fosters dynamic task management, accelerates delivery cycles, and enhances customer satisfaction through focused, uninterrupted work. In essence, kanban flow epitomizes efficiency—a harmonious blend of transparency, adaptability, and continuous improvement—unlocking the full potential of agile methodologies.

Structuring your Kanban flow

Establishing a structured kanban flow within your software development team is essential to implementing kanban effectively. This ensures smooth task progression and optimized workflow management. Here's how you can structure your kanban flow:

Visualize workflow: Begin by visualizing your team's workflow on a Kanban board. Whether physical or virtual, the board should depict each stage of the development process, from task inception to completion.

Standardize workflow: Define and standardize the workflow stages according to your team's processes and requirements. Common stages include "To Do," "In Progress," and "Done," but customize as needed to reflect your unique workflow.

Identify blockers and dependencies: Ensure that your kanban board enables immediate identification of blockers and dependencies. This transparency allows for prompt resolution and prevents workflow disruptions.

Set work-in-progress (WIP) limits: Implement WIP limits for each workflow stage to avoid overburdening and to maintain a steady workflow. WIP limits help optimize resource allocation and reduce multitasking, fostering higher productivity.

Encourage collaboration: Foster a culture of collaboration within your team, where members collectively address bottlenecks and work together to ensure smooth workflow progression. This collaborative approach promotes efficiency and accelerates task completion.

Utilize kanban cards: Represent each task as a kanban card on the board, containing essential details such as task description, assignee, and estimated time for completion. Kanban cards facilitate visual tracking of task progress and promote transparency within the team.

By structuring your kanban flow in this manner, you can streamline your software development processes, enhance team collaboration, and maximize efficiency in task management.

Exploring the origins of Kanban

Kanban is prominent among today's agile and DevOps software teams, but the Kanban methodology dates back more than 50 years. In the late 1940s, Toyota began optimizing its engineering processes based on the same model supermarkets used to stock their shelves. 

Supermarkets stock just enough inventory to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the excess inventory it must hold at any given time. Meanwhile, the supermarket can still ensure that essential products are always in stock.

When Toyota applied this same system to its factory floors, the goal was to better align its massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban," between teams. 

When someone emptied a bin of materials used on the production line, a kanban card was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor and, in turn, send their own kanban to the supplier. While this process has evolved since the 1940s, this same "just in time" (JIT) manufacturing process remains at the heart of the kanban methodology.

Kanban for software teams

Agile software development teams today can leverage JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus on continuous improvement, and transparency throughout the development cycle.

Kanban Board | Atlassian agile coach

While the core principles of the Kanban framework are timeless and applicable to almost any industry, software development teams have found particular success with the agile practice. Unlike implementing kanban on a factory floor, which would involve changes to physical processes and the addition of substantial materials, the only physical things software teams need are a board and task cards, and even those can be virtual.

Kanban boards

The work of all Kanban teams revolves around a Kanban board, a tool used to visualize and optimize the workflow across teams. While physical boards are popular among some teams, virtual boards are crucial in any agile software development tool for their traceability, collaboration, and accessibility from multiple locations.

Regardless of whether a team uses a digital or physical kanban board, it ensures that the team visualizes their work, standardizes their workflow, and immediately identifies and resolves all blockers and dependencies. A basic kanban board has a three-step workflow: To Do, In Progress, and Done. However, depending on a team's size, structure, and objectives, they can map the workflow to meet their unique processes.

Because the kanban methodology relies upon full transparency of work and real-time communication, the kanban board acts as the single source of truth for the team's work.

Agile Kanban Board | Atlassian agile coach

Kanban cards

In Japanese, kanban literally translates to "signboard." Kanban teams represent every work item as a separate card on the board. The main purpose of representing work as a card on the Kanban board is to allow team members to track progress through its workflow in a highly visual manner. 

Kanban cards feature critical information about project tasks, giving teams visibility into who is responsible for which tasks and a brief description of the job, and how long tasks are estimated to take. Cards on virtual kanban boards often feature screenshots and other technical details that are valuable to the assignee. 

Enabling team members to view the status of each task at any moment, alongside relevant details, promotes heightened focus, comprehensive traceability, and rapid identification of blockers and dependencies.

Benefits of the kanban framework

Kanban is one of the most popular software development methodologies agile teams use today. Kanban offers additional advantages to task planning and throughput for teams of all sizes.

Planning flexibility

A kanban team focuses only on the work that's actively in progress. Once the team completes a task, they select the next task from the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team because any changes outside the current work items don't impact the team. 

As long as the product owner keeps the most important work items on top of the backlog, the development team can rest assured they are delivering maximum value back to the business.


Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure no surprises. 

Shortened time cycles

Cycle time is a key metric for Kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team's workflow—from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

Overlapping skill sets lead to shorter cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. Therefore, teams employ best practices like code review and mentoring to help spread knowledge. Shared skills mean team members can take on heterogeneous work, further optimizing cycle time. 

Additionally, this approach empowers the entire team to address any work bottlenecks collectively, facilitating a swift resolution and ensuring a smooth workflow. For example, testing responsibilities extend beyond QA engineers to include developers, fostering a collaborative effort to maintain efficiency. In a kanban system, the entire team ensures work moves smoothly through the process.

Fewer bottlenecks

Multitasking kills efficiency. Increased workload simultaneously leads to more frequent context switching, impeding the progress of tasks toward completion. That's why a vital tenet of the kanban process is limiting the work in progress (WIP). Work-in-progress limits highlight bottlenecks in the team's process due to a lack of focus, people, or skill sets.

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's a good reason for it. 

Developers often prefer to write new code rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state and review others' work before raising their code reviews, ultimately reducing the overall cycle time.

Visual metrics

One of the core values is a strong focus on continually improving team efficiency and effectiveness with every iteration of work. Charts provide a visual mechanism for teams to ensure they're continuing to improve. 

When the team can see data, it's easier to spot bottlenecks in the process (and remove them). Two common reports Kanban teams use are control charts and cumulative flow diagrams. A control chart shows the cycle time for each issue and a rolling average for the team.

Pro Tip:

The team's goal is to reduce the time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart indicates success.

Agile control chart | Atlassian agile coach

A cumulative flow diagram shows the number of issues in each state. The team can easily spot blockers when the number of issues increases in any given state. Issues in intermediate states such as "In Progress" or "In Review" are not yet shipped to customers, and a blocker in these states can increase the likelihood of massive integration conflicts when the work gets merged upstream.

Cumulative Flow Diagram

Continuous delivery

Continuous delivery (CD) describes the process of releasing work to customers frequently. Continuous integration (CI) is the practice of automatically building and testing code incrementally throughout the day. Together, they form a CI/CD pipeline that is essential for DevOps teams to ship software faster while ensuring high quality.

Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value. The faster a team can deliver innovation to the market, the more competitive their product will be. Kanban teams focus on precisely that: optimizing the flow of work out to customers.

Scrum vs. kanban

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. 




Release methodology


Regular fixed-length sprints (i.e., two weeks)


Continuous flow



Product owner, scrum master, development team


Continuous delivery or at the team's discretion

Key metrics




Cycle time

Change philosophy


Teams should strive not to change the sprint forecast during the sprint. Doing so compromises learning around estimation.


Change can happen at any time

Some teams blend the ideals of the kanban method and scrum into "scrumban." They take fixed-length sprints and roles from Scrum and focus on work-in-progress limits and cycle time from Kanban.

For teams just starting with agile, we strongly recommend choosing one methodology and running with it for a while. If your team is ready to use the kanban methodology, use our free kanban board template today!

Jira board

Get started free with the Jira kanban template

Maximize efficiency by seeing and moving forward the work that matters most.

Dan Radigan
Dan Radigan

Agile has had a huge impact on me both professionally and personally as I've learned the best experiences are agile, both in code and in life. You'll often find me at the intersection of technology, photography, and motorcycling. 

Up Next