Quelltext der Seite Kanban (Entwicklung)

'''Kanban''' ist eine Methode mit Ursprung in der Produktionssteuerung und wurde für die Softwareentwicklung stark adaptiert. Ziel ist die transparente Darstellung der vorliegenden Aufgaben. Die bessere Visualisierung ermöglicht die Arbeitsschritte besser zu steuern und somit kürzere [[Durchlaufzeit]]en zu erreichen. Auch Probleme – insbesondere [[Flaschenhals (Logistik)|Engpässe]] – können schnell sichtbar gemacht werden.

== Wurzeln und Geschichte ==
Das japanische Wort ''{{lang|ja-Latn|[[Kanban]]}}'' bedeutet ursprünglich ‚Signalkarte‘ (''{{lang|ja-Latn|kan}}'' ‚Signal‘, ''{{lang|ja-Latn|ban}}'' ‚Karte‘) und ist eine Technik aus dem [[Toyota-Produktionssystem]], mit der ein gleichmäßiger Fluss in der Fertigung hergestellt und so Lagerbestände reduziert werden sollen. Der Schwerpunkt liegt dabei auf dem optimalen Fluss jedes einzelnen Produktes durch die Fertigung. Kanban in der [[Informationstechnik]] (IT) übernimmt zwar den Namen, versucht aber keine direkte Übertragung einzelner Techniken aus der Produktion auf die IT. Vielmehr werden einige grundlegende Prinzipien aus der ''{{lang|en|Lean Production}}'' (‚[[Schlanke Produktion]]‘), und mehr noch dem ''{{lang|en|[[Lean Development]]}}'' (auch ''{{lang|en|Lean Product Development}}''), übernommen und ergänzt durch die ''{{lang|en|[[Theory of Constraints]]}}''<ref>D. Anderson: ''Agile Management for Software Engineering - Applying the Theory of Constraints for Business Results''. Prentice Hall, 2004, ISBN 0-13-142460-2</ref> und das klassische [[Risikomanagement]]. Insbesondere die Ideen Don Reinertsens, der verschiedene Techniken vorstellt, wie sich Produkte in wesentlich kürzerer Zeit entwickeln lassen, spielen eine wichtige Rolle in Kanban. Als Begründer von Kanban in der IT gilt [[David J. Anderson]], der zuvor an der Entwicklung von [[Feature Driven Development]] mit beteiligt war und 2010 das erste Buch zu Kanban veröffentlichte.

== Prinzipien und Praktiken ==
Anderson beschreibt sechs Prinzipien und sechs Praktiken, die Unternehmen in ihre Arbeitsweise integrieren, wenn sie Kanban anwenden:

=== Prinzipien ===
''Change-Prinzipien''
* Starte mit dem, was jetzt getan wird: In diesem Grundprinzip stecken zwei Dinge. Indem man mit dem beginnt, was man gerade tut, beendet man die aktuelle Arbeit, bevor etwas Neues begonnen wird. Genauso ist hier aber auch die Aussage enthalten, dass Kanban einfach eingeführt werden kann, alle bestehenden Rollen, Prozesse und Verantwortlichkeiten bleiben bestehen.
* Führe Einigung darüber herbei, Verbesserung durch evolutionäre Veränderungen anzustreben: Weiterentwicklung ist essentiell, hier sollen Verbesserungen aber vor allem durch kleine/evolutionäre Schritte erreicht werden.
* Fördere Handlungen von Leadership auf allen Ebenen: Verbesserung kann nur funktionieren, wenn sich alle Ebenen in der Organisation daran beteiligen. Besonders wichtig ist es, dass Mitarbeiter, die direkt die Arbeit verrichten, „Acts of Leadership“ zeigen und konkrete Verbesserungsvorschläge einbringen.<ref>{{Literatur |Autor=Burrows, Mike |Titel=Kanban: verstehen, einführen, anwenden |Ort=Heidelberg |Datum=2015 |ISBN=978-3-86490-253-6}}</ref>

''Service-Erbringungs-Prinzipien''
* Verstehe die Bedürfnisse und Erwartungen der Kunden und fokussiere Dich auf diese
* Manage die Arbeit, lass die Menschen sich selbst um die Arbeit herum organisieren
* Entwickle das Netzwerk aus Services und dessen Regeln häufig weiter, um Ergebnisse zu verbessern<ref>{{Internetquelle |autor= |url=https://kanban.university/kanban-guide/ |titel=The Official Guide to The Kanban Method |werk=kanban.university |sprache=en |datum=2021-03-01 |abruf=2025-12-13}}</ref>

=== Praktiken ===
; <nowiki>Visualisiere</nowiki>
: Die Wertschöpfungskette mit ihren verschiedenen Prozessschritten (zum Beispiel [[Anforderungsdefinition]], [[Entwicklung]], [[Softwaredokumentation|Dokumentation]], [[Softwaretest|Test]], [[Inbetriebnahme]]) wird gut sichtbar für alle Beteiligten visualisiert. Dafür wird ein ''[[Kanban-Tafel|Kanban-Board]]'' (in der Regel ein großes ''{{lang|en|[[Schreibtafel#Whiteboard|Whiteboard]]}}'') verwendet, auf dem die unterschiedlichen Aktivitäten als Spalten dargestellt werden. Die einzelnen Anforderungen (es können ''{{lang|en|Tasks}}'', ''{{lang|en|Features}}'', ''{{lang|en|User Stories}}'', ''{{lang|en|Minimal Marketable Features}}'' (MMF) usw. sein) werden auf Karteikarten oder Haftnotizen festgehalten und durchwandern mit der Zeit als so genannte Tickets das Kanban-Board von links nach rechts.
; <nowiki>Limitiere die parallele Arbeit (das WIP)</nowiki>
: Die Anzahl der Tickets (''{{lang|en|Work in Progress}}'' – WiP), die gleichzeitig innerhalb einer Aktivität bearbeitet werden dürfen, wird limitiert (''WiP-Limit''). Wenn beispielsweise die Entwicklung gerade zwei Tickets bearbeitet, und das Limit für diese Aktivität zwei beträgt, darf sie kein drittes Ticket annehmen, auch wenn die Anforderungsdefinition ein weiteres bereitstellen könnte. Hierdurch entsteht ein Pull-System, bei dem sich jede Aktivität ihre Arbeit bei der Vorgängeraktivität abholt, anstatt fertige Arbeit einfach an die nächste Aktivität zu übergeben.
; <nowiki>Steuere den Arbeitsfluss</nowiki>
: Die Mitglieder eines Kanban-Prozesses messen typische Größen wie die [[Durchlaufzeit]], die Lieferrate und das WIP, um festzustellen, wie gut die Arbeit organisiert ist, wo man noch etwas verbessern kann und welche Versprechen man an die Kunden geben kann, für die man arbeitet. Dadurch wird die Planung erleichtert und die Verlässlichkeit gesteigert.
; <nowiki>Mache Regeln explizit</nowiki>
: Um sicherzustellen, dass alle Beteiligten des Prozesses wissen, unter welchen Annahmen und Gesetzmäßigkeiten man arbeitet, werden möglichst alle Regeln der Zusammenarbeit, die es gibt, explizit gemacht. Dazu gehören z.&nbsp;B.
:* eine Definition des Begriffes „fertig“, ähnlich der [[Scrum#Definition of Done|Definition of Done in Scrum]],
:* Bedeutung der einzelnen Spalten,
:* Antworten auf die Fragen: wer zieht, wann zieht man, wie wählt man das nächste zu ziehende Ticket aus der Menge der vorhandenen Tickets aus (Pull-Kriterien)
; <nowiki>Implementiere Feedbackschleifen</nowiki>
: In festgesetzten Terminen gibt sich das Team (oder die Teams untereinander) gegenseitig Feedback.
: Beispiele:
:* Retrospektiven: Zusammenarbeit revue passieren lassen
:* Standup Meeting: Absprache anstehender Aufgaben / Blockaden ansprechen / Fluss koordinieren
:* Operation Reviews: Kanban-Teams des Unternehmens treffen sich und tauschen Erfahrungen aus
; <nowiki>Verbessere gemeinsam, entwickle experimentell weiter</nowiki>

Die Visualisierung und die Begrenzung des WiP sind einfache Mittel, mit denen rasch sichtbar wird, wie schnell die Tickets die verschiedenen Aktivitäten durchlaufen und wo sich Tickets stauen. Die Stellen, vor denen sich Tickets häufen, während an den nachfolgenden Aktivitäten freie Kapazitäten vorhanden sind, werden als ''{{lang|en|Bottlenecks}}'' bezeichnet.
Durch Analysen des Kanban-Boards können immer wieder Maßnahmen ergriffen werden, um einen möglichst gleichmäßigen Fluss zu erreichen. Beispielsweise können die Limits für einzelne Aktivitäten verändert werden, es können Puffer eingeführt werden (insbesondere vor ''{{lang|en|Bottlenecks}}'', die durch nur zeitweise Verfügbarkeit von Ressourcen entstehen), die Anzahl der Mitarbeiter an den verschiedenen Aktivitäten kann verändert werden, technische Probleme werden beseitigt usw. Dieser [[Kontinuierlicher Verbesserungsprozess|kontinuierliche Verbesserungsprozess]] (japanisch: ''{{lang|ja-Latn|[[Kaizen]]}}'') ist wesentlicher Bestandteil von Kanban.

== Kaizen ==
Kanban enthält als festen Bestandteil eine Kultur des [[Kontinuierlicher Verbesserungsprozess|kontinuierlichen Verbesserungsprozesses]] (KVP), gibt aber keine konkreten Kadenzen hierfür vor. In vielen Kanban-Teams haben sich aber mindestens die folgenden drei Kadenzen etabliert:
; Tägliche Statusmeetings ({{lang|en|Standup-Meetings}})
: Das Team trifft sich täglich (in der Regel morgens) vor dem Kanban-Board. Dort wird anhand der Tickets der Projektfortschritt seit dem letzten Meeting deutlich gemacht. Außerdem werden Probleme verdeutlicht und Lösungswege besprochen. Das Meeting ist allerdings auf Kürze angelegt (zirka 15 Minuten), so dass längere Diskussionen ausgelagert werden.
; {{lang|en|Operations Reviews}}
: In Kanban werden so genannte ''{{lang|en|Operation Reviews}}'' abgehalten. Dies sind Meetings, die der kontinuierlichen Verbesserung dienen. Sie weisen Ähnlichkeiten zu Retrospektiven auf, wie sie aus anderen agilen Methoden bekannt sind. Allerdings finden ''{{lang|en|Operation Reviews}}'' unregelmäßig statt. Und sie streben eine hohe Objektivität an, indem sie sich stärker auf die gesammelten Daten aus der Vergangenheit beziehen. Weiterhin wird versucht, dass an diesen Meetings Teilnehmer aus der gesamten Organisation teilnehmen (inklusive Management), und nicht nur das Entwicklungsteam.
; {{lang|en|Root Cause Analysis}}
: Probleme sollen in Kanban nicht verwaltet, sondern behoben werden. Dies geschieht im Wesentlichen dadurch, dass durch das Kanban-Board Fehler schnell deutlich werden, zum Beispiel weil sich Arbeit staut, einzelne Aktivitäten nicht ausgelastet sind, die Durchlaufzeiten zu lang sind oder einzelne Tickets ständig an derselben Aktivität bleiben. Die Fehlerursachen sollen schnell ausfindig gemacht und schnell beseitigt werden (gegebenenfalls durch die Zusammenarbeit des gesamten Teams).

== ''{{lang|en|Value, Flow}}'' und ''{{lang|en|Waste Elimination}}'' ==
Kanban orientiert sich am Grundsatz aus dem ''{{lang|en|Lean Thinking}}'' {{" |Sprache=en |Text=''Value Trumps Flow, Flow Trumps Waste Elimination'' |Übersetzung=Wert geht über Fluss, Fluss geht über Beseitigung von Verschwendung}}.
Dies bedeutet, dass zwar großer Wert darauf gelegt wird, Verschwendung zu beseitigen (zum Beispiel unfertige Aufgaben) und einen möglichst gleichmäßigen Fluss zu gewährleisten, dass an erster Stelle jedoch stets der Wert der zu erledigenden Tickets steht. Deshalb kann es auch gerechtfertigt werden, ein Kanban-Limit kurzfristig zu brechen, um ein sehr wichtiges Ticket schneller zu bearbeiten oder Features schon im Vorwege detailliert zu spezifizieren, obwohl ungewiss ist, ob/wann sie tatsächlich realisiert werden.

== Priorisierung ==
Um zu entscheiden, welche ''{{lang|en|work items}}'' zu welchem Zeitpunkt in das Kanban-System genommen werden, wird häufig nach dem Schema der Verzögerungskosten (''{{lang|en|Cost of Delay}}'') priorisiert, das auf [[Donald G. Reinertsen|Reinertsen]]/[[Steven Smith (IT)|Smith]] zurückgeht. Die Idee dahinter ist, dass es nicht nur Kosten verursacht, neue ''work items'' zu bearbeiten, sondern dass auch Kosten dadurch entstehen, wenn diese mit Verzögerung auf den Markt gebracht werden. Streng genommen handelt es sich dabei nicht um „Kosten“, sondern um [[Opportunitätskosten|Verzichtskosten]]. Standardmäßig ist davon auszugehen, dass ein ''work item'' umso mehr Verzögerungskosten verursacht, je später es am Markt ist. Die Frage ist dann, wie teuer jeder weitere Tag/Woche/Monat Verzögerung ist und wie sich diese Kosten im Verhältnis zu den Verzögerungskosten für andere ''work items'' verhalten.
Es gibt aber auch ''work items'' bei denen über einen gewissen Zeitraum gar keine Verzögerungskosten anfallen, diese dann aber an einem fixen Termin schlagartig ansteigen (und dann sogar das gesamte Unternehmen gefährden können), oder auch kritische ''work items'' die von Beginn an hohe Verzögerungskosten verursachen.

== Service-Klassen ==
Wenn ein Kanban-System installiert wird, werden zu Beginn in der Regel alle Tickets gleich behandelt. Das bedeutet, dass diejenigen Tickets, die zuerst in der ersten Aktivität erledigt wurden, auch zuerst in der nächsten Aktivität bearbeitet werden. Dieses Vorgehen wird als FIFO (''{{lang|en|[[First In – First Out]]}}'') bezeichnet. Oft wird jedoch schnell deutlich, dass Tickets mit verschiedener Wichtigkeit behandelt werden. Deshalb wird in Kanban vorgeschlagen, verschiedene Service-Klassen (''{{lang|en|Classes of Service}}'') zu definieren:
; Beschleunigt (''{{lang|en|Expedite}}'')
: Diese Tickets müssen mit hoher Priorität behandelt werden. Es kann nötig sein, dass das gesamte Team seine momentane Tätigkeit stoppt, um dieses Ticket zu bearbeiten. Für diese Service-Arten werden häufig die Kapazitätslimits der einzelnen Aktivitäten vorübergehend außer Kraft gesetzt.
; Fester Termin (''{{lang|en|Fixed-Date}}'')
: Wenn eine Funktionalität erst zu einem fixen Termin benötigt wird (zum Beispiel weil dann eine Gesetzesänderung wirksam wird), dann werden die entsprechenden Tickets so durch das Kanban-System geschleust, dass die Funktionalität kurz vor diesem Stichtag produktiv geht.
; Vage (''{{lang|en|Intangible}}'')
: Wenn der Geschäftswert und/oder die Verzögerungskosten für eine neue Funktionalität vage sind, werden die entsprechenden Tickets nachrangig behandelt. Das Team kann zum Beispiel definieren, dass sich zu jedem Zeitpunkt nur ''ein'' solches Ticket im System befinden darf.
; Standard (''{{lang|en|Standard}}'')
: Alle anderen Tickets zählen zur Standard-Serviceklasse. In der Regel werden sie nach FIFO behandelt. Das Team kann jedoch auch andere/zusätzliche Regeln definieren.
Die Service-Arten werden maßgeblich bestimmt durch die Art der Verzögerungskosten, die mit den jeweiligen ''work-items'' verbunden sind.

== Varianzen ==
Auch wenn es unrealistisch ist, dass alle Anforderungen exakt dieselbe Größe haben bzw. immer in nahezu derselben Zeit erledigt werden können, wird in Kanban-Systemen angestrebt, diesem Ideal möglichst nahezukommen. Ein Ziel von Kanban ist es daher, die Varianzen zu verringern. Dies geschieht, indem zum Beispiel ''{{lang|en|User Stories}}'' in ''{{lang|en|Tasks}}'' möglichst gleicher Komplexität heruntergebrochen werden.

== ''Tracking'' ==
In Kanban-Systemen werden verschiedene Maße ([[Softwaremetrik|Metriken]]) aufgezeichnet, um empirische Daten für zukünftige Verbesserungen zu sammeln:
; {{lang|en|Cumulative Flow Diagram}} (CFD)
: Das kumulative Flussdiagramm kann als Weiterentwicklung der ''{{lang|en|Burnup}}''-Diagramme angesehen werden, die in [[Extreme Programming|XP]] und (teilweise) Scrum verwendet werden. Allerdings zeigt ein CFD nicht nur an, wann wie viele Tasks erledigt werden, sondern es visualisiert die Zustände in allen Aktivitäten des Kanban-Systems (z.&nbsp;B. Entwicklung, Dokumentation, Test usw.). Es macht so schnell deutlich, wo sich die ''{{lang|en|Bottlenecks}}'' befinden.
; {{lang|en|Work in Progress}} (WiP)
: Dieses sehr einfache Diagramm zeigt an, wie sich die Anzahl der ''{{lang|en|Tasks}}'' und ''{{lang|en|Stories}}'' entwickelt, die sich gleichzeitig im Kanban-System befinden. Eine stetig steigende Kurve signalisiert dabei in der Regel ein Problem (zum Beispiel immer mehr blockierte Tickets).
; Durchlaufzeit
: In einem einfachen Liniendiagramm wird dargestellt, wie viele Tickets pro Woche erledigt wurden.
; Fehlerrate
: Durch dieses Diagramm wird kontrolliert, wie sich die Anzahl an Fehlern über die Zeit entwickelt. Weil Kanban auf kurze Durchlaufzeiten ausgerichtet ist und eine Grundannahme lautet, dass kurze Durchlaufzeiten nur durch hohe Qualität zu erreichen sind, liegt ein wichtiges Ziel von Kanban immer in der Reduzierung der Fehlerrate.

== Anwendungsbereiche ==
Die Anwendungsbereiche von Kanban sind sehr vielfältig. Momentan wird Kanban hauptsächlich in diesen Fällen eingeführt:
* Ein Team, das bereits agil vorgeht (zum Beispiel nach [[Scrum]]), sucht nach weiteren Verbesserungsmöglichkeiten. Kanban stellt hierbei eine Möglichkeit dar, noch flexibler mit den Anforderungen umzugehen, die Durchlaufzeiten zu verkürzen, häufiger freizugeben und fokussierter zu arbeiten.
* Für klassisch ausgerichtete Unternehmen, die zum Beispiel nach dem Wasserfall-Modell vorgehen, stellt es häufig eine zu große Herausforderung dar, ein agiles Vorgehen wie Scrum einzuführen, weil hierfür recht weitreichende Veränderungen nötig sind. In diesem Fall bietet Kanban den Vorteil, dass Änderungen evolutionär eingeführt werden können, ohne dass dies unmittelbar größere Änderungen nötig macht.
* Für Bereiche, die durch starke Arbeitsteilung und Spezialisierung gekennzeichnet sind, ist Kanban häufig attraktiver als andere agile Methoden, in denen häufig gefordert wird, dass die Teams aus Generalisten bestehen und keine Wissensinseln vorhanden sind. Dies scheint aber für einige Bereiche unrealistisch zu sein.
* In Bereichen mit hohen Unsicherheiten sind ungestörtes Arbeiten und Iterationen fester Länge wie in Scrum kaum möglich. Hier kann Kanban mit den verschiedenen Service-Arten die bessere Wahl darstellen.

== Zertifizierung ==
David Anderson gründete die ''David J. Anderson School of Management'' in [[Bilbao]] und die ''Kanban University'' in [[Seattle]], die Personenzertifizierungen zu Kanban anbieten. Bis heute wurden weltweit über 150.000 Personen Kanban-zertifiziert.<ref>{{Internetquelle |autor= |url=https://kanban.university/about/ |titel=About |werk=kanban.university |sprache=en |datum=2014-09-29 |abruf=2025-12-13}}</ref>

== Verhältnis zu anderen Vorgehensweisen  ==
=== Wasserfall ===
Auch wenn die Aktivitäten auf einem Kanban-Board häufig genau den Schritten des [[Wasserfallmodell]]s entsprechen, besteht hier kein zwingender Zusammenhang. Insbesondere ist Kanban darauf angelegt, dass die einzelnen Tickets möglichst schnell alle Aktivitäten durchlaufen und dann auch regelmäßig freigegeben werden. Kanban arbeitet also mit kleinen Schritten, die regelmäßig überprüft und gegebenenfalls wieder korrigiert werden. Allerdings lässt sich Kanban auf ein existierendes Wasserfall-Modell aufsetzen und kann dazu führen, dieses allmählich schneller und flexibler zu gestalten.

Der Unterschied zum klassischen Wasserfall wird insbesondere dadurch deutlich, dass im Wasserfall das gesamte Produkt seriell die einzelnen Produktionsphasen durchläuft, bei Kanban dagegen einzelne „Werkstücke“ bzw. Produktanforderungen. Insbesondere versucht man bei Kanban, die ''{{lang|en|batch size}}'', d.&nbsp;h. die Menge gleichzeitig in das Produktionssystem eingegebener Anforderungen, zu reduzieren.

=== Scrum ===
Kanban weist viele Gemeinsamkeiten mit dem agilen Produktentwicklungsframework<ref>{{Internetquelle |autor=Ken Schwaber; Jeff Sutherland |url=https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf |titel=2020-Scrum-Guide |werk= |hrsg= |datum= |abruf=2021-02-09  |format=PDF |sprache=DE}}</ref> [[Scrum]] auf, steht jedoch in keinem zwingenden Verhältnis zu diesem. Weder muss man zuerst Scrum einsetzen, bevor man Kanban einführt, noch schließen sich beide Ansätze komplett aus. In gewisser Weise lässt sich Scrum als ''eine'' mögliche Implementierung von Kanban ansehen. Der Hauptunterschied zwischen beiden Ansätzen besteht darin, dass Scrum ein team-zentrierter Ansatz ist und Kanban primär die Wertgenerierung entlang der Wertschöpfungskette optimiert.

Nach [[Henrik Kniberg]] lassen sich folgende Gemeinsamkeiten und Unterschiede zwischen Scrum und Kanban ausmachen.<ref>{{Internetquelle |autor=Henrik Kniberg & Mattias Skarin (Übersetzung von Maria Oelinger) |url=https://wwwlehre.dhbw-stuttgart.de/~hoyer/ePapers/BUCH_Kniberg_Kanban_und_Scrum.pdf |titel=Kanban und Scrum |werk= |hrsg= |datum=2010 |abruf=2025-12-13 |format=PDF |sprache=DE}}</ref>

==== Gemeinsamkeiten von Kanban und Scrum ====

* schlank („[[Lean Development|lean]]“) und [[Agile Softwareentwicklung|agil]]
* Pull-System
* begrenzen WiP
* setzen auf Transparenz, um den Prozess zu verbessern
* fokussieren darauf, möglichst schnell und möglichst häufig releasefähige Produkt-Inkremente auszuliefern
* basieren auf selbstorganisierenden Teams
* erfordern, dass Anforderungen in kleine Einheiten heruntergebrochen werden
* In beiden wird der Releaseplan immer wieder optimiert, indem empirische Daten ausgewertet werden (Team-Geschwindigkeit / Durchlaufzeiten)

==== Unterschiede zwischen Kanban und Scrum ====
{| class="wikitable"
|-
!Kanban|| Scrum
|-
| Iterationen sind optional. Es kann unterschiedliche Takte für Planung, Releases und Prozessverbesserung geben. || Iterationen mit gleichen Längen sind vorgeschrieben.
|-
| Commitments sind optional. ||  Das Team commitet sich auf ein Sprint Ziel.
|-
| Die Durchlaufzeit (''{{lang|en|Cycle Time}}'') wird als Basis-Metrik für Planung und Prozessverbesserung verwendet. || Die Team-Geschwindigkeit (''{{lang|en|Velocity}}'') ist die Basis-Metrik für Planung und Prozessverbesserung.
|-
| Cross-funktionale Teams sind optional. Experten-Teams sind erlaubt. || Cross-funktionale Teams sind vorgeschrieben.
|-
| Keine Vorschrift bezüglich der Größe von Anforderungen. || Anforderungen müssen so aufgeteilt werden, dass sie sich innerhalb einer Iteration erledigen lassen.
|-
| WiP wird direkt limitiert. || WiP wird indirekt limitiert (durch die Menge an Anforderungen, die in einen Sprint passt).
|-
| Schätzungen sind optional. || Schätzungen sind vorgeschrieben.
|-
| Neue Anforderungen können zu jedem Zeitpunkt an das Team gegeben werden, falls Kapazitäten frei sind. || Während eines laufenden Sprints können keine neuen Anforderungen an das Team gegeben werden.
|-
| Gibt keine Rollen vor. || Schreibt drei Rollen vor (''{{lang|en|Product Owner}}'', ''{{lang|en|Scrum Master}}'', Entwicklungs-Team).
|-
| Ein Kanban-Board kann von mehreren Teams und/oder Einzelpersonen geteilt werden. || Ein Sprint-Backlog gehört einem einzelnen Team, das Product-Backlog kann zu mehreren Teams gehören.
|-
| Ein Kanban-Board wird kontinuierlich weitergepflegt. || Das Sprint-Backlog wird nach jedem Sprint gelöscht und neu aufgesetzt. Das Product-Backlog wird kontinuierlich weitergepflegt.
|-
| Priorisierung ist optional. || Schreibt vor, dass alle Einträge im Product-Backlog priorisiert sein müssen.
|}

== Literatur ==
* {{Literatur
   |Autor=David J. Anderson
   |Titel=Kanban. Evolutionäres Change Management für IT-Organisationen
   |Verlag=dpunkt.verlag
   |Ort=Heidelberg
   |Datum=2011
   |ISBN=978-3-89864-730-4
   |Originaltitel=Kanban. Successful Evolutionary Change for Your Technology Business
   |Originalsprache=en}}
* {{Literatur
   |Autor=Klaus Leopold, Siegfried Kaltenecker
   |Titel=Kanban in der IT. Eine Kultur der kontinuierlichen Verbesserung schaffen
   |Auflage=3. Auflage (1. Auflage 2012)
   |Verlag=Hanser Verlag
   |Ort=München
   |Datum=2018
   |ISBN=978-3-446-45360-9}}
* {{Literatur
   |Autor=Jim Benson, Tonianne DeMaria Barry
   |Titel=Personal Kanban. Visualisierung und Planung von Aufgaben, Projekten und Terminen mit dem Kanban-Board
   |Verlag=dpunkt.verlag
   |Ort=Heidelberg
   |Datum=2013
   |ISBN=978-3-89864-822-6
   |Originaltitel=Personal Kanban. Mapping Work, Navigating Life
   |Originalsprache=en}}
* {{Literatur
   |Autor=Mike Burrows
   |Titel=Kanban. Verstehen, einführen, anwenden
   |Verlag=dpunkt.verlag
   |Ort=Heidelberg
   |Datum=2015
   |ISBN=978-3-86490-253-6
   |Originaltitel=Kanban from the Inside
   |Originalsprache=en}}
* {{Literatur
   |Autor=Klaus Leopold
   |Titel=Kanban in der Praxis. Vom Teamfokus zur Wertschöpfung
   |Verlag=Hanser Verlag
   |Ort=München
   |Datum=2017
   |ISBN=978-3-446-44343-3}}
* {{Literatur
   |Autor=David J. Anderson, Andy Carmichael
   |Titel=Die Essenz von Kanban kompakt
   |Verlag=dpunkt.verlag
   |Ort=Heidelberg
   |Datum=2018
   |ISBN=978-3-86490-531-5
   |Originaltitel=Essential Kanban Condensed
   |Originalsprache=en}}
* {{Literatur
   |Autor=Florian Eisenberg
   |Titel=Kanban mehr als Zettel. Wie die Methoden Ihnen zu echtem Mehrwert verhilft
   |Auflage=2. Auflage (1. Auflage 2018)
   |Verlag=Hanser Verlag
   |Ort=München
   |Datum=2022
   |ISBN=978-3-446-47166-5}}
* {{Literatur
   |Autor=David J. Anderson, Alexei Zheglov
   |Titel=Fit for Purpose. Wie Unternehmen Kunden finden, zufriedenstellen & binden
   |Verlag=dpunkt.verlag
   |Ort=Heidelberg
   |Datum=2019
   |ISBN=978-3-86490-579-7
   |Originaltitel=Fit for Purpose. How Modern Businesses Find, Satisfy, & Keep Customers
   |Originalsprache=en}}
* {{Literatur
   |Autor=David J. Anderson, Teodora Bozheva
   |Titel=Kanban Maturity Model. So werden Unternehmen Fit for Purpose
   |Verlag=dpunkt.verlag
   |Ort=Heidelberg
   |Datum=2021
   |ISBN=978-3-86490-608-4
   |Originaltitel=Kanban Maturity Model. A Map to Organizational Agility, Resilience, and Reinvention
   |Originalsprache=en}}
* {{Literatur
   |Autor=Susanne Bartel
   |Titel=Kanban - kurz & gut
   |Verlag=O’Reilly
   |Ort=Heidelberg
   |Datum=2023
   |ISBN=978-3-96009-178-3}}
* {{Literatur
   |Autor=David J. Anderson
   |Titel=Kanban. Der evolutionäre Weg zu agilen Organisationen
   |Verlag=dpunkt.Verlag
   |Ort=Heidelberg
   |Datum=2024
   |ISBN=978-3-86490-986-3
   |Originaltitel=Discovering Kanban. The Evolutionary Path to Enterprise Agility
   |Originalsprache=en}}
englisch:
* {{Literatur
   |Autor=Donald G. Reinertsen
   |Titel=The Principles of Product Development Flow: Second Generation Lean Product Development
   |Verlag=Celeritas Publishing
   |Ort=Redondo Beach CA
   |Datum=2009
   |ISBN=978-1-935401-00-1}}
* {{Literatur
   |Autor=Preston G. Smith, Donald G. Reinertsen
   |Titel=Developing Products in Half the Time. New Rules, New Tools
   |Verlag=Van Nostrand Reinhold
   |Ort=New York
   |Datum=1998
   |ISBN=0-442-02548-3}}
* {{Literatur
   |Autor=Corey Ladas
   |Titel=Scrumban – Essays on Kanban Systems for Lean Software Development
   |Verlag=Modus Cooperandi Press
   |Ort=Seattle
   |Datum=2008
   |ISBN=978-0-578-00214-9}}

== Weblinks ==
* [https://www.orghandbuch.de/Webs/OHB/DE/OrganisationshandbuchNEU/4_MethodenUndTechniken/Methoden_A_bis_Z/Kanban/Kanban_node.html Organisationshandbuch Kanban], [[Bundesministerium des Innern]]
* [https://www.heise.de/developer/artikel/Kriterien-fuer-eine-Entscheidung-fuer-Scrum-oder-Kanban-1071172.html Kriterien für eine Entscheidung für Scrum oder Kanban], [[Heise Online]], 2. September 2010

== Einzelnachweise ==
<references />

{{Normdaten|TYP=s|GND=7734112-0}}

[[Kategorie:Agile Softwareentwicklung]]
[[Kategorie:Vorgehensmodell (Software)]]