Bevor das Scrum Team mit seiner Arbeit beginnt, steht die Analyse des umzusetzenden Themas an. Für diese Analyse sollte sich das Team aus Product Owner und Business Analyst eigene Qualitätsansprüche festlegen, um vollständige Stories zu erhalten. Ein Erfahrungsbericht.
Ich habe gerade einen Tag Scrum Zeremonien hinter mir. Als Product Owner ist die Estimation Session im Planning immer der anstrengendste Teil des Tages – und der kommt direkt nach dem Mittagessen. Fünfzehn User Stories habe ich gemeinsam mit dem Business Analysten dem Team vorgestellt, drei davon „durfte“ ich gleich wieder einpacken. Das Team hatte vor der ersten Schätzung so viele Fragen, die nicht alle zufriedenstellend beantwortet werden konnten. Das passiert zum Glück nicht so oft. Wenn, dann ist es aber umso ärgerlicher.
Am Anfang des Tages war die Welt noch einfach und gar nicht anstrengend. Im Sprint Review wurden mir die in den letzten zwei Wochen umgesetzten User Stories präsentiert. Da kann ich für jede User Story zum Beispiel die folgenden Punkte durchgehen:
- Ist die Funktionalität der Story umgesetzt?
- Sind alle Akzeptanztests erfüllt?
- Wie wurde die Umsetzung dokumentiert?
- Gab es ein technisches Review der Story?
Kurz gesagt bin ich die „Definition of Done“ des Teams durchgegangen – den „unausgesprochenen Vertrag“ zwischen Team und Product Owner. Wenn das Team einen Vertrag mit mir als Product Owner hat, wann eine Story fertig ist, ist der eigentlich nur einseitig bindend? Nein, die Kehrseite der Medaille ist die Definition of Ready.
Thema analysieren
Die Definition of Ready ist mein Teil des Vertrags eine fertige User Story ans Team zu geben, die geschätzt werden kann und die ich im Planning nicht wieder einpacken muss. Ähnlich wie bei der Definition of Done entwickelt sich die Definition of Ready im Laufe der Zeit. Erhalte ich die Schätzung nur unter Protest oder gar nicht, war mein Teil noch nicht erfüllt, die Story noch nicht fertig.
Ganz am Anfang meiner Definition of Ready steht die Analyse des Themas. Haben wir, Business Analyst und Product Owner, das Thema verstanden und sind auf den Kern der Anforderung gestoßen? Haben wir alle unsere Fragen bei der Analyse geklärt? Ist das noch nicht der Fall, heißt es Zurück auf Los…
User Stories schreiben
Die erste grobe Struktur erhält das Thema, wenn wir überlegen wie viele User Stories wir schreiben werden. Je mehr Stories wir finden, desto notwendiger wird es gemeinsam mit dem Team und evtl. auch dem Kunden einen Story Workshop zu machen.
Schreiben wir die User Stories auf, beachten wir einige formale Aspekte. Entspricht die Story der Vorlage „Als Rolle möchte ich ein Ziel erreichen, um ein Problem zu lösen“? Jede Story braucht auch ihre Akzeptanztests. Entsprechen die Akzeptanztests der Vorlage „Zeige, dass ein Teilziel erreicht wird“?
Review machen
Anschließend gehe ich die Stories, ähnlich wie diesen Text nachdem ich die erste Version geschrieben habe, noch einmal durch. In Gedanken stelle ich mir dabei schon mal das Planning vor in dem ich die Story präsentiere. Dabei versuche ich mir die typischen Fragen des Teams zu stellen und überlege, ob ich darauf eine Antwort in der Story formuliert habe. Ist das nicht der Fall, fehlt noch der eine oder andere Akzeptanztest.
Neben der inhaltlichen Aufbereitung der User Stories habe ich auch noch die Komplexität der Stories im Blick. Ich versuche eine gute Mischung kleiner oder mittlerer Stories zu erhalten und möglichst keine großen. Große Stories sind in dem Team Stories mit 13 oder mehr Story Points. Diese Stories haben zwei Nachteile. Zum einen bieten sie eine höhere Chance während der Umsetzung zu explodieren, zum anderen fällt das Commitment des Teams kleiner aus, wenn eine „Wilde 13“ im Sprint ist.
Will ich mit einer Story eine Änderung auf der Benutzeroberfläche erreichen, ist ein Anhang an die Story auf jeden Fall ein beispielhafter Screenshot der neuen Funktionalität. Damit habe ich zumindest meine Erwartung deutlich gemacht. Wohl gemerkt meine Erwartung und nicht die exakte Vorgabe der Lösung.
Planning vorbereiten
Richtig spannend wird es, wenn die Umsetzung im eigenen Team auch noch von der Zuarbeit anderer Teams abhängig ist. Neben der Planung im eigenen Team, kommt es dann drauf an mit dem Nachbarteam ein passendes Zeitfenster für die Umsetzung auszuhandeln.
Für das Planning in dem ich die neuen User Stories vorstelle brauche ich noch eine gute Einführung in das Thema der Story. Mehr Verständnis für den Zusammenhang, in dem die konkrete Story steht, schärft den Blick des Teams auf die Story und erhöht die Qualität der Rückfragen im Planning und damit meiner Erfahrung nach auch die Qualität der Umsetzung.
Erkennen wir während der Arbeit an den User Stories, dass mit den bisher im Team eingesetzten Technologien das aktuelle Thema nicht umgesetzt werden kann, ist das ein deutliches Signal. Bevor die fachliche Umsetzung starten kann, muss das Team in einem Spike herausfinden, wie die technische Umsetzung erfolgen soll.
Definition of Ready schützt nicht vor Kommunikation
Die letzten Absätze mögen sich sehr nach Wasserfall anhören: „Ich schreib mal alles auf was ich so zu einem Thema zusammen getragen habe und werfe das über die Wand zu den Entwicklern. Hab ich lange genug gewartet wird schon das Richtige implementiert sein.“ Deshalb sind für mich die beiden folgenden Punkte besonders wichtig.
- Nicht alle Stories brauchen die gleiche Vorbereitung. Agile Softwareentwicklung ist auch in der Aufbereitung der Stories agil.
- Im Zeitraum vom Planning bis zum Review gibt es zwischen Product Owner, Business Analyst und Entwickler viele Möglichkeiten sich über eine Story auszutauschen. Die Story selbst ist immer der Initiator für Kommunikation zwischen allen Beteiligten, z.B. zur Frage die die GUI denn nun wirklich aussehen soll.
Fazit
Auf den Punkt gebracht stehen je nach Thema eine Auswahl der folgenden Punkte auf meiner aktuellen Definition of Ready für eine Story:
- Ist das Thema durchdrungen?
- Sind die Fragen geklärt?
- Habe ich die Vorlage für User Story und Akzeptanztests genutzt?
- Haben die einzelnen Stories die richtige Größe?
- Habe ich mit dem Business Analyst ein Story Review gemacht?
- Wie starte ich die Präsentation der Story?
- Ist für GUI Themen ein beispielhafter Screenshot erstellt?
- Ist für eine neue Technologie ein Spike notwendig?
- Ist die übergreifende Umsetzung mit anderen Teams koordiniert?
Jedes Mal, wenn ich für eine Story im Planning keine Schätzung bekommen habe oder zu viele Frage beantworten musste, entdecke ich im Nachgang, dass ich meinen Teil des Vertrags nicht eingehalten habe. Meine Story war nicht ready!
Ich hoffe, dass ich mit meinem Ausflug in die Scrum Welt aus meiner Sicht andere Product Owner dazu angeregt habe, sich selbst Gedanken über ihre eigene Definition of Ready zu machen.
Mein Ziel für die nächsten Zeremonien ist klar: Ich will meine eigene Definition of Ready erfüllen und keine Story mehr einpacken müssen. Das sollte das Planning auch entspannter machen.