Wie ein Scrum Board aufgebaut sein muss, damit es im Sprint trägt: Spalten, Karten, WIP-Limits, Definition of Ready und Done, der Rhythmus über alle Events hinweg und die Kennzahlen, die tatsächlich etwas aussagen. Dazu eine klare Trennung zwischen dem, was KI im Refinement heute leistet, und dem, was beim Team bleiben muss.
Das Scrum Board ist das meistgenutzte und zugleich am häufigsten missverstandene Artefakt agiler Arbeit. Es hängt in jedem zweiten Teamraum und ist in jedem Tool vorkonfiguriert. In vielen Organisationen dient es allerdings als Statusanzeige für Führungskräfte statt als Arbeitsinstrument für das Team.
Dieser Artikel beschreibt, wie ein Scrum Board aufgebaut sein muss, damit es im Sprint tatsächlich trägt, welche Kennzahlen sich daraus ableiten lassen, wo KI die Sprintplanung heute entlastet und an welcher Stelle sie im Scrum nichts verloren hat.
Wenn Sie zuerst wissen möchten, wie sich Scrum zu Kanban, Lean oder klassischen Modellen verhält, finden Sie das im Überblick zu den Projektmanagement-Methoden. Für die Steuerungsebene darüber, also Softwareauswahl, Multiprojektmanagement und Einführung, siehe unseren Leitfaden zum agilen Projektmanagement.
Ein Scrum Board ist ein visuelles Werkzeug, das den Inhalt eines Sprints in Spalten darstellt und den Bearbeitungsstand jeder Aufgabe sichtbar macht. Es zeigt das Sprint Backlog eines festen Zeitraums, üblicherweise ein bis vier Wochen, und wandert von links nach rechts: von offen über in Arbeit bis erledigt.
Der Zweck ist nicht Dokumentation, sondern Selbstorganisation. Das Team soll in wenigen Sekunden erkennen können, woran gerade gearbeitet wird, was blockiert ist und ob das Sprint-Ziel noch erreichbar erscheint. Sobald das Board primär dazu dient, Dritte zu informieren, verändert sich sein Inhalt, und zwar immer in Richtung der besseren Optik.
Ein Punkt, den fast alle Tool-Anbieter auslassen: Das Scrum Board ist kein Bestandteil des Scrum-Frameworks. Der Scrum Guide kennt drei Artefakte, nämlich Product Backlog, Sprint Backlog und Increment. Das Board gehört nicht dazu. Es ist ein Werkzeug, das viele Teams wählen, um ihr Sprint Backlog sichtbar zu machen.
Das ist keine Haarspalterei, sondern hat drei praktische Folgen. Erstens ist die Spaltenstruktur frei. Es gibt keine vorgeschriebenen Spalten, und wer "To Do, In Progress, Done" für gesetzt hält, übernimmt eine Konvention, keine Regel. Zweitens entscheidet das Team. Ein Scrum Team ist selbstorganisiert, und wenn ein anderes Format besser funktioniert, ist das kein Regelverstoß. Drittens darf sich das Board verändern. Retrospektiven dürfen die Struktur anpassen.
Gerade der dritte Punkt wird in vielen Organisationen faktisch verhindert, weil Boards zentral administriert werden und Änderungen ein Ticket beim internen Tool-Team erfordern. Das ist ein stiller, aber wirksamer Verstoß gegen die Selbstorganisation.
Beide Boards sehen ähnlich aus und funktionieren grundlegend verschieden. Diese Verwechslung ist die Ursache vieler frustrierter Teams.
Das Scrum Board bildet einen fest umrissenen Sprint ab, meist ein bis vier Wochen. Es enthält ausschließlich das Sprint Backlog des laufenden Zyklus und wird zu jedem Sprintstart neu befüllt. Der Umfang bleibt innerhalb des Sprints stabil, gesteuert wird über Sprint-Ziel und Sprint-Umfang, gemessen über Velocity und Sprint-Zielerreichung. Es passt zu Produktentwicklung mit planbaren Zyklen.
Das Kanban Board bildet dagegen einen kontinuierlichen Fluss ohne Zeitboxen ab. Es zeigt alle laufenden Arbeitsschritte, läuft dauerhaft weiter und wird über WIP-Limits pro Spalte gesteuert. Prioritäten dürfen jederzeit angepasst werden, gemessen wird über Durchlaufzeit und Durchsatz. Es passt zu Betrieb, Support und allen Bereichen mit unregelmäßigem Zulauf.
Die praktische Konsequenz: Ein Team mit hohem, unvorhersehbarem Zulauf, etwa aus Support, Wartung oder kurzfristigen Vertriebsanfragen, wird mit einem Scrum Board dauerhaft unglücklich, weil der Sprint ständig aufgebrochen wird. Dort ist Kanban die ehrlichere Wahl. Viele Teams kombinieren beides: Scrum für die Entwicklungsarbeit, ein separater Kanban-Fluss für Unvorhergesehenes.
Die Minimalstruktur umfasst drei Spalten. Zu erledigen enthält alles, was im Sprint eingeplant, aber noch nicht begonnen ist. Der häufigste Fehler besteht darin, diese Spalte als allgemeine Ablage zu missbrauchen. In Bearbeitung enthält, woran aktiv gearbeitet wird und wofür jemand zuständig ist. Enthält sie mehr Karten als das Team Personen hat, ist das Board bereits aus dem Gleichgewicht. Erledigt enthält ausschließlich, was die Definition of Done erfüllt. "Erledigt bis auf die Tests" ist nicht erledigt.
Das Sprint Backlog wird im Sprint Planning zusammengestellt und liegt zu Beginn vollständig in der ersten Spalte. Nach dem Pull-Prinzip ziehen sich die Teammitglieder Aufgaben anschließend selbst. Aufgaben werden nicht zugewiesen. Dieser Unterschied entscheidet darüber, ob Mitverantwortung entsteht oder nicht.
Ab einer gewissen Teamgröße lohnen sich zusätzliche Spalten, sofern jede einen echten Zustandswechsel abbildet. Eine Spalte Blockiert ist sinnvoll, wenn externe Abhängigkeiten regelmäßig auftreten. Sie braucht kein Limit, aber einen Tageszähler, damit Wartezeit sichtbar wird. Eine Spalte In Review lohnt sich, wenn das Vier-Augen-Prinzip verbindlich gilt, dann mit einem engen Limit, damit Reviews nicht liegen bleiben. Eine Test- oder QA-Spalte ist angebracht, wenn Testen eine eigene Kompetenz im Team ist. Und eine Spalte Bereit zur Abnahme hilft, wenn die fachliche Freigabe außerhalb des Teams erfolgt.
WIP-Limits, also Obergrenzen für gleichzeitig laufende Arbeit, sind der wirksamste einzelne Hebel für die Durchlaufzeit. Ein Team von sechs Personen mit vierzehn gleichzeitig offenen Karten liefert nicht mehr, sondern weniger. Jeder Kontextwechsel kostet Zeit, und nichts wird fertig. Als Faustregel gilt maximal eine aktive Karte pro Person plus ein kleiner Puffer.
Zusätzlich helfen Swimlanes, also horizontale Bahnen, die das Board nach Kategorie unterteilen, etwa nach Feature, Team, Epic oder Dringlichkeit. Eine eigene Bahn für echte Notfälle verhindert, dass Dringendes den normalen Fluss unterläuft und dabei unsichtbar bleibt.
Eine Karte, die im Daily erklärt werden muss, ist keine gute Karte. Diese Elemente reichen in nahezu allen Fällen aus:
Nicht auf die Karte gehören der komplette Diskussionsverlauf, Statusberichte für Dritte und Aufgaben, die kein eigenständiges Ergebnis erzeugen.
Zwei Vereinbarungen entscheiden über die Qualität eines Boards. Beide sind kein Formalismus, sondern Schutzmechanismen.
Die Definition of Ready beantwortet, wann eine Karte überhaupt in einen Sprint darf: Das Ergebnis ist beschrieben und verstanden, Akzeptanzkriterien liegen vor, die Karte ist geschätzt, bekannte Abhängigkeiten sind geklärt und die Arbeit ist innerhalb eines Sprints erledigbar. Fehlt diese Vereinbarung, landet unklare Arbeit im Sprint und blockiert ihn von innen.
Die Definition of Done beantwortet, wann eine Karte wirklich fertig ist: Akzeptanzkriterien erfüllt, Review durchgeführt, getestet, dokumentiert im vereinbarten Umfang, ausgeliefert oder auslieferbar. Fehlt sie, sammelt sich in der letzten Spalte Arbeit, die nicht fertig ist, und die Velocity wird zur Fiktion.
Schritt acht wird am häufigsten übersprungen, und er ist der Grund, warum ein Board dem Management oft nichts sagt.
Ein Scrum Board wirkt nur im Zusammenspiel mit den Events. Jedes Event hat eine andere Beziehung zum Board.
Hier entsteht das Board. Das Team zieht Einträge aus dem Product Backlog in den Sprint, formuliert ein Sprint-Ziel und stellt sicher, dass die eingeplante Menge zur verfügbaren Kapazität passt, abzüglich Urlaub, Bereitschaft und Meetings. Ein übersprungenes oder überhastetes Planning ist eine der häufigsten Ursachen für gescheiterte Sprints, weil sich die fehlende Klärung über den gesamten Zyklus verteilt.
Fünfzehn Minuten, am Board. Die produktive Variante arbeitet sich nicht Person für Person durch die Frage, was jeder gestern getan hat. Sie geht Karte für Karte von rechts nach links vor: Was ist kurz vor fertig und braucht Unterstützung? Diese Reihenfolge lenkt die Aufmerksamkeit auf Fertigstellung statt auf Beschäftigung und verkürzt das Daily nebenbei erheblich.
Kein offizielles Event mit fester Zeitbox, aber unverzichtbar. Hier werden kommende Einträge geklärt, geschnitten und geschätzt, damit sie die Definition of Ready erreichen. Refinement bereitet die Zutaten vor, das Planning kocht. Wer Refinement auslässt, verlagert die Klärung ins Planning und verdoppelt dessen Dauer.
Das Board zeigt, was fertig geworden ist. Wichtig ist die Haltung: Das Review ist ein Arbeitsgespräch mit Stakeholdern über das Ergebnis, keine Statuspräsentation. Der wertvolle Teil sind die Rückmeldungen, die anschließend ins Product Backlog zurückfließen.
Die einzige Gelegenheit, das Board selbst zu verändern. Typische Erkenntnisse: Eine Spalte fehlt, ein WIP-Limit ist zu hoch angesetzt, die Definition of Done wird regelmäßig umgangen. Bewährt hat sich eine beschlossene Änderung pro Retrospektive. Mehr wird erfahrungsgemäß nicht umgesetzt. Warum regelmäßige Rückschau auch auf Zielebene den Unterschied macht, zeigt unser Beitrag zum OKR-Check-in.
Die bekannteste Kennzahl ist die Velocity, also die durchschnittlich abgeschlossenen Story Points pro Sprint. Sie ist eine Planungsgröße für ein einzelnes Team, keine Leistungskennzahl. Sobald sie als Ziel gesetzt wird, steigt sie zuverlässig, allerdings durch großzügigere Schätzungen. Story Points sind zudem teamspezifisch und zwischen Teams grundsätzlich nicht vergleichbar.
Der Sprint-Burndown zeigt die verbleibende Arbeit im laufenden Sprint. Als Frühwarnsystem wird er meist überschätzt, weil er Probleme erst anzeigt, wenn wenig Handlungsspielraum bleibt. Deutlich aussagekräftiger ist die Sprint-Zielerreichung, also der Anteil der Sprints, in denen das gesetzte Ziel erreicht wurde. Sie beantwortet die Frage, ob ein Team verlässlich zusagt. In der Praxis wird sie erstaunlich selten überhaupt erhoben.
Die Durchlaufzeit misst, wie lange eine Karte von "in Arbeit" bis "erledigt" braucht. Sie ist die ehrlichste Kennzahl am Board, weil sie sich nicht durch Schätzverhalten manipulieren lässt. Ergänzend lohnt sich die Blockierdauer, also die Zeit, die Karten wartend verbringen, sowie die Zahl der ungeplanten Einschübe, die in fast jeder Organisation beklagt und in fast keiner gezählt wird.
Für die Steuerung gilt damit: Sprint-Zielerreichung und Durchlaufzeit gehören nach oben, Velocity bleibt im Team. Wie ein Führungsrhythmus aussieht, der diese Werte regelmäßig aufgreift, ohne das Team zu unterbrechen, beschreibt unser Beitrag zum wöchentlichen Führungsrhythmus. Die grundsätzliche Unterscheidung zwischen steuernden und messenden Kennzahlen behandeln wir in OKR vs. KPI.
Der Begriff Scrum Management wird uneinheitlich benutzt. Gemeint ist meist die Steuerungsebene um das Board herum: Rollen, Verantwortlichkeiten, Skalierung und die Verbindung zum Rest der Organisation.
Das Scrum-Framework kennt drei Verantwortlichkeiten. Der Product Owner verantwortet Wert und Reihenfolge des Product Backlog, aber nicht, wie das Team arbeitet. Der Scrum Master verantwortet die Wirksamkeit von Scrum und die Beseitigung von Hindernissen, aber weder Aufgabenverteilung noch Statusberichte. Die Developers, also alle, die zur Erstellung des Ergebnisses beitragen, verantworten das Wie, die Qualität und die Schätzung, aber nicht die Priorisierung des Product Backlog.
Die häufigste Rollenverwechslung in der Praxis: Der Scrum Master wird als Projektleitung eingesetzt und verteilt Aufgaben. Damit ist die Selbstorganisation beendet, und das Board wird vom Arbeitsinstrument zum Zuteilungswerkzeug. Wie sich Verantwortung ohne Aufgabenzuweisung vereinbaren lässt, zeigt der Vergleich Zielvereinbarung: OKR und MBO im Vergleich.
Ab dem zweiten Team an einem Produkt stellen sich drei Fragen, die ein einzelnes Board nicht beantwortet.
Erstens: ein Backlog oder mehrere? Bei einem gemeinsamen Produkt gilt ein Product Backlog und ein Product Owner. Mehrere Backlogs erzeugen Priorisierungskonflikte, die anschließend niemand entscheidet. Zweitens: Wie werden Abhängigkeiten sichtbar? Karten, die auf ein anderes Team warten, gehören markiert und aggregiert, sonst verschwindet die Wartezeit in beiden Boards gleichzeitig. Drittens: Wer entscheidet über Teamgrenzen hinweg? Skalierungsansätze wie SAFe, Scrum@Scale oder Scrum of Scrums beantworten das unterschiedlich, gemeinsam ist ihnen eine Entscheidungsebene oberhalb des Team-Boards.
Ab dieser Ebene wird Portfolio- und Multiprojektsteuerung relevant, inklusive Ressourcenkonflikten und Priorisierung bei begrenzter Kapazität. Beides behandeln wir ausführlich im Leitfaden zum agilen Projektmanagement.
Nahezu jedes Scrum-Tool bewirbt inzwischen KI-Funktionen. Nützlich ist die Unterscheidung zwischen dem, was heute belastbar funktioniert, und dem, was Ankündigung bleibt.
Das ist der reifste Anwendungsfall. Aus einer groben Feature-Beschreibung erzeugen Sprachmodelle Story-Entwürfe mit Akzeptanzkriterien und prüfen bestehende Einträge gegen die INVEST-Kriterien: unabhängig, verhandelbar, wertvoll, schätzbar, klein, testbar.
Der Nutzen zeigt sich vor allem bei vagen Tickets, also jenen Einträgen, die aus einem Halbsatz bestehen und deren Bedeutung nur die Person kennt, die sie angelegt hat. Ein Modell kann daraus einen strukturierten Entwurf machen, der im Refinement diskutierbar ist. Der eigentliche Gewinn liegt dabei weniger in der eingesparten Schreibzeit als in der Qualität der Akzeptanzkriterien. Je klarer sie formuliert sind, desto weniger Nacharbeit entsteht mitten im Sprint. Weniger Überraschungen sind wertvoller als schnelleres Refinement.
KI kann aus historischen Sprint-Daten wie vergangenen Story-Größen, tatsächlichen Fertigstellungszeiten und der Team-Velocity kalibrierte Schätzvorschläge ableiten. Der Nutzen liegt nicht in der Zahl selbst, sondern im Startpunkt: Schätzdiskussionen beginnen nicht mehr bei null, was ihre Dauer spürbar verkürzt.
Für die Priorisierung gilt das ausdrücklich nicht. Ein Modell kann Signale zusammentragen, etwa Kundenanfragen, Umsatzbezug und Abhängigkeiten. Die Abwägung zwischen konkurrierenden Zielen ist jedoch eine Entscheidung mit Verantwortung. Sie gehört zum Product Owner und lässt sich nicht delegieren.
Der unterschätzte Anwendungsfall. KI erkennt zuverlässig doppelte oder überlappende Einträge, Karten ohne Akzeptanzkriterien, Einträge, die seit Monaten nicht angefasst wurden, Karten, die ungewöhnlich lange in einer Spalte liegen, sowie Muster, die auf Verzögerung hindeuten, bevor der Burndown es zeigt.
Gerade das systematische Ausmisten geringwertiger Einträge wird unterschätzt. Ein aufgeräumtes Backlog ist keine Kosmetik, sondern die Voraussetzung dafür, dass Priorisierung überhaupt möglich ist. In einer Liste mit mehreren hundert Einträgen priorisiert niemand, er sucht.
Beim Schreiben einer Story liefert KI Entwurf, Struktur und Akzeptanzkriterien. Fachliche Richtigkeit und Nutzerverständnis bleiben beim Team. Beim Schneiden einer zu großen Story liefert sie Vorschläge nach Workflow-Schritt oder Datenvariante. Die Entscheidung über den Schnitt trifft das Team. Beim Schätzen liefert sie einen kalibrierten Ausgangswert. Das gemeinsame Verständnis entsteht weiterhin im Gespräch.
Beim Refinement übernimmt KI Vorarbeit und Qualitätsprüfung, das Gespräch selbst bleibt. Im Daily kann sie zusammenfassen und Auffälligkeiten markieren, Absprachen und Zusagen entstehen zwischen Menschen. Im Review kann sie das Gelieferte zusammenstellen, die Bewertung nehmen Stakeholder vor. In der Retrospektive kann sie Daten aufbereiten und Muster erkennen. Offenheit, Vertrauen und Beschlüsse entstehen im Raum.
Der Wert des Refinements entsteht im Gespräch, nicht im Dokument. Wenn KI vollständige Stories liefert und das Team sie nur noch abnickt, ist die Vorarbeit automatisiert und das gemeinsame Verständnis verloren, also der Teil, der Sprints trägt.
Drei Leitplanken haben sich bewährt. Erstens: KI-Output ist Entwurf, nie Ergebnis. Jede generierte Story durchläuft ein menschliches Review. Zweitens: Retrospektiven bleiben in der Bewertung KI-frei. Datenaufbereitung ja, Deutung nein, weil psychologische Sicherheit nicht in einem generierten Bericht entsteht. Drittens: Kontextqualität bestimmt Ausgabequalität. Ein Prompt mit nur dem Story-Text erzeugt generische Ergebnisse, erst mit Datenmodell, verwandten Stories und Architekturkontext entstehen Hinweise, auf die man handeln kann.
Der zehnte Fehler ist der teuerste, weil er unsichtbar bleibt: Sämtliche Board-Kennzahlen können gut aussehen, während sich am Geschäftsergebnis nichts ändert. Die verwandten Muster auf Zielebene haben wir in Häufige Fehler bei OKRs gesammelt.
Entwicklungsnahe Suiten wie Jira oder Azure DevOps bieten die tiefste Sprint-Mechanik und die beste Anbindung an Code und Deployment. Sie spielen ihre Stärke dort aus, wo ein Entwicklungsanteil vorhanden ist. Für Teams ohne technischen Bezug ist der Funktionsumfang meist größer als der Bedarf, und die Einrichtung bindet entsprechend Zeit.
Work-Management-Plattformen wie monday, Asana oder ClickUp lassen sich schneller einführen und funktionieren auch für gemischte Teams ohne einheitlichen fachlichen Hintergrund. Bei komplexen Abhängigkeiten und Auswertungen über mehrere Boards hinweg sind spezialisierte Systeme im Vorteil.
Kollaborationsflächen wie Miro oder Mural sind für Refinement, Story Mapping und Workshops gebaut. Sie sind Denkraum, nicht führendes System. Sie halten einen Arbeitsstand als Momentaufnahme fest, nicht als nachvollziehbare Historie.
Ziel- und Strategie-Layer wie Fasan schließen die Ebene darüber: die Verbindung zwischen Sprint-Ergebnis und Unternehmensziel. Sie ersetzen kein Board und keinen Ticket-Tracker.
Ein Muster fällt beim Blick in die Praxis besonders auf. Viele Scrum-Teams pflegen parallel zu ihrem Board weiterhin Tabellen. Das ist selten Bequemlichkeit, sondern meist der Versuch, eine Sicht herzustellen, die das Board nicht liefert, nämlich die Ebene oberhalb des Sprints. Wo genau die Grenze einer Tabelle verläuft, zeigt der Vergleich OKR-Software vs. Excel. Wie eine strukturierte Auswahlentscheidung abläuft, beschreibt OKR-Software auswählen: Worauf es ankommt.
Ein gut geführtes Scrum Board beantwortet die Frage, woran ein Team gerade arbeitet, perfekt. Die Frage, warum diese Arbeit wichtiger ist als alles andere, beantwortet es überhaupt nicht. Das ist keine Schwäche des Boards, sondern eine Frage der falschen Ebene.
Die Verbindung entsteht über eine durchgängige Zielkette. Ganz oben steht die Strategie mit einem Horizont von mehreren Jahren, etwa die Position im Mittelstandssegment auszubauen. Darunter liegt das Objective für das Quartal, etwa das Onboarding-Erlebnis deutlich zu verbessern. Auf der nächsten Ebene macht ein Key Result das messbar, etwa indem die Zeit bis zur ersten produktiven Nutzung deutlich verkürzt wird. Dieser Wert wird wöchentlich aktualisiert. Darunter liegt das Sprint-Ziel, etwa die Self-Service-Einrichtung ohne Support nutzbar zu machen. Und ganz unten liegt die einzelne Karte: Nutzer kann Testdaten selbst importieren.
Erst wenn diese Kette existiert, wird ein Sprint-Ergebnis für die Geschäftsführung interpretierbar, und umgekehrt wird ein Unternehmensziel für das Team handlungsleitend. Wie eine solche Zielhierarchie entsteht, beschreiben wir in Strategische Ziele entwickeln und praxisnah in OKR-Einführung in Unternehmen.
An dieser Stelle setzt Fasan an. Fasan ist kein Ersatz für ein Scrum Board und will keiner sein. Fasan macht die Ebene darüber sichtbar. Orbit stellt dar, welche Ergebnisse auf welche Ziele und welche Strategie einzahlen, inklusive der Abhängigkeiten zwischen Initiativen, die im einzelnen Board unsichtbar bleiben. Analytics zeigt Zielfortschritt im Zeitverlauf statt als Momentaufnahme und macht Stagnation früh erkennbar. Dashboards liefern jeder Rolle die passende Sicht, ohne dass jemand Statusfolien pflegt. Der Bereich Produktivität verankert Reflexion und Kontext direkt am Ergebnis, statt sie in Meetings zu verlieren. Und die Integrationen halten die Zielarbeit im täglichen Workflow präsent, etwa über Slack, statt sie in ein zusätzliches Tool auszulagern.
Welche Prinzipien dabei den Unterschied zwischen dokumentierten und tatsächlich gesteuerten Zielen ausmachen, fasst unser Beitrag zu den OKR Best Practices zusammen.
Nächster Schritt: Demo buchen und in 30 Minuten sehen, wie sich Sprint-Ergebnisse am eigenen Zielsystem mit Unternehmenszielen verbinden lassen.
Ein Scrum Board zeigt alle Aufgaben eines Sprints in Spalten und macht sichtbar, was offen, in Arbeit und erledigt ist. Es dient dem Team zur Selbstorganisation, nicht der Statusmeldung nach oben. Die Karten wandern von links nach rechts, je weiter rechts eine Karte liegt, desto weiter ist die Aufgabe.
Mindestens drei: zu erledigen, in Bearbeitung und erledigt. Der Scrum Guide schreibt keine Spalten vor, Teams ergänzen bei Bedarf Blockiert, In Review oder Test. Jede zusätzliche Spalte sollte einen echten Zustandswechsel abbilden, sonst erzeugt sie nur Verschiebearbeit.
Das Scrum Board bildet einen zeitlich begrenzten Sprint ab und wird zu jedem Sprintstart neu befüllt. Das Kanban Board bildet einen kontinuierlichen Fluss ohne Zeitboxen ab und wird über WIP-Limits gesteuert. Scrum passt zu planbaren Entwicklungszyklen, Kanban zu Betrieb und Support mit unregelmäßigem Zulauf.
Nein. Der Scrum Guide kennt Product Backlog, Sprint Backlog und Increment als Artefakte. Das Board ist ein optionales Werkzeug, das viele Teams nutzen, um ihr Sprint Backlog sichtbar zu machen. Deshalb sind Spaltenstruktur und Format frei wählbar und dürfen in Retrospektiven angepasst werden.
Ein bis vier Wochen, wobei zwei Wochen die verbreitetste Länge und ein guter Startwert sind. Entscheidend ist Konstanz: Wer die Sprint-Länge laufend ändert, kann keine belastbare Velocity aufbauen und verliert die Vergleichbarkeit zwischen den Zyklen.
Ja, sofern sich die Arbeit in eigenständige, innerhalb eines Sprints lieferbare Ergebnisse zerlegen lässt. Verbreitet ist das in Marketing, Produktentwicklung und Personalarbeit. Bei stark unterbrechungsgetriebener Arbeit wie Support ist Kanban die passendere Wahl.
Als Faustregel maximal eine aktive Karte pro Person plus ein kleiner Puffer. Mehr parallele Arbeit erhöht die Kontextwechsel und verlängert die Durchlaufzeit, ohne den Durchsatz zu steigern. WIP-Limits pro Spalte sind der wirksamste einzelne Hebel dagegen.
KI kann heute Story-Entwürfe erzeugen, Akzeptanzkriterien vorschlagen, Schätzungen aus historischen Daten kalibrieren, doppelte oder veraltete Einträge erkennen und Verzögerungsmuster markieren. Priorisierung, Zusagen und die Bewertung in der Retrospektive bleiben beim Team, weil sie Verantwortung und Kontext erfordern.
Entwicklungsnahe Teams wählen meist Jira oder Azure DevOps, gemischte Teams eher monday, Asana oder ClickUp. Für Refinement und Story Mapping eignen sich Kollaborationsflächen wie Miro. Für die Verbindung zu Unternehmenszielen braucht es eine zusätzliche Ebene, die das Board ergänzt und nicht ersetzt.
Die Developers, also das Team, das die Arbeit erledigt. Der Scrum Master unterstützt die Wirksamkeit von Scrum, verteilt aber keine Aufgaben. Der Product Owner verantwortet Wert und Reihenfolge des Product Backlog, nicht die Board-Mechanik oder die Aufgabenverteilung im Sprint.
