Sprintplanung

Im Sprint Planning soll ein realistischer Plan für die Umsetzung wichtiger Features im aktuellen Sprint erstellt werden. Dazu muss das Sprint Planning zwei Dinge liefern:

• Die Menge der für den Sprint selektierten Product Backlog Items
• Einen Plan, wie diese Product Backlog Items im Sprint umgesetzt werden

​

Definition of Ready

Die Definition of Ready bestimmt, wann ein Product Backlog Item ausreichend ausgearbeitet ist, um in einen Sprint aufgenommen zu werden. Während die Idee grundsätzlich sinnvoll ist, kann sie problematisch werden, wenn sie als starre Checkliste oder zur Abgrenzung zwischen Product Owner und Entwicklungsteam missbraucht wird. Dies widerspricht dem kollaborativen Gedanken von Scrum. Eine gute Definition of Ready sollte daher:

• Den Fokus auf Zusammenarbeit statt auf Abgrenzung legen
• Prozessorientiert statt artefaktorientiert sein
• Ein gemeinsames Verständnis der User Stories sicherstellen
• Die gemeinsame Formulierung von Akzeptanzkriterien betonen

Das Ziel ist eine konstruktive Zusammenarbeit zwischen Product Owner und Entwicklungsteam, nicht eine bürokratische Hürde.

​

Defintion of Done

Die Definition of Done ist ein zentrales Element in Scrum, das die Qualitätsstandards für fertiggestellte Product Backlog Items festlegt. Eine typische DoD enthält technische und qualitätssichernde Kriterien wie:

​

Code-Integration

• Integration in den Hauptentwicklungszweig (HEAD/TRUNK/MASTER)
• Erfolgreiche Integration mit anderen neuen Funktionen

​

Testing

• Installation und Test auf Testumgebung
• Erfolgreiche Systemtests
• Erfüllung aller Akzeptanzkriterien

​

Dokumentation

• Aktualisierung der Benutzer- und Betriebsdokumentation

​

Praktische Herausforderungen

• Besonders für neue Teams ist die Erstellung lieferbarer Produktinkremente oft schwierig
• Die Organisation manueller Tests durch Fachabteilungen kann problematisch sein
• Als Übergangslösung beschränken sich Teams manchmal zunächst auf Lieferungen ins Testsystem

Wichtig ist zu verstehen, dass die DoD ein lebendes Dokument ist, das sich mit der Reife des Teams weiterentwickeln kann, aber immer die grundlegenden Qualitätsstandards sicherstellen muss.

​

Sprintziel

Das Sprint-Ziel ist ein zentrales Commitment im Sprint Backlog und sollte mehr sein als nur eine Liste abzuarbeitender Tasks. Ein effektives Sprint-Ziel folgt den SMART-Kriterien:

• Specific: Eindeutig und konkret formuliert
• Measurable: Erreichung muss messbar sein
• Achievable: Herausfordernd, aber erreichbar
• Relevant: Wichtig für Produkt/Unternehmen
• Time based: Zeitlich begrenzt (durch Sprint-Länge gegeben)

Gute Sprint-Ziele sind beispielsweise:

• “Wir trauen uns, die Statistikfunktion vor dem Vorstand zu präsentieren”
• “Unser Web-Frontend kann eine Transaktion auf dem Hostsystem auslösen”
• “Die Oberfläche unserer Webanwendung ist responsiv”
• “Das System ist Multi-User-fähig”

Vermeiden sollte man zu generische Ziele wie “Sprint Backlog abarbeiten”, da diese:

• Wenig motivierend sind
• Keine klare Richtung vorgeben
• Die “Relevant”-Komponente der SMART-Kriterien nicht erfüllen

Wenn regelmässig keine konkreten Sprint-Ziele definiert werden können, deutet dies möglicherweise auf Probleme bei der Priorisierung des Product Backlogs hin.