Scrum-Checkliste
Egal ob ein Team neu mit Scrum anfängt oder schon lange damit unterwegs ist, es macht Sinn von Zeit zu Zeit zu überprüfen ob man nicht in ganz andere Richtungen abrutscht. Die folgende Checkliste basiert auf einer die ich bei einem meiner Kunden eingesetzt habe. Sie geht an einigen Stellen über den Scrum Guide hinaus um auch die Best Practices zu umfassen, andere Dinge werden nicht erwähnt, da sie dort selbstverständlich waren (z.B. dass technische Lösungswege oder Architektur von den Teams selbst festgelegt werden). Eine gute Einsatzmöglichkeit für so eine Liste ist, sie ausgedruckt ans Team-Board zu hängen. Sobald ein Punkt aus Sicht eines Teammitglieds nicht mehr erfüllt ist kann er ihn rot markieren, wodurch ein Thema für die nächste Retrospektive entsteht. Alternativ kann sie auch in Workshops, Audits oder zu sonstigen Anlässen genutzt werden. Was ich nicht machen würde wäre ein komplettes Besprechen aller Punkte in einiger einzigen Retrospektive, dafür dürfte die Zeit nicht reichen.
- Das Team besteht aus 3 - 7 Mitgliedern, einem PO und einem Scrum Master
- Das Team ist crossfunktional besetzt (FE, BE, QA, UX, etc)
- Der PO und der Scrum Master sitzen beim Team
- PO und der Scrum Master sind Vollzeit-Jobs
- Der PO hält ständigen Kontakt zu seinen Stakeholdern
- Der Scrum Master tauscht sich regelmässig mit dem Management aus
- Die Regel-Meetings finden statt (Daily Standup, Planning, Retrospektive, Review)
- In jedem Sprint finden Backlog Refinements statt
- Es existiert ein physisches Sprint-Board
- Es existieren ein Burndown-Chart und ein Velocity Chart
- Es existieren eine Definition of Ready und eine Definition of Done
- Die Sprints haben jeweils ein fachliches Sprint-Ziel
- Alle Stories im Sprint sind fachlich geschnitten
- Alle Stories im Sprint haben fachliche Akzeptanzkriterien
- Alle Stories im Sprint sind geschätzt
- Alle Stories im Sprint sind Epics zugeordnet
- Alle Stories im Sprint sind in Tasks unterteilt
- Die Stories im Sprint werden sequenziell abgearbeitet
- Die Tasks sind so geschnitten, dass sie in einem Tag erledigt werden können
- Es gibt WIP-Limits für die Team-Mitglieder
- Im Sprint finden Pairing und gegenseitige Reviews statt, es gibt shared Codeownership
- Die Tests ergeben eine Test-Pyramide
- Alle Aufwände (auch SoS, Spikes, Bugs, etc.) sind auf dem Board abgebildet
- Nach dem Sprint ist jede fertige Story potentially shippable
- Nach dem Sprint erzeugt jede fertige Story eine nutzbare Funktionalität
- Im Sprint Review sind Stakeholder anwesend
- Impediments werden erkannt und bearbeitet
- Es wird an technischen Schulden und Bugs gearbeitet
- Der PO weiss woran die Entwickler arbeiten
- Das Team kennt die Produktvision und den ungefähren Inhalt der nächsten Sprints
- Das Team kennt seine Velocity
- Es existiert eine Story Map und/oder Road Map
- Es gibt ein Scrum of Scrums zur fachlichen Abstimmung zwischen den Teams
- Es gibt eine Community of Practice zum Erfahrungsaustausch mit anderen Personen
