Kanban, Scrum oder Scrumban: welche Methode zu deinem Team passt

Drei Wege, die Arbeit eines Teams zu ordnen: ein fortlaufendes Board, feste Sprints oder eine Mischung. Unterschiede, Auswahl und wie Prior jede unterstützt.

5 Min. Lesezeit

Kanban, Scrum und Scrumban sind drei Arten, die Arbeit eines Teams zu ordnen. Kanban bewegt die Arbeit Punkt für Punkt über ein Board. Scrum arbeitet in festen Runden, den Sprints. Scrumban nimmt Teile von beidem. Welche Methode passt, hängt davon ab, wie deine Arbeit hereinkommt und wie viel davon du planen kannst.

#Woher sie kommen

Kanban stammt von Toyota. Taiichi Ohno benutzte Karten, auf Japanisch kanban genannt (ein Schild oder eine Signalkarte), um jedem Schritt einer Fertigungslinie zu sagen, wann mehr hergestellt werden soll. Arbeit wurde gezogen, wenn Platz dafür war, statt in die Linie gedrückt zu werden. David J. Anderson übertrug die Idee in Kanban: Successful Evolutionary Change for Your Technology Business (2010) auf Software und Wissensarbeit. Zwei ihrer Kernpraktiken sind, die Arbeit auf einem Board sichtbar zu machen und zu begrenzen, wie viel gleichzeitig in Arbeit ist.

Scrum wurde von Ken Schwaber und Jeff Sutherland niedergeschrieben. Der aktuelle Scrum Guide ist von November 2020 datiert. Ein Scrum-Team hat einen Product Owner, einen Scrum Master und Developer. Die Arbeit läuft in Sprints von höchstens einem Monat. Jeder Sprint umfasst die Sprint-Planung, das Daily Scrum, das Sprint-Review und die Sprint-Retrospektive. Das Team verpflichtet sich auf ein Sprintziel, und die Developer, die die Arbeit machen, schätzen die Einträge.

Scrumban hat Corey Ladas in seinem Buch Scrumban: Essays on Kanban Systems for Lean Software Development beschrieben. Es gibt keine einheitliche Definition. Eine übliche Form ist ein Board mit Grenzen für die Arbeit in Bearbeitung, dazu ein paar Scrum-Gewohnheiten, etwa ein regelmäßiges Review. Scrum.org veröffentlicht außerdem den Kanban Guide for Scrum Teams für Teams, die Flusspraktiken in Scrum einbringen wollen.

#Wie sie sich unterscheiden

Die Grenzen für die Arbeit in Bearbeitung sind wichtiger, als sie aussehen. Littles Gesetz aus der Warteschlangentheorie besagt: In einem stabilen Prozess ist die durchschnittliche Zeit, die ein Eintrag in Bearbeitung verbringt, gleich der durchschnittlichen Zahl der Einträge in Bearbeitung, geteilt durch die Rate, mit der sie abgeschlossen werden. Bleibt dein Ausstoß gleich und fängst du mehr Einträge an, dauert jeder einzelne länger.

#So wählst du

Stell dir drei Fragen.

Ein paar Beispiele: Ein Supportteam, das Anfragen beantwortet, nimmt Kanban. Ein Produktteam, das alle zwei Wochen ein Funktionspaket ausliefert, nimmt Scrum. Ein kleines Team, das Funktionen baut und außerdem einen Strom von Fehlern bearbeitet, nimmt Scrumban. Eine einzelne Person mit einer Liste von Projekten nimmt Kanban oder einfach eine Liste.

Wechseln ist möglich. Teams starten oft mit einem Board, sehen, was hängt, und ergänzen später Sprints, wenn Planung wichtig wird.

#Fehler, die du vermeiden solltest

• Ein Board ohne Grenzen. Ohne Grenze für die Arbeit in Bearbeitung ist ein Kanban-Board nur eine To-do-Liste in Spalten.
• Sprints ohne Ziel. Ein Sprint, der nur ein Eimer voller Aufgaben ist, verliert den Sinn der Runde.
• Rituale um ihrer selbst willen. Wenn ein Meeting nie eine Entscheidung ändert, kürze es oder streich es.
• Planning Poker für alles. Schätze, was du zum Planen brauchst.
• Velocity oder Burn-Charts nutzen, um Menschen zu beurteilen. Sie dienen der eigenen Planung des Teams.
• Mitten im Sprint die Methode wechseln. Warte auf eine natürliche Pause.

#Wann sie das falsche Werkzeug sind

• Für eine einzelne Person. Eine Liste mit einer klaren nächsten Aktion reicht.
• Wenn die Reihenfolge durch Abhängigkeiten festgelegt ist. Ein Bauplan oder eine Startcheckliste braucht eine Zeitachse, kein Board.
• Wenn die Arbeit ein einziges großes Ergebnis ist. Eine Abschlussarbeit ist kein Fluss von Einträgen.
• Wenn niemand die Prioritäten verantwortet. Scrum braucht jemanden, der entscheidet, was zuerst kommt.

#In Prior

Prior unterstützt alle drei über den Projekttyp eines Projekts. Wähle ihn beim Anlegen oder Bearbeiten eines Projekts.

• Das Board. Agile Projekte haben einen Tab Board neben Tickets, Übersicht, Notizen und Aktivität. Die Spalten folgen den Status des Projekts, und jede zeigt, wie viele Karten sie enthält. Zieh eine Karte in eine andere Spalte, oder öffne ihr Menü und wähle Nach die gewünschte Spalte verschieben. Auf dem Handy stehen die Spalten als Chips über dem Board.
• Kanban. Das Board ist der Mittelpunkt. Prior erzwingt keine Grenzen für die Arbeit in Bearbeitung. Setz dir deshalb selbst ein Limit und schau auf die Zahl oben in jeder Spalte. Alle Aufgaben hat ebenfalls eine Kanban-Ansicht, die nach Status, Priorität, Projekt oder Fälligkeit gruppieren kann.
• Scrum. Die Zyklen werden zu Sprints. Du bekommst einen Sprintfilter auf dem Board und bei den Tickets (Aktiver Sprint, Alle, Backlog), Punktefortschritt und Velocity auf dem Tab Sprints, einen Burn-Chart und den Tab Planning Poker.
• Scrumban. Es behält die Zyklen, ohne Burn-Charts, und ergänzt Story Points. Planning Poker ist über Ansicht hinzufügen verfügbar.
• Wenn du deine Meinung änderst. Wenn du den Typ wechselst, bleiben deine Aufgaben erhalten. Punkte, Sprints und die frühere Einrichtung bleiben gespeichert, sodass ein Zurückwechseln sie wiederherstellt.

Mehr dazu unter Agile Projekte und Kanban, Scrum und Scrumban. Zum Schätzen siehe Story Points und Planning Poker.