Best Practices – Scrum-Board

Diese Anleitung beschreibt, wie ein Scrum-Board erstellt und gepflegt wird, sodass es Transparenz, Effizienz und Nachvollziehbarkeit für das ganze Scrum-Team sicherstellt.
Nach Befolgung dieser Anleitung kann jede Person – auch ohne Vorerfahrung – ein vollständiges Scrum-Board nach Best Practices aufbauen.

1. Vorbereitung

Bevor das Board erstellt wird, sollten folgende Punkte geklärt sein:

Teamstruktur:
Wer gehört zum Scrum-Team?
Wer ist Product Owner, Scrum Master, wer sind die Developers?
Toolwahl:
In welchem System wird das Board geführt? (z. B. Jira, Azure DevOps, Trello, Miro)
Sprintdauer:
Wie lange dauert ein Sprint (z. B. 2 Wochen)?
Definition of Done (DoD):
Welche Kriterien müssen erfüllt sein, damit eine Aufgabe als „fertig“ gilt?

Tipp: Dokumentiere die Definition of Done sichtbar auf dem Board (z. B. als oberste Karte in der „Done“-Spalte).

2. Rollenbeschreibung (kurzer Überblick)

Rolle	Hauptfokus	Typische Aufgaben	Anzahl pro Team
Product Owner	Produktwert & Priorisierung	Backlog-Pflege, Stakeholder-Management, Zieldefinition	1
Scrum Master	Prozess & Teamunterstützung	Coaching, Moderation, Hindernisse beseitigen	1
Developers	Umsetzung & Qualität	Entwicklung, Test, Design, Lieferung	3–9 Personen

2.1 Product Owner (PO)

Verantwortlich für den fachlichen und geschäftlichen Erfolg des Produkts
Pflegt und priorisiert das Product Backlog
Sorgt für maximale Wertschöpfung

Typische Hintergründe: Produktmanager:in, Fachexpert:in, Vertreter:in der Nutzerseite.

Es gibt genau einen Product Owner pro Scrum-Team, damit Prioritäten klar sind.

2.2 Scrum Master (SM)

Coach, Moderator und Prozesshüter
Unterstützt das Team bei der Anwendung von Scrum
Beseitigt Hindernisse (Impediments)
Moderiert Meetings (Daily, Retro, Planning etc.)
Schützt das Team vor Überlastung & unklaren Anforderungen

2.3 Developers (Entwicklungsteam)

Umsetzen der Produktanforderungen in funktionierende Inkremente
Selbstorganisation: Das Team plant, wie die Arbeit erledigt wird
Einhalten der Definition of Done
Zusammenarbeit ohne Silos, gemeinsames Ownership

Typische Skills: Entwicklung, Test, UX/UI, Datenbank, Infrastruktur, Dokumentation etc.

3. Aufbau des Scrum-Boards

Ein Scrum-Board zeigt den Arbeitsfluss im Sprint:
Von ungeplant → geplant → in Arbeit → geprüft → fertig.

Typische Spalten:

Spalte	Beschreibung	Regeln / Hinweise
Backlog	Noch nicht priorisierte/geplante Stories & Aufgaben	Wird vom PO gepflegt. Keine völlig unklaren Notizen.
To Do / Selected	Für den aktuellen Sprint geplante, startklare Aufgaben	Nur was Definition of Ready erfüllt.
In Progress	Aufgaben, an denen aktuell gearbeitet wird	WIP-Limit beachten (max. X Tasks gleichzeitig).
Review / Code Review	Aufgaben in technischer/fachlicher Prüfung	Review durch zweite Person.
Testing / QA	Aufgaben im Test	Tests dokumentiert/bestätigt.
Done	Aufgaben, die die Definition of Done erfüllen	Sprint-Inkrement ist lieferfähig.

Tipp: Statusfarben im Tool nutzen (z. B. Grau = Backlog, Blau = To Do, Gelb = In Progress, Grün = Done).

4. Grundprinzip beim Aufbau

Merksatz:

Ein gutes Board zeigt jederzeit klar:
Was gerade gemacht wird, woran als Nächstes gearbeitet wird und was fertig ist.

4.1 Backlog

Alle Ideen, Anforderungen und zukünftigen Aufgaben
Noch nicht im aktuellen Sprint geplant oder priorisiert
Verantwortlich: Product Owner
Nur sinnvoll formulierte Themen, keine losen Stichworte

Beispiel-Story:
„Als Benutzer möchte ich mein Passwort ändern können, damit ich mein Konto sicher verwalten kann.“

4.2 To Do / Selected for Sprint

Aufgaben, die im Sprint geplant und bereit zur Umsetzung sind
Erfüllen die Definition of Ready (klar, verstanden, geschätzt)
Werden im Sprint Planning vom Team ausgewählt

4.3 In Progress

Aufgaben, an denen aktiv gearbeitet wird
WIP-Limit anwenden (z. B. max. 4 Aufgaben gleichzeitig)
Ziel: weniger anfangen, mehr fertigstellen

4.4 Review / Code Review

Aufgabe ist technisch fertig entwickelt
Wird von zweiter Person geprüft (z. B. Code-Qualität, Architektur, Sicherheit)
Wichtig für Qualitätssicherung und Wissensaustausch

4.5 Testing / QA

Aufgabe wird fachlich/technisch getestet
Tests durch Entwickler, Tester oder automatisiert
Wenn kein separates Testing-Team existiert, übernimmt das Dev-Team Review & Test

4.6 Done

Alle Punkte der Definition of Done erfüllt
Fertig, auslieferbar, keine offenen To-dos

Beispiel-DoD:

Akzeptanzkriterien erfüllt
Code reviewed
Tests bestanden
Dokumentation aktualisiert
PO hat Abnahme erteilt
Keine offenen Fehler mehr

5. Zusatzelemente für ein gutes Board

Element	Erklärung	Nutzen
Swimlanes	Horizontale Zeilen (z. B. pro Epic)	Mehr Struktur & Übersicht
Labels/Tags	Schlagwörter/Kategorien	Filtern & Gruppieren
Farben	Visuelle Unterscheidung von Kartentypen	Schnellere Orientierung
WIP-Limits	Begrenzung paralleler Aufgaben	Fokus & Fluss (Flow)

5.1 Swimlanes

Strukturieren das Board z. B. nach:
Teammitglied
Projekt/Epic
Bug vs. Feature
Vorteil: Auf einen Blick sichtbar, wer oder was woran arbeitet.

5.2 Labels / Tags

Schlagworte wie #frontend, #urgent, #kundeA
Erleichtern Filter, Reports und thematische Auswertungen.

5.3 Farben

Beispiele:
Grün = Done
Blau = Story
Orange = Task
Rot = Bug
Lila = Spike

5.4 WIP-Limits

Begrenzen die Anzahl paralleler Aufgaben je Spalte
Verhindern Überlastung
Fördern Teamarbeit & Fokus auf Fertigstellen

6. Kartenkategorien & Vorlagen

Aufgabentypen auf dem Board:

Kategorie	Zweck	Typisches Ziel	Wann verwenden?
User Story	Anforderung aus Nutzersicht	Wert schaffen	Wenn neue Funktion/Nutzen geliefert werden soll
Task	Konkrete Arbeitseinheit	Umsetzung organisieren	Wenn klar ist, was genau getan werden muss
Bug	Fehler / Defekt	Qualität sichern	Wenn etwas nicht wie erwartet funktioniert
Feature/Epic	Größerer Funktionsblock	Struktur schaffen	Wenn Thema zu groß für einzelne Story ist
Spike	Forschungs-/Klärungsaufgabe	Wissen gewinnen	Wenn erst verstanden werden muss, was zu tun ist

User Story – Vorlage:

Als [Rolle] möchte ich [Ziel], damit ich [Nutzen] habe.
Akzeptanzkriterien: …

Task – Vorlage:

Ziel: …
Schritte: …
Ergebnis: …

Bug – Vorlage:

Beschreibung: …
Schritte zur Reproduktion: …
Erwartetes Ergebnis: …

Feature / Epic – Vorlage:

Beschreibung: …
Ziele: …
Verknüpfte Stories: …

Spike – Vorlage:

Fragestellung / Problem: …
Vorgehensweise: …
Erwartetes Ergebnis (z. B. Entscheidung, Architekturvorschlag): …
Timebox: … (z. B. 1–2 Tage)

7. Pflege & Nutzung des Boards

7.1 Tägliche Nutzung (Daily Scrum)

Leitfragen:

Was habe ich gestern gemacht?
Was mache ich heute?
Was hindert mich?

Das Board ist zentrales Hilfsmittel. Karten werden live verschoben.

7.2 Wöchentliche Pflege

Product Owner aktualisiert das Backlog
Team überprüft WIP-Limits & Aufgabenstatus
Veraltete oder unklare Tickets werden bereinigt

7.3 Nach jedem Sprint

„Done“-Tasks archivieren oder dokumentieren
Lessons Learned in der Retrospektive festhalten
Definition of Done bei Bedarf anpassen

7.4 Transparenz & Übersicht

Filter & Swimlanes für Epics, Owner, Priorität nutzen
WIP-Limits respektieren
Farbcodes konsistent verwenden
Alle Teammitglieder haben Lese- und Schreibrechte

8. Zusammenfassung

Ein gutes Scrum-Board ist:

Transparent – Jeder sieht den aktuellen Stand.
Aktuell – Keine veralteten Aufgaben.
Einheitlich – Klare Spalten, Kategorien und Vorlagen.
Nützlich – Unterstützt Daily, Planning und Retrospektive gleichermaßen.