Egal bei welchem Kunden oder in welcher Branche ich bin, ein Problem treffe ich als Agile Requirements Engineering Coach immer wieder an: Zu grosse Features und User Stories. Was heisst „zu gross“? Grundsätzlich kann man sagen, ein Feature ist dann zu gross, wenn es nicht in ein Release (Product Increment) passt. Bei einer User Story dann, wenn sie nicht in einem Sprint abgearbeitet werden kann. Das hat diverse negative Auswirkungen:
- Mehraufwand
Unfertige Artefakte müssen im nächsten Release- oder der Sprint Planning erneut diskutiert, geschätzt und eingeplant werden. - Unregelmässige Auslastung
Tester sind durch erhöhten Testaufwand am Ende eines Sprints oder Releases chronisch unter- oder überlastet. Falls dedizierte Tester im Team sind, werden diese nicht besonders erfreut sein darüber, dass sie mal zu wenig und dann wieder viel zu viel Arbeit haben. - Qualitätsverlust
In wenig Zeit muss sehr viel auf einmal getestet werden – es bleibt weniger Zeit für einzelne Details. - Negative Wirkung auf die Team-Stimmung
Features und Stories können nicht den Stakeholdern präsentiert werden, weil sie nur zu 80% fertig sind. - Unzufriedene Stakeholder
Vertrauensverlust und in Frage stellen der Verlässlichkeit, weil nicht regelmässig Resultate geliefert werden und Stakeholder somit weniger oft Feedback geben können. Und das obwohl das Team eigentlich einen anständigen Pace an den Tag legt.
Abbildung 1 zeigt, dass grosse Features oder Stories dem frühen Feedback von Stakeholdern im Weg stehen. Sowohl bei der linken, wie auch bei der rechten Abbildung wurde der gleiche Umfang des eingeplanten Scopes umgesetzt. Aufgrund der kleineren Stories kann aber bei der rechten Abbildung viel mehr im Sprint Review gezeigt werden. Dies führt zu zufriedenen Teilnehmern in der Review, besserer Qualität durch regelmässig ausgelastete Tester und hat auch auf die Entwickler eine motivierende Wirkung.
Abbildung 1: Vergleich von grossen und kleinen Artefakten
Gründe für zu grosse Artefakte gibt es viele. Folgende konnte ich im Rahmen meiner Tätigkeit als agile RE Coach bis anhin beobachten:
- Prinzip Hoffnung
„Jetzt kennt sich das Team doch schon besser, nach 5 Sprints“, „Bei der anderen Funktion machen wir ja ein MVP, dann sparen wir dort Ressourcen“ oder ganz simpel „Das schafft das Team schon!“ Bei solchen Sätzen sollte man aufhorchen. Wenn bereits das Gefühl sagt, dass es knapp wird, dann besser ein Feature verkleinern oder ein anderes in der Roadmap nach hinten verschieben. - Die schöne Story
Man hat zwei Workshops organisiert, mit Stakeholdern verhandelt und nach dem SMART-Prinzip geschriebene Akzeptanzkriterien definiert. Wahrlich schön und vollkommen sieht sie aus, die User Story. Sie hat zwar schon an Umfang zugelegt während der Definition und mittlerweile 15 Akzeptanzkriterien – aber was für ein Mensch wäre man, wenn man so etwas Vollkommenes kaputt machen würde? Spass beiseite: Die Workshops waren wertvoll und so sind es auch die Akzeptanzkriterien. Nun muss man die Story aber splitten, so dass man zwei oder drei möglichst unabhängige User Stories erhält. Dieser Vorgang muss verinnerlicht und nicht als notwendiges Übel betrachtet werden. - Das „Jekami“
„Jekami“ steht für „Jeder kann mitmachen“. Keinem Product Owner käme es in den Sinn, Code zu schreiben. Schliesslich ist das ein Handwerk, dass erlernt werden muss. Und genauso ist das Requirements Engineering und somit das User Story schreiben ein Handwerk, das es zu professionalisieren gilt. Ganz nach dem Motto „Wo Schlechtes reingeht, kommt nichts Gutes raus“. Immer wieder erlebe ich, dass die Person Stories schreibt, die gerade Zeit hat. Dass die Stories dann in einer sehr variablen Qualität daher kommen, ist die logische Folge. Gerade zu wenig detaillierte und zu wenig spezifische User Stories führen nach dem Einplanen zu sehr viel Abklärungsbedarf und oftmals merkt man erst dann, dass der Scope viel zu gross ist. - Just-to-Late- anstatt Just-In-Time-Specification
Features werden in Release- oder PI-Plannings in für den nächsten Release oder Product Increment eingeplant. Wer denkt, man könne die Features dann am Planungsmeeting präzisieren und verbessern, liegt oftmals falsch. Zu aufwändig ist die Analyse oder das Erarbeiten von unterstützenden Artefakten wie Use Cases, UML-Modellen, User Journeys oder Wireframes – um nur einige zu nennen. Auch die User Stories für die ersten 1-2 Sprints des Product Increments sollten in hoher Qualität vorhanden sein. Die User Stories können durchaus vom Entwicklungsteam validiert, geschätzt und bei Bedarf geschnitten werden. Aber die Informationsgrundlage für einen erfolgreichen Start und ein vertrauensvolles Committment des Teams, sollten vorhanden sein.
Gründe für zu grosse User Stories gibt es also einige. Was kann man dagegen tun? Als erstes sollte man das agile Requirements Enginnering nicht unterschätzen, sondern als Spezialdisziplin anerkennen. Somit braucht es auch Spezialisten, wie die Product Owner und Requirements Engineers, die das Handwerk der Feature- und User Story-Definition beherrschen. Ist das nicht der Fall, gibt es diverse Ausbildugsmassnahmen wie z.B. Agile Requirements Engineering Kurse oder massgeschneiderte Workshops wie „User Stories definieren & schneiden“ bei der SwissQ Academy. Dabei wird gelernt, welche Informationen in welcher Detailtiefe zu welchem Zeitpunkt vorhanden sein müssen. Zudem wird vertieft auf das Thema „Feature- und Story Splitting“, also auf das Zerschneiden oder Zerkleinern von Features und Stories eingegangen. Abbildung 2 ist Teil des Agile Requirements Engineering Posters und zeigt auf, nach welchen Kriterien solch ein Splitting gemacht werden kann.
Abbildung 2: Splitting Varianten
Eine weitere wichtige Massnahme ist das Diskutieren der Qualität der agilen Artefakte und das Festlegen einer gewünschten Qualität. Oftmals wird das mit Hilfe einer Definition of Ready gemacht. Eine Defintion of Ready beschreibt, welche Art von Informationen und welche Detailtiefe in einem Feature respektive einer User Story vorhanden sein muss, damit diese eingeplant werden kann. So eine Definition of Ready wird vom ganzen Scrum Team erarbeitet. So haben auch die Empfänger der Features und Stories die Möglichkeit mitzureden. Viel wichtiger als eine niedergeschriebene Defintion of Ready ist aber, dass diese auch gelebt wird – und nicht irgendwo in einem Ordner verstaubt, sondern für alle ersichtlich gehalten wird.
Der wohl wichtigste Faktor für gute, umsetzbare agile Artefakte ist aber das richtige Verständnis für die Just-in-Time Specification. Die Verantwortlichen müssen verstehen, dass die Artefakte zum Zeitpunkt der Planung und des Team Committments bereit sein müssen. Nicht vorher und nicht danach. Sie müssen verstehen, dass es weder ein Problem noch eine Schande ist, wenn eine User Story am Anfang zu gross wird. So lange sie dann ohne Wenn und Aber in zwei oder drei Stories zerschnitten wird. Die Teams danken es mit einer gesteigerten Motivation, die aus den vielen Erfolgen in den Sprints und Product Increments entsteht.
