Pauschal kann man sagen:
Grade so detailliert, dass das Team offene Fragen während des Sprints, in dem die Story umgesetzt wird, rechtzeitig klären kann.
Das hängt also auch von den vorhandenen Skills im Team ab. Wenn z.B. kein Konzepter-Skill im Team vorhanden ist, dann muss das UI/UX-Konzept im Vorfeld erstellt werden. Auch dann, wenn es so umfangreich ist, dass es in dem Sprint nicht rechtzeitig genug fertiggestellt werden kann, um die Folgetätigkeiten auch noch abzuschließen.
Was tun mit Langläufern oder zurückgestellten Aufgaben bei Scrum?
Stories oder Aufgaben, die bekanntermaßen nicht im aktuellen Sprint abgeschlossen werden können, sollten nicht ins Sprint Backlog aufgenommen werden. Das ist oft z.B. bei teamexternen Abhängigkeiten der Fall.
Aber wohin gehören sie denn dann?
Entweder teilt man so ein Issue in kleinere Teile auf, die innerhalb eines Sprint umgesetzt werden können, oder markiert es im Backlog als WARTEND.
Für den zweiten Fall kann man im Backlog eine Trennlinie eingetragen. Z.B. „— WAITING ON SOMETHING above this line —„.
Niedrig priorisierte Bugs oder Aufgaben, die prinzipiell startklar sind, und nur noch auf Zeit bzw. Priorisierung warten, gehören ans untere Ende des Backlogabschnittes, welcher fertig für den Sprint ist. D.h. direkt über eine Trennlinie „— READY FOR SPRINT above this line —„.
Was tun, damit solche Einträge nicht in Vergessenheit geraten?
- Issues die an bestimmte Termine gebunden sind, sollte man in einen elektronischen Kalender eintragen. Dann bekommt man eine aktive Erinnerung.
- Alternativ bzw. zusätzlich kann man ein Board errichten, auf dem solche Langläufer auf Wiedervorlage gelegt werden können. Das Board hat einen Bereich für jeden künftigen Sprint, auf dem diese Aufgaben geheftet werden. Zu Beginn des Sprints wird geprüft, ob die Aufgabe ins Sprintbacklog übertragen werden kann.
- Am Besten gegen das Vergessen ist jedoch eine erste Teilaufgabe zu definieren, die innerhalb eines Sprints abgeschlossen werden kann. Das ist dann die Erinnerung an die Folgeaufgabe.
Verwandte Artikel:
WM 2014 Spielaufstellung für Estimation Workshops
Manchmal scheinen selbst Entwickler zu viel zu reden. Grade in frühzeitigen Estimation- (bzw. Grooming- oder Product Backlog Refinement) Workshops verliert man leicht den Fokus und diskutiert zu früh über fachliche und technische Feinheiten.
Mit dieser Spielaufstellung hat das Team eine spielerische Hilfe sich auf die wichtigsten Dinge zu konzentrieren.
Jeder Spieler auf dem Feld steht für einen wichtigen Aspekt bei einer User Story.
- Titel ist eindeutig.
- Wer, was, warum sind beschrieben.
- Story wurde vorab von einem Entwickler gereviewed.
- Fachlichkeit ist nachvollziehbar.
- Akzeptanzkriterien sind eindeutig.
- Abschätzbar.
- Fachliche Voraussetzungen sind aufgelistet.
- Technische Voraussetzungen sind aufgelistet.
- Umsetzung ist in einem Sprint möglich.
Darüber hinaus kann man sich noch weitere Spielregeln ausdenken. Ersatzspieler, z.B. für die typischen INVEST Kriterien oder zu speziellen Team Herausforderungen. Oder Punktregelungen.
Diese Präsentation mit der Spielaufstellung kann gerne weiterverwendet werden. Enjoy!
•Titel ist eindeutig.
•Wer, was, warum sind beschrieben.
•Story wurde vorab von einem Entwickler gereviewed.
•Fachlichkeit ist nachvollziehbar.
•Akzeptanzkriterien sind eindeutig.
•Abschätzbar.
•Fachliche Voraussetzungen sind aufgelistet.
•Technische Voraussetzungen sind aufgelistet.
•Umsetzung ist in einem Sprint möglich.
Verwandte Artikel:
Zwei User Story Beispiele
Ein einfaches Beispiel
Überschrift: Anwendung starten
Story: Als Autor möchte ich nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen, um Zeit zu sparen.
(Quelle: Wikipedia)
Ein ausführlicheres Beispiel
Überschrift: Datenschutzerklärung System Sales Assistant
Story: Jeder Anwender der Anwendung muss vor der Verwendung personenbezogener Daten bestätigen, dass er die Datenschutzerklärung beachtet, um den rechtlichen Anforderungen des Datenschutzgesetz §4711 zu genügen.
Akzeptanzkriterien:
- Bei jeder Anmeldung am System wird eine Textinformation angezeigt, die bestätig werden muss. Maximal jedoch einmal je Benutzer und Quartal.
- Wenn der Anwender die Information nicht bestätigt, beendet sich die Anwendung.
- Die Textinformation muss durch eine Person in der Rolle „Betrieblicher Datenschutzbeauftragter“ ohne neue Distribution der Anwendung redaktionell gepflegt werden können.
Folgendes ist nicht angefordert:
- Die Textinformation muss nicht archiviert werden.
- Die Bestätigungen müssen nicht gespeichert oder weitergemeldet werden.
Bemerkungen zu den Beispielen
- Die Überschrift erleichtert das optische Auffinden in einem Stapel von User Stories. Unabhängig davon, ob sie an der Wand hängen, oder in einem elektronischen System wie z.B. Jira.
- Das einfache Beispiel funktioniert gut für Teams, die schon lange zusammen an den Produkt arbeiten und großes Domainenwissen haben. Ein neu gegründetes Team benötigt i.d.R. mehr Spezifikationen.
- Der Detailgrad einer User Story wächst mit der Zeit. Zur Releaseplanung und Priorisierung gibt es nur einfache Stories Sätze / Epics / Features, aber dafür decken diese möglichst vollständig den Release Umfang ab.
- Nach erster Priorisierung werden die Stories für die kommenden 2-3 Sprints in Product Backlog Refinement Workshops detailliert, so dass zum Sprint Planning I schon einige der Punkte vorhanden sind:
- Überschrift
- User Story
- Akzeptanzkriterien
- Abschätzung in Story Points
- Ermittlung und Klärung technischer sowie organisatorischer Abhängigkeiten
Bei Bedarf noch
- Nicht-Anforderungen
- Funtionale Ablaufdiagramme
- UX-Design / Kreativ Konzept / Wire Frames
- Vermaßtes UI-Design
- Testfälle
Das hilft dem Team dabei, die Story auch wirklich in einem Sprint umsetzen zu können.
Verwandte Artikel:
Agiles Projektcontrolling
Agilität bedeutet nicht, dass man orientierungslos vor sich her entwickelt. Durch folgende Praktiken haben die verschiedennen Interessengruppen einen guten Einblick in das Projekt.
- Tägliche Teammeetings
- Burndown (oder -up) Grafiken je Iteration (Sprint) und für das gesamte Release
- Echte Fortschrittsmessung mit der Definition von DONE
- Anzahl der entdeckten Fehler nach DONE Meldung
- Review Meetings am Ende einer Iteration
- Grad der Testabdeckung
Daneben natürlich die üblichen Klassiker:
- Zeit
- Kosten