# 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.

Source: https://priortasks.com/de/guides/kanban-scrum-or-scrumban/
Last updated: 2026-11-05

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](https://scrumguides.org/scrum-guide.html) 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](https://www.scrum.org/resources/kanban-guide-scrum-teams) für Teams, die Flusspraktiken in Scrum einbringen wollen.

## Wie sie sich unterscheiden

| | Kanban | Scrum | Scrumban |
| --- | --- | --- | --- |
| Rhythmus | Fortlaufend | Feste Sprints | Board plus regelmäßiges Review |
| Planung | Wenn Platz ist | Zu Beginn eines Sprints | Oft, wenn das Board leer läuft |
| Änderung mitten drin | Jederzeit | Begrenzt durch das Sprintziel | Meist flexibel |
| Rollen | Keine nötig | Product Owner, Scrum Master, Developer | Nach Wahl |
| Schätzungen | Optional | Üblich, oft Story Points | Optional |
| Wichtigste Regel | Arbeit in Bearbeitung begrenzen | Sich auf ein Sprintziel festlegen | Beides |

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.

1. **Wie kommt die Arbeit herein?** Ist sie unvorhersehbar, etwa Supportanfragen, Fehler oder dringende Bitten, passt ein fortlaufendes Board. Kannst du ein paar Wochen im Voraus planen, passen Sprints.
2. **Kann das Team sich für eine Zeit auf ein Ziel festlegen?** Wenn jemand die Prioritäten jeden Tag ändern kann, ist ein Sprint schwer zu schützen. Wähle dann Kanban.
3. **Willst du eine regelmäßige Pause für den Rückblick?** Scrum baut sie ein. Bei Kanban fügst du sie selbst hinzu.

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.

| Typ | Was du bekommst | Tarif |
| --- | --- | --- |
| Standard | Aufgaben und Notizen mit Status und Prioritäten | Kostenlos |
| Agil · Kanban | Ein Backlog und ein Board, auf dem die Arbeit durch Spalten wandert | Kostenlos |
| Agil · Scrum | Sprints, Story Points und Planning Poker für das Team | Pro |
| Agil · Scrumban | Ein fortlaufendes Board mit Story Points und Planning Poker | Pro |

> [!pro] Scrum und Scrumban brauchen Pro im Tarif des Inhabers
> Ohne Pro arbeitet ein Scrum- oder Scrumban-Projekt wie ein Kanban-Projekt. Seine Punkte, Sprints und Einstellungen bleiben gespeichert und kommen zurück, sobald der Inhaber Pro hat. Die Personen, die du einlädst, brauchen kein Pro. Siehe [Tarife und Preise](https://priortasks.com/de/docs/account/plans-and-pricing/).

- **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](https://priortasks.com/de/docs/agile/agile-projects/) und [Kanban, Scrum und Scrumban](https://priortasks.com/de/docs/agile/kanban-scrum-scrumban/). Zum Schätzen siehe [Story Points](https://priortasks.com/de/guides/story-points/) und [Planning Poker](https://priortasks.com/de/guides/planning-poker/).