Kanban und Scrum Boards werden normalerweise mit Whiteboards und den Kategorien “To Do – In Progress – Done” in Verbindung gebracht. Aber wie unterscheidet man das eine vom anderen? In diesem Artikel haben wir 11 Punkte gesammelt, die die wichtigsten Unterschiede zwischen Kanban und Scrum Boards zeigen.
Scrum Board vs. Kanban: Grundlegende Definitionen
Sowohl Scrum als auch Kanban Boards verwenden die Agile Methodik, um den Projektstatus von der Idee bis zur Fertigstellung zu verfolgen: Festlegung konkreter Ziele, Delegierung von Aufgaben und Planung des Arbeitsablaufs.
Scrum Boards sind methodischer, erfordern jedoch mehr Vorbereitungszeit und Organisation. Kanban Boards geben Teammitgliedern mehr Spielraum, bieten jedoch nicht das gleiche Maß an organisatorischer Struktur. Welche Projektmanagement-Methode ist also am besten für Sie geeignet?
Wir werden uns gleich eingehend mit dem Vergleich von Kanban vs. Scrum Boards befassen, aber lassen Sie uns zunächst die Grundlagen für die Diskussion legen und dies aus Sicht der Softwareentwicklung betrachten. Hier ist ein sehr gut gemachtes Video, das den Grundstein für unsere Diskussion in diesem Artikel legen wird.
Kanban vs. Scrum im direkten Vergleich
In Miro können Sie jeder Kategorie eine vorausgewählte Farbe, Form oder Beschriftung zuweisen.
Was ist ein Kanban Board?
Das Kanban Board ist ein Board, das den Prozessfluss verfolgt und gleichzeitig die Anzahl der Work-in-Progress-Aktivitäten beibehält. Die Anzahl der Work-in-Progress ist klein genug, um unwürdige Aufgaben zu vermeiden, aber groß genug, um ungenutzte Ressourcen zu reduzieren. Kanban ist wie ein Basketballspiel, bei dem eine abgeschlossene Aufgabe einen Punkt darstellt und ein Team versucht, die Zeit zwischen den Würfen zu minimieren.
Lassen Sie uns genauer hinschauen und die Unterschiede im Detail betrachten.
Was ist ein Scrum Board?
Ein Scrum Board ist ein Aufgabenboard, das die Arbeit in Sprints verfolgt. Ein Sprint ist ein kurzer, konstanter und wiederholender Zeitraum. Die Länge des Sprints ist kurz genug, um das Team konzentriert zu halten, aber lang genug, um ein versandfertiges Arbeitsergebnis zu liefern. Das Scrum Board zu erstellen ist wie das Lernen für eine Prüfung: Es ist ein Werkzeug zur Sprintplanung, mit dem Sie herausfinden können, was getan werden muss, und Ihr Team und Ihren Zeitplan organisieren können.
11 entscheidende Unterschiede zwischen Scrum und Kanban Boards
1. Begrenzung der Work-in-Progress
Scrum begrenzt die Arbeit in Progress pro Iteration. Das Entwicklungsteam muss sich darauf verpflichten, die Anzahl der Aufgaben festzulegen, die sie während des Sprints erledigen können. Es gibt nichts, was uns daran hindert, alle Aufgaben gleichzeitig im In-Progress-Bereich zu haben.
Kanban begrenzt die Arbeit in Progress pro Workflow-Zustand. Zum Beispiel bedeutet die Zahl fünf im rosa Bereich, dass sich nicht mehr als 5 Aufgaben im In-Progress-Bereich befinden sollten.
2. Kanban vs. Scrum Board: Eigentümer
Das Scrum Board gehört immer einem Scrum-Team (und wird in der Regel von einem Scrum Master geleitet). Ein Scrum-Team ist eine multidisziplinäre Gruppe von Mitarbeitern, deren Hintergrund alle für die erfolgreiche Erledigung aller Aufgaben während dieses Sprints erforderlichen Fähigkeiten umfasst.
Das Kanban Board muss nicht einem bestimmten Team gehören, da es hauptsächlich einem Arbeitsablauf gewidmet ist.
3. Rechte zur Änderung des Product Owners
Ein Product Owner kann das Scrum Board nicht bearbeiten, wenn das Team sich auf eine bestimmte Anzahl von Aufgaben für den Sprint festgelegt hat. Obwohl das Scrum Board für alle Interessierten sichtbar ist, darf es nur vom Scrum-Team (Board-Eigentümer) bearbeitet werden.
Kanban kann vom Product Owner bearbeitet werden. Laut dem Essential Kanban Condensed Guide gibt es in Kanban zwei “Hüte”, die die Teammitglieder tragen können: Service Request Manager und Service Delivery Manager. Der “Hut” des Service Request Managers ist eine Alternative zum Product Owner.
4. Aufgabenhingabe
Auf dem Scrum Board ist das gesamte Team für jede Aufgabe verantwortlich.
Beim Kanban ist ein Team ursprünglich nicht für alle Aufgaben verantwortlich. Jede Person ist für ihren eigenen Schritt im Aufgabenfluss (Codierung, Testen, Überprüfen usw.) verantwortlich. Allerdings gibt es im Kanban-Kontext eine Kultur der “slack resources” (Reservekapazitäten), die bei Bedarf bei Engpässen helfen sollen. “Slack resources” sind alle nicht-engpassbezogenen Ressourcen. Wenn eine Person ihre Aufgabe abgeschlossen hat und es beim Testen etwas Kompliziertes gibt, kann sie entscheiden, was zu tun ist: dem Tester helfen, die Aufgabe abzuschließen, oder eine andere Aktivität aus der Warteschlange wählen.
5. Aktualisierungen innerhalb der Iterationen
Das Scrum-Team darf während des Sprints keine neuen Aufgaben zum Board hinzufügen. Die Anzahl der Aufgaben wird während der Planungssitzung vor Beginn der Iteration festgelegt.
Es gibt keine festgelegten Zeitrahmen für die Aktualisierung eines Kanban Boards (das Team schätzt den Fluss mithilfe von historischen Daten ein), da dies die Arbeit-in-Progress-Aktivitäten begrenzt. Sobald eine Aufgabe aus dem In-Progress-Bereich in den Abschnitt “Erledigt” verschoben wird und die Kapazität freigegeben wird, wird das neue Element in der Entwicklung bearbeitet.
6. Dringlichkeit
Dank vorheriger analytischer, planerischer, Dimensionierung und Priorisierungssitzungen wird ein Scrum-Team selten mit unerwarteten Dringlichkeiten konfrontiert. Eines der Hauptziele dieser Methodik besteht darin, das Produkt anpassungsfähig und das Team vorausschauend zu machen.
Einige Teams fügen dem Kanban-Board einen Dringlichkeitsbereich hinzu, der als Schwimmbahn dargestellt wird und maximale Geschwindigkeit erreichen soll. Es kann eine unvorhergesehene dringende Aufgabe aus dem Backlog oder eine Engpassaufgabe aus dem Board sein. In diesem Fall haben Dringlichkeitsaufgaben Vorrang für das Team, sodass einige Teammitglieder geschickt werden sollten, um sie schneller zu erledigen.
7. Backlog
Auf dem Scrum-Taskboard verschiebt das Team Elemente vom Produkt-Backlog zum Sprint-Backlog, das die Liste der Elemente enthält, die sie sich verpflichtet haben, in einem festgelegten Zeitraum zu erstellen.
Scrum verwendet User Stories als bewährte Methode, um große Elemente aus dem Produkt-Backlog in das Sprint-Backlog zu zerlegen. Laut dem Agilen Leitfaden sollten Features und Aufgaben mit Details wie Akzeptanztests, UI-Skizzen usw. versehen werden.
Kanban verwendet ebenfalls eine Backlog-Praxis, die im Allgemeinen (aber nicht notwendigerweise) mit einer User Story gleichgesetzt wird.
8. Vom Backlog zum To-Do-Bereich
Wenn das Scrum-Team sich zu Aufgaben verpflichtet, schätzt es sie als machbar innerhalb des Sprint-Zeitrahmens ein. Wenn die Aufgabe für den Sprint zu groß ist, sollte sie in Schritte aufgeteilt werden, bis jeder Schritt in den Sprint-Zeitrahmen passt.
Ungeachtet der Aufgabenbewegung vom Backlog zum To-Do-Bereich über Vorschläge und den Commitment-Punkt gibt es in Kanban keine spezifische Regel bezüglich des Umfangs der Aufgabe.
9. Priorisierung
In Scrum ist die Priorisierung ein Muss. Sie umfasst in der Regel das Sortieren und Pflegen des Produkt-Backlogs für den aktuellen Sprint, das Festlegen von Prioritäten und die Ressourcenschätzung während der täglichen Scrum-Meetings. Bei der Priorisierung ist es wichtig, vorherzusagen, was für den NÄCHSTEN (nicht den aktuellen) Sprint wichtig sein wird.
Kanban verwendet keine Priorisierungs- oder Schätzmethode, sondern plant das Projekt mithilfe probabilistischer Prognosen.
10. Berichte
Scrum verwendet Velocity als primäre Metrik, begleitet von einer Reihe von Diagrammen und Berichten:
- Sprint Burndown Chart
- Sprint Report
- Epic Burndown
- Epic Report
- Release Burndown
- Velocity Chart
- Version Report usw.
In Kanban sind keine bestimmten Diagramme vorgeschrieben. Es empfiehlt sich jedoch, die folgenden Berichte an das Kanban Board zu heften, da die primäre Metrik hier die Durchlaufzeit ist: Das Control Chart misst die Zykluszeit für Probleme, und das Cumulative Flow Diagram zeigt die verschiedenen Status von Arbeitsobjekten für einen bestimmten Zeitraum an.
11. Zurücksetzen von Perioden
Im Scrum sollten alle Aufkleber am Ende jedes Sprints im Abschnitt “Erledigt” sein, sonst gilt der Sprint als erfolglos. Nach der Sprint-Retrospektive werden alle Aufkleber entfernt, um das Board für den nächsten Sprint zu leeren. Der Prozess des Zurücksetzens des Boards kann ein schönes Gefühl der Erfüllung und des Abschlusses vermitteln.
Kanban ist ein dauerhaftes Werkzeug ohne Zeitrahmen, daher ist es nicht erforderlich, es zurückzusetzen und neu zu starten. Der Arbeitsablauf setzt sich mit dem Projektlebenszyklus fort, und neue Elemente (Aufkleber) werden hinzugefügt, sobald der Bedarf besteht.
Ergänzung
Alle Bilder für diesen Artikel stammen von der in Miro erstellten Karte.
Wie Sie sehen können, sind sowohl Kanban als auch Scrum Boards nicht isoliert. Es ist sehr nützlich, den gesamten Prozess zur Erstellung und Aktualisierung der beiden beliebtesten visuellen Management-Tools auf einer Seite zu haben.
Außerdem möchte ich daran erinnern, dass dieser Artikel nicht darauf abzielt, festzulegen, welches Tool besser ist, da es keinen Wettbewerb zwischen ihnen gibt. Viele Trainer empfehlen, herauszufinden, was für Ihr spezifisches Team am besten funktioniert, um ein individualisiertes Scrumban (Scrum + Kanban) zu implementieren und bessere Ergebnisse zu erzielen.
Virtuelle Boards bieten einen erheblichen Vorteil gegenüber physischen Boards. Wenn Sie Miro für die Agile Planung mit Ihrem Remote-Team ausprobieren möchten, sollten Sie Folgendes beachten:
- Vorbereitete visuelle Planungsvorlagen
- Unsere Fallstudie mit Fokus auf Story Sizing in Miro
- Unsere Fallstudie mit guten Beispielen für Retrospektiven
- Ein Artikel, der Agile und Lean, Scrum und Kanban vergleicht
Erfahren Sie mehr über Agile Workflows und was Ihr Team mit Miro erreichen kann.
