Kanban (Japanese: , meaning signboard or billboard) is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.
Work items are visualized to give participants a view of progress and process, from start to finish--usually via a Kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested.
In knowledge work and in software development, the aim is to provide a visual process management system which aids decision-making about what, when, and how much to produce. The underlying Kanban method originated in lean manufacturing, which was inspired by the Toyota Production System. It has its origin in the late 1940s when the Toyota automotive company implemented a production system called just-in-time; which had the objective of producing according to customer demand and identifying possible material shortages within the production line. But it was Microsoft engineer David J. Anderson who realized how this method devised by Toyota could become a process applicable to any type of company that needs organization. Kanban is commonly used in software development in combination with other methods and frameworks such as Scrum.
David Anderson's 2010 book, Kanban, describes an evolution of the approach from a 2004 project at Microsoft using a theory-of-constraints approach and incorporating a drum-buffer-rope (comparable to the kanban pull system), to a 2006-2007 project at Corbis in which the kanban method was[by whom?] identified. In 2009, Don Reinertsen published a book on second-generation lean product-development which describes the adoption of the kanban system and the use of data collection and an economic model for management decision-making. Another early contribution came from Corey Ladas, whose 2008 book Scrumban suggested that kanban could improve Scrum for software development. Ladas saw Scrumban as the transition from Scrum to Kanban. Jim Benson and Tonianne DeMaria Barry published Personal Kanban, applying Kanban to individuals and small teams, in 2011. In Kanban from the Inside (2014), Mike Burrows explained kanban's principles, practices and underlying values and related them to earlier theories and models. In Agile Project Management with Kanban (2015), Eric Brechner provides an overview of Kanban in practice at Microsoft and Xbox. Kanban Change Leadership (2015), by Klaus Leopold and Siegfried Kaltenecker, explained the method from the perspective of change management and provided guidance to change-initiatives. In 2016 Lean Kanban University Press published a condensed guide to the method, incorporating improvements and extensions from the early kanban projects.
The diagram here shows a software development workflow on a Kanban board. Kanban boards, designed for the context in which they are used, vary considerably and may show work item types ("features" and "user stories" here), columns delineating workflow activities, explicit policies, and swimlanes (rows crossing several columns, used for grouping user stories by feature here). The aim is to make the general workflow and the progress of individual items clear to participants and stakeholders.
As described in books on Kanban for software development, the two primary practices of Kanban are to visualize your work and limit work in progress (WIP). Four additional general practices of Kanban listed in Essential Kanban Condensed, are to make policies explicit, manage flow, implement feedback loops, and improve collaboratively.
The Kanban board in the diagram above highlights the first three general practices of Kanban.
For example, on the Kanban board shown above, the "Deployment" step has a WIP limit of five and there are currently five epics shown in that step. No more work items can move into deployment until one or more epics complete that step (moving to "Delivered"). This prevents the "Deployment" step from being overwhelmed. Team members working on "Feature Acceptance" (the previous step) might get stuck because they can't deploy new epics. They can see why immediately on the board and help with the current epic deployments.
Once the five epics in the "Deployment" step are delivered, the two epics from the "Ready" sub-column of "Feature Acceptance" (the previous step) can be moved to the "Deployment" column. When those two epics are delivered, no other epics can be deployed (assuming no new epics are ready). Now, team members working on deployment are stuck. They can see why immediately and help with feature acceptance.
This workflow control works similarly for every step. Problems are visual and evident immediately, and re-planning can be done continuously. The work management is made possible by limiting work in progress in a way team members can see and track at all times.
Kanban uses specific metrics to measure team capacity and estimate project length.
Team velocity defines how many tasks a team can deliver in a given period of time, for example a week or iteration. Velocity is calculated periodically and to help with accuracy of the calculated velocity, teams aim to create tasks that are similar in size. Knowing team velocity helps better predict when a project is going to end.
Lead and Cycle time defines the average time it takes to complete a task. Lead time is calculated since the team gets a request from the client and Cycle time is calculated since the team starts working on a task. Lead time is used to understand how long a client has to wait for their product and cycle time is used to understand how fast the team produces a product. 
Actionable Agile metrics use cycle time to better predict when each project item is going to be finished. Created by Daniel S. Vacanti in 2015, actionable Agile metrics measure how much time it took to finish 50%, 85% and 95% of the tasks. And use this information to help the team better predict and control task delivery dates.