Ziele der SCRUM-Checkliste
Wenn Sie das Gefühl haben nun alle Methoden und Prozesse von SCRUM im Team installiert zu haben und bereits mehrere Sprints durchgeführt haben, lassen Sie das Team bewerten wie erfolgreich sie die Einführung der SCRUM-Methode einschätzen. Drucken Sie diese Liste aus und verteilen Sie bei der nächsten Retrospektive an das Team. Es geht hierbei insbesondere auch darum Diskussionen anzuregen und gemeinsam zu überlegen, welche weiteren Elemente von SCRUM im Team eingeführt werden sollten. Ich bin kein Verfechter davon, dass man zwingend alle SCRUM-Prozesse 1:1 umsetzen muss – auch hier ist Agilität also Anpassungsfähigkeit gefragt.
1.) Bottom-Line von SCRUM
Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert.
Bereitstellung von neuen, getesteten Features alle 4 Wochen oder weniger
Es werden die wichtigsten business relevanten Features bereitgestellt
Der Prozess verbessert sich kontinuierlich
2.) Kernbestandteile von SCRUM
Diese Bestandteile können als Kernbestandteile von SCRUM genannt werden. Ohne diese haben Sie SCRUM nicht erfolgreich implementiert.
Der Product Owner ist klar definiert
Der Product Owner hat die Kompetenz zu priorisieren.
Der Product Owner hat direkten Kontakt zum Team
Das Team hat ein Sprint-Backlog
Sprint Backlog ist für jeden einsehbar
Das Backlog wird täglich upgedatet
Das SCRUM Team verfügt exklusiv über das Sprint-Backlog
Das Daily Stand Up findet regelmäßig statt
Das gesamte Team nimmt teil
Probleme und Impediments werden aufgezeigt und wahrgenommen
Das Review Meeting wird am Ende eines jeden Sprints durchgeführt
Das Team übernimmt die Vorbereitung und Durchführung des Review Meetings
Es werden fertige, getestete Features vorgestellt
Das Team erhält Feedback vom Product Owner und den Stakeholdern
Es existiert eine Definition of Done
Die Definition of Done wird vom Team respektiert und berücksichtigt
Bereitgestellte Features entsprechen der Definition of Done
Retrospektive findet an jedem Sprintende statt
Es werden konkrete Verbesserungen erarbeitet und im Laufe des nächsten Sprintzyklus angegangen
Es sind Verbesserungen erkennbar
Das gesamte Team inklusive Product Owner und SCRUM Master nehmen teil
Es existiert ein Product Backlog
Das Product Backlog ist priorisiert durch den Product Owner
Die Priorisierung erfolgt gemäß dem Business Value
Es erfolgte eine gemeinsame Schätzung der hoch priorisierten Items für mindestens zwei kommende Sprints
Einträge werden vollständig von dem Product Owner verstanden
Alle Einträge sind in Form einer User Story beschrieben inklusive der Akzeptanzkriterien
Einzelne Einträge sind so geschrieben, dass sie in einem Sprint durchführbar sind
Es findet regelmäßig ein Sprintplanungsmeeting (Refinement-Meeting) statt
Der Product Owner und das gesamte Team nimmt hieran teil
Das Product Backlog wurde durch den Product Owner vorbereitet
Der Output aus dem Meeting ist die Sprintplanung
Das gesamte Team glaubt an das Sprintziel und hält es für realistisch
Der Product Owner ist zufrieden mit der Priorisierung und dem Sprintziel und kann dies gegenüber den Stakeholdern vertreten
Die Sprints haben eine definierte, gleichbleibende Länge erreicht
Die Sprintlänge beträgt maximal vier Wochen oder weniger
Das Sprintende wird erreicht und nicht verschoben
Das Team wird nicht durch externe Faktoren gestört oder gesteuert
Das Team liefert in der Regel das, was im Planungsmeeting definiert wurde
Teamgröße ist stabil
Das Team sitzt zusammen
Die Teamkonstellation ist weitestgehend stabil
Es gibt maximal 9 Teammitglieder und mindestens 5
3.) Empfohlene Bestandteile von SCRUM
Nicht absolut notwendig aber sinnvolle Bestandteile von SCRUM.
Es wird in Storypoints geschätzt anstatt in Zeit
Der Product Owner und der SCRUM Master sind gut erreichbar
Das Product Backlog ist für jedermann einsehbar
Jeder im Team nimmt an der Schätzung der Product Backlog Items teil
Das Team besitzt das Know-How die Backlog Items umzusetzen
Der SCRUM Master sitzt beim Team
Das Team kennt die drei wichtigsten Impediments
Der SCRUM Master hat eine Strategie diese zu beseitigen
Das Management ist informiert, falls der SCRUM Master diese nicht selbst beseitigen kann
Der SCRUM Master ist fokussiert diese zu beseitigen
User Stories werden in der Sprintplanung in Aufgaben (Tasks) runtergebrochen
Die Tasks oder User Stories sind geschätzt
Die Tasks werden täglich gemäß des Fortschritts aktualisiert
Die Geschwindigkeit (Velocity) wird im Burn-down gemessen
Die Tasks oder User Stories sind geschätzt
Die Geschwindigkeit nutzt der Product Owner für die kommende Sprintplanung
Nur fertiggestellte Tasks beeinflussen die Velocity
Das Daily Stand Up findet täglich zur gleichen Uhrzeit mit allen Teammitgliedern statt
Es beträgt maximal 15 Minuten
Jedes Teammitglied weiß, woran der andere gerade arbeitet