# Kanban - A Brief Introduction | Atlassian ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article2.74d541386bbf.png) URL:: https://www.atlassian.com/agile/kanban Author:: Atlassian ## Highlights > A kanban board is a physical or digital project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency(or flow). ([View Highlight](https://read.readwise.io/read/01g379cwhakp9tjahc4a4ahkaw)) > Learn how to use work in progress limits, the 4 goals for agile teams using WIP limits, and why WIP limits are important. Get started here. ([View Highlight](https://read.readwise.io/read/01g379d2s7x0sfz0zc79z7qckm)) > Kanplan adds the backlog and backlog grooming concepts of scrum to kanban, using the backlog instead of the To Do column to plan and prioritize work. ([View Highlight](https://read.readwise.io/read/01g379d85cak7f8k57mktzefhs)) > In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product 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 amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock. > When Toyota applied this same system to its factory floors, the goal was to better align their 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 a bin of materials being used on the production line was emptied, a kanban 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. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it. ([View Highlight](https://read.readwise.io/read/01g379emhnnmdqwfsb7346jjyg)) > In Japanese, kanban literally translates to "visual signal." For kanban teams, every work item is represented as a separate card on the board. ([View Highlight](https://read.readwise.io/read/01g379f38hank1h87j7wzq28tj)) > A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the [backlog](https://www.atlassian.com/agile/scrum/backlogs). ([View Highlight](https://read.readwise.io/read/01g379fkw93sc30g09s2hma3ap)) > Multitasking kills efficiency. The more work items in flight at any given time, the more context switching, which hinders their path to completion. That's why a key tenet of kanban is to limit the amount of work in progress (WIP). Work-in-progress limits highlight bottlenecks and backups in the team's process due to lack of focus, people, or skill sets. ([View Highlight](https://read.readwise.io/read/01g379gt955nysjyd93pbjem08)) > For example, a typical software team might have four [workflow](https://www.atlassian.com/agile/project-management/workflow) states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's 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 to review others work before raising their own code reviews. This ultimately reduces the overall cycle time. ([View Highlight](https://read.readwise.io/read/01g379hmk30dyqy45kmqnb56g3)) > 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 market, the more competitive their product will be in the marketplace. And kanban teams focus on precisely that: optimizing the flow of work out to customers ([View Highlight](https://read.readwise.io/read/01g379j1efe48b6yv6786pv4m6)) > Some teams blend the ideals of kanban and scrum into "scrumban." They take fixed length sprints and roles from scrum and the focus on work in progress limits and cycle time from kanban. For teams just starting out with agile, however, we strongly recommend choosing one methodology or the other and running with it for a while. You can always get fancy later on. ([View Highlight](https://read.readwise.io/read/01g379jbkk8e8gv44qx0r07qkw)) --- Title: Kanban - A Brief Introduction | Atlassian Author: Atlassian Tags: readwise, articles date: 2024-01-30 --- # Kanban - A Brief Introduction | Atlassian ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article2.74d541386bbf.png) URL:: https://www.atlassian.com/agile/kanban Author:: Atlassian ## AI-Generated Summary An introduction to kanban methodology for agile software development and its benefits for your agile team. ## Highlights > A kanban board is a physical or digital project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency(or flow). ([View Highlight](https://read.readwise.io/read/01g379cwhakp9tjahc4a4ahkaw)) > Learn how to use work in progress limits, the 4 goals for agile teams using WIP limits, and why WIP limits are important. Get started here. ([View Highlight](https://read.readwise.io/read/01g379d2s7x0sfz0zc79z7qckm)) > Kanplan adds the backlog and backlog grooming concepts of scrum to kanban, using the backlog instead of the To Do column to plan and prioritize work. ([View Highlight](https://read.readwise.io/read/01g379d85cak7f8k57mktzefhs)) > In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product 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 amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock. > When Toyota applied this same system to its factory floors, the goal was to better align their 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 a bin of materials being used on the production line was emptied, a kanban 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. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it. ([View Highlight](https://read.readwise.io/read/01g379emhnnmdqwfsb7346jjyg)) > In Japanese, kanban literally translates to "visual signal." For kanban teams, every work item is represented as a separate card on the board. ([View Highlight](https://read.readwise.io/read/01g379f38hank1h87j7wzq28tj)) > A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the [backlog](https://www.atlassian.com/agile/scrum/backlogs). ([View Highlight](https://read.readwise.io/read/01g379fkw93sc30g09s2hma3ap)) > Multitasking kills efficiency. The more work items in flight at any given time, the more context switching, which hinders their path to completion. That's why a key tenet of kanban is to limit the amount of work in progress (WIP). Work-in-progress limits highlight bottlenecks and backups in the team's process due to lack of focus, people, or skill sets. ([View Highlight](https://read.readwise.io/read/01g379gt955nysjyd93pbjem08)) > For example, a typical software team might have four [workflow](https://www.atlassian.com/agile/project-management/workflow) states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's 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 to review others work before raising their own code reviews. This ultimately reduces the overall cycle time. ([View Highlight](https://read.readwise.io/read/01g379hmk30dyqy45kmqnb56g3)) > 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 market, the more competitive their product will be in the marketplace. And kanban teams focus on precisely that: optimizing the flow of work out to customers ([View Highlight](https://read.readwise.io/read/01g379j1efe48b6yv6786pv4m6)) > Some teams blend the ideals of kanban and scrum into "scrumban." They take fixed length sprints and roles from scrum and the focus on work in progress limits and cycle time from kanban. For teams just starting out with agile, however, we strongly recommend choosing one methodology or the other and running with it for a while. You can always get fancy later on. ([View Highlight](https://read.readwise.io/read/01g379jbkk8e8gv44qx0r07qkw))