Scrum-Leitfaden | 33. Scrumban- und Kanban-Boards in Scrum

Scrum und Kanban sind Teamarbeitsmethoden, die viele Gemeinsamkeiten aufweisen. Allerdings gibt es auch Unterschiede, die wir heute besprechen möchten. Kanban-Boards werden auch oft von Scrum-Teams übernommen. Denn sie sind sehr praktisch, um Teamarbeit und deren Fortschritt zu visualisieren. Durch die Kombination der besten beiden Methoden entstand eine Technik namens Scrumban. Es ist beliebt in Projekten, die Produktentwicklung mit Servicebereitstellung kombinieren, wo lange Sprints und relativ formalisierte Scrum-Meetings nicht immer geeignet sind.

Scrumban und Kanban Boards in Scrum – Inhaltsverzeichnis:

1. Einführung
2. Kanban gegen Scrum
3. Kanban-Boards in Scrum
4. Scrumban
5. Zusammenfassung

Einführung

Kanban ist eine Methode, die in Japan entwickelt wurde. Es entstand in den 1950er Jahren und war in erster Linie ein Werkzeug, um die kontinuierliche Produktion so zu steuern, dass keine Bestände und Überschüsse entstehen, sondern Ressourcen kontinuierlich verarbeitet werden. Im frühen 21. Jahrhundert wurde Kanban von David J. Anderson an die Bedürfnisse der Softwareentwicklung angepasst.

Kanban gegen Scrum

Die allgemeine Arbeitsweise in Kanban unterscheidet sich von Scrum vor allem durch einen weniger formalen Ansatz. In Kanban gibt es nicht so detaillierte Richtlinien zum Beispiel zur Arbeit in Sprints, Rollen des Product Owners, Scrum Masters und des Entwicklungsteams. Dies ist möglich, weil Kanban sich auf die Kontinuität von Aufgaben konzentriert , wie z. B. die Bereitstellung einer bestimmten Art von Service, die wiederholbarer sind und keine so komplexe Planung erfordern.

Zweck und Arbeitsweise sind jedoch ähnlich. Das Ziel von Kanban ist es, dem Kunden das qualitativ hochwertigste Produkt pünktlich zu liefern. Die beiden Methoden gemeinsamen Prinzipien bezüglich der Arbeitsweise lassen sich wie folgt formulieren:

1. Die Arbeit soll reibungslos und ohne Ausfallzeiten ablaufen – in Scrum wird dies durch die kontinuierliche Abfolge von Sprints erreicht, während in Kanban die Arbeit durch den reibungslosen Ablauf von Aufgaben kontinuierlich ist. Sie bilden eine Warteschlange, aus der die Entwickler einige Aufgaben zur Erledigung auswählen (ziehen).
2. Das Team sollte sich nur auf ausgewählte Aufgaben konzentrieren – in der Kanban-Terminologie sollte das Team „work in progress“ reduzieren. In Scrum sind das Äquivalent dazu User Stories, die aus dem Product Backlog ausgewählt und in das Sprint Backlog aufgenommen werden
3. Der Fortschritt von Aufgaben sollte für alle Beteiligten sichtbar sein – in Kanban werden sie durch Boards visualisiert, die auch oft in Scrum-Teams zu finden sind.

Kanban-Boards in Scrum

Ein Kanban-Board ist ein weit verbreitetes Tool zur Visualisierung der Teamarbeit. Es ist eine Tabelle mit mehreren Spalten. In jedem von ihnen gibt es Aufgaben mit einem bestimmten Status. Die Kategorisierung von Aufgaben basiert auf einer einfachen Regel: Eine Karte mit einer Beschreibung der Aufgabe – oder ihres virtuellen Äquivalents – wird in eine der Spalten gelegt. Die Mindestversion von Kanban-Boards enthält drei Spalten:

• Machen
• Im Gange
• Erledigt – in die letzte Spalte gehen die Aufgaben, die der Definition der Erledigung entsprechen, über die wir hier geschrieben haben.

Unten finden Sie ein Beispiel für ein Kanban-Board aus einem All-in-One-Projektmanagementsystem – Firmbee.com

Üblicherweise gibt es mehr Spalten. Wenn weitere Aufgaben zu erledigen sind, gibt es normalerweise eine zusätzliche Spalte mit dem Titel „Zur Fertigstellung ausgewählt“ zwischen den Spalten „ Zu erledigen“ und „In Bearbeitung“ . Während die Spalte „To-do“ als Product Backlog dient, über das wir hier geschrieben haben, dient die Spalte „Zur Fertigstellung ausgewählt“ als Sprint Backlog, das wir in diesem Artikel ausführlich beschreiben.

Der zweite übliche Zusatz ist eine Spalte „wird geprüft“ oder „zur Genehmigung“. Es wird normalerweise zwischen den Spalten mit den „in Bearbeitung“ und den „erledigten“ Aufgaben eingefügt. Es enthält Aufgaben, die vom Entwicklungsteam abgeschlossen wurden und auf die Genehmigung durch den Product Owner warten. Die Aufgabe des Product Owners besteht darin, die Einhaltung der Akzeptanzkriterien zu überprüfen und die endgültige Zustimmung des Kunden einzuholen. In dieser Situation werden nur die endgültig akzeptierten Aufgaben in die letzte Spalte verschoben.

Scrumban

Aufgrund der großen Popularität von Scrum und Kanban erschien ihr Hybrid, der das Beste aus beiden Arbeitsweisen kombiniert. Scrumban funktioniert am besten in Organisationen, die die Erstellung von Produkten mit der Bereitstellung von Dienstleistungen verbinden, was häufig die Implementierung des Produkts beim Kunden beinhaltet. Aufgrund der Reduzierung von Meetings und Kommunikation kann das Team größer sein.

Scrumban legt weniger Wert auf Metriken, die üblicherweise in Scrum verwendet werden, wie z. B. das Burndown-Diagramm. Es nutzt jedoch die Scrum-Säulen der Notwendigkeit, den Arbeitsprozess kontinuierlich zu verbessern und an die Bedingungen und Bedürfnisse des Kunden anzupassen.

Beim Arbeiten in Scrumban wird die Arbeit jedoch nicht in Sprints aufgeteilt. Scrum-Meetings finden alle 3, 6 oder 12 Monate statt.

Die Arbeitseinteilung erfolgt nach dem „On-Demand“-Prinzip, also wie sie anfällt. User Storys werden direkt in der ersten Spalte des Kanban-Boards mit „to-do“-Aufgaben platziert. Es dient somit als Sprint Backlog, über das wir in diesem Artikel ausführlicher geschrieben haben. Wie im Sprint Backlog stehen die dringendsten Aufgaben ganz oben auf der To-Do-Liste. Für komplexere Projekte kann der Projektmanager jedoch eine separate To-Do-Liste führen, die dem Product Backlog entspricht, aus der er auswählt, welche Aufgaben in die erste Spalte gestellt werden.

Beim Verschieben von Aufgaben aus der ersten in die zweite Spalte gilt die „Pull“-Regel . Das bedeutet, dass Aufgaben nicht an einen bestimmten Entwickler delegiert werden. Jede Person wählt eine Aufgabe aus der Warteschlange aus und führt sie selbstständig aus.

Die Anzahl der Aufgaben, die in der mittleren Spalte „zu erledigen“ platziert werden, ist in der Regel je nach Teamgröße begrenzt, sodass möglichst jeder nur eine Aufgabe gleichzeitig bearbeitet.

Zusammenfassung

Scrum und Kanban sind, obwohl sie für ähnliche Zwecke verwendet werden, unterschiedliche Arbeitsweisen. Scrum funktioniert am besten in kreativen, innovativen Projekten, die von kleinen Scrum-Teams durchgeführt werden. Kanban hingegen wurde geschaffen, um in einer kontinuierlichen und ausfallfreien Umgebung zu arbeiten und ähnliche Dienstleistungen zu erbringen. Scrum verwendet häufig Kanban-Boards als Methode, um die geleistete Arbeit zu visualisieren. Die Kombination aus beidem führte zu Scrumban, das am besten als Framework für Organisationen funktioniert, die ihre Produkte verkaufen und darauf basierende Dienstleistungen für den Kunden erbringen.

Wenn Ihnen unsere Inhalte gefallen, werden Sie Teil unserer fleißigen Bienen-Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autorin: Caroline Becker

Als Projektmanagerin ist Caroline Expertin darin, neue Methoden zu finden, um die besten Arbeitsabläufe zu gestalten und Prozesse zu optimieren. Ihre organisatorischen Fähigkeiten und ihre Fähigkeit, unter Zeitdruck zu arbeiten, machen sie zur besten Person, um komplizierte Projekte in die Realität umzusetzen.

Alle Beiträge anzeigen

Scrum-Leitfaden:

1. Glossar der Grundbegriffe, Rollen und Begriffe
2. Was ist Scrum?
3. Scrum-Werte
4. Wie implementieren Sie Scrum in Ihrem Unternehmen?
5. Scrum Team – was ist das und wie funktioniert es?
6. Wer ist ein Product Owner?
7. Die häufigsten Fehler des Product Owners
8. Wer ist der Scrum-Master?
9. Eigenschaften eines guten Scrum Masters
10. Die häufigsten Fehler des Scrum Masters
11. Welche Statistiken und Metriken sollte der Scrum Master verfolgen?
12. Zusammenarbeit zwischen Product Owner und Scrum Master
13. Entwicklungsteam in Scrum
14. Die häufigsten Fehler von Entwicklern
15. Scrum-Artefakte
16. Scrum skalieren
17. Sprint-Rückstand
18. Was ist das Product Backlog?
19. Was sind User Stories?
20. Erstellen Sie die beste User Story mit INVEST
21. Die häufigsten Fehler in User Storys
22. Akzeptanzkriterien für User Storys
23. Schätzung und Story Points in Scrum
24. Planungspoker
25. Team-Schätzspiel
26. Inkrement definieren
27. Scrum-Ereignisse
28. Was ist Sprint in Scrum?
29. Verpflichtungen des Scrum-Teams – Produktziel, Sprintziel und Abschlussdefinition
30. Was ist ein Burndown-Diagramm?
31. Wie erstellt und interpretiert man ein Burndown-Diagramm?
32. Vor- und Nachteile des Burndown-Charts
33. Kanban-Boards in Scrum und Scrumban
34. Velocity in Scrum - Schnelligkeit des Entwicklungsteams
35. Tägliches Scrum
36. Sprint-Planung
37. Sprint-Review
38. Was ist eine Sprint-Retrospektive?
39. Häufige Fehler während einer Sprint-Retrospektive
40. Pflege des Produkt-Backlogs