We create digital success
Elasticbrains GmbH
Schieggstr. 23D
81479 München
+49 176 8562958
© 2023 Elasticbrains GmbH | Impressum | Datenschutz
Menü
Scrum Rituale & Artefakte
Die 3 Scrum Artefakte die in Scrum zum Einsatz kommen sind das Product Backlog, das Sprint Backlog sowie das Product Increment.
Die 5 Rituale (Ereignisse) sind der Sprint, das Sprint Planning, das Daily Scrum das Review und die Retrospektive.
Events (Rituale)
Artefakte
Scrum Artefakte
Product Backlog
- Enthält möglichst alle geplanten Features in Form von User Stories, die innerhalb des Backlogs gegeneinander priorisiert sind.
- Wird durch den Product Owner gepflegt
Sprint Backlog
- Die im aktuellen Sprint relevanten User Stories
- Der Umfang des Sprint Backlogs ist innerhalb des Sprints fix (commitment der Entwickler)
Increment
- Die im jeweiligen Sprint umzusetzende Software / App
- Im Rahmen der User Story Spezifikation immer lauffähig
Scrum Rituale
ZIEL:
Planung des kommenden Sprints
Sprint Planning
- Das Sprint Planning besteht aus zwei Teilen, dem Planning 1 und Planning 2
- Im ersten Teil des Sprint Planning werden die vom Product Owner (PO) geplanten und priorisierten User Stories dem Developer Team vorgestellt. Die Entwickler:innen schätzen die User Stories und geben ein erstes Commitment ab.
- Im zweiten Teil des Plannings planen die Entwickler:innen grob den Sprint, erstellen Subtasks identifizieren Risiken und geben ein finales Commitment ab
Teilnehmer
- Product Owner:in
- Crossfunctional Team
- Scrum Master:in
ZIEL:
Transparenz über den aktuellen Sprint Status, Kommunikation im Team und schnelle Identifizierung von Blockern
Daily (Standup)
- Das Daily ist in der Regel auf 15 min beschränkt
- Jede(r) Teilnehmer:in beantwortet drei Fragen:
- Was hab ich (gestern) gemacht?
- Was mache ich heute?
- Was blockiert mich gerade?
- Wichtig keine Diskussionsrunde –> Timebox auf 15 Minuten
- falls es Themen mit Klärungsbedarf gibt
–> dediziertes Meeting, oder direkt im Anschluss an das Daily
- falls es Themen mit Klärungsbedarf gibt
Teilnehmer
- Product Owner:in
- Crossfunctional Team
- Scrum Master:in
ZIEL:
Kontinuierliche Verbesserung des Prozesses und/oder Beseitigung von Problemen
Retrospektive
- Der/die Scrum Master:in bereitet wechselnde Formate vor, um kontinuierlich positive wie negative Erfahrungen der Projektteilnehmer:innen und Verbesserungsvorschläge zu sammeln.
Beispiele:- Start / Stop / Continue
- Mad / Sad / Glad
- Team / Project SWOT
- Lean Coffee
- Dabei sollen immer konkrete Aufgaben herausfallen, die in dem nachfolgenden Sprint umgesetzt werden können um den Prozess kontinuierlich zu verbessern
Teilnehmer
- Product Owner:in
- Crossfunctional Team
- Scrum Master:in
Weitere Tools für Retros:
ZIEL:
Präsentation des umgesetzten Artefakts des letzten, gerade beendeten Sprints
Sprint Review (Demo)
- Präsentation der umgesetzten Features durch die Entwickler:innen
- Präsentation der erreichten KPIs des Sprints (Offene Stories, Geschlossene Stories, Velocity, etc)
- Falls Stakeholder:innen anwesend sind, könnte der Rahmen auch genutzt werden um einen Overall-Status im Gesamtprozess zu kommunizieren
Teilnehmer
- Product Owner:in
- Crossfunctional Team
- Scrum Master:in
- Ggfls. Stakeholder
ZIEL:
Vorstellung neuer Stories durch den Product Owner (PO) – Story Estimation des Teams für die Vorausplanung zukünftiger Sprints
Refinement
- ggfls. Fragen zu aktuellen Stories klären
- Präsentation neuer User Stories durch den/die Product Owner:in
- Feedback zu den User Stories durch das Team
- Entlastung des Planning Meetings, da fertige User Stories bereits geschätzt werden können
- Priorisierung des Backlogs
- “Aufräumen” des Backlogs
Teilnehmer
- Product Owner:in
- Crossfunctional Team
- Scrum Master:in
Definition of ready / Definition of done
Formale, definierbare, implizite Anforderungen an User Stories (DoR) und an das Inkrement (DoD)
Definition of Ready
- Die User Story liegt definiert im Backlog.
- Die User Story entspricht den formalen Anforderungen
- Die User Story hat vollständige Akzeptanzkriterien
- Die User Story hat erste Testfälle definiert
- Die User Story erfüllt die INVEST Kriterien
- Die User Story wurde vom Entwickler Team geschätzt
- Abhängigkeiten zu anderen Teams / Dienstleistern innerhalb der User Story sind identifiziert
- Alle Abhängigkeiten Dritter, wie Layouts, Assets, API Dokumentationen, SDKs sind für das Team verfügbar
- UX Anforderungen wurden mit in die User Story einbezogen (z.B. Verhalten bei Edge Cases)
Definition of Done
- develop branch ist “rebased” in den feature branch und konflikte wurden ggf aufgelöst
- das Inkrement erfüllt vollständig die Akzeptanzkriterien
- eine Dokumentation ist erstellt und Hinweise zum Test der Story sind in den Kommentaren
- Das Inkrement ist ohne Fehler in der CI erstellt worden
- Der Entwickler hat das erstellte Inkrement getestet
Scrum Beispiel Meetings
Kanban als Vorstufe zur Story Erstellung
Weitere Themen in unserem Agile Bereich:
Wir freuen uns auf Ihre Anfrage
