Improving the flow – User Stories im Feature Breakdown erstellen und schätzen

Die ganz normalen Probleme von Refinements

Ein Team, in dem ich Scrum Master war, hatte immer wieder Probleme in den Refinements. Die User Stories waren schlecht geschnitten und oft fehlte auch eine Story in einem bestimmten Kontext, um den vollen Mehrwert für die Nutzer*innen liefern zu können. Entsprechend hatten unsere Refinementmeetings die Tendenz, immer länger und detailreicher zu werden, während gleichsam geschriebene Stories komplett verworfen, umgeschrieben und wieder zusammengelegt wurden. Egal wie sehr wir an unserem Refinementprozess geschraubt haben (Behavioral Driven Development, Three-Amigos-Meetings, mehrstufige QA-Checks vor den Refinementmeetings…), wir waren immer entweder unzufrieden mit der Geschwindigkeit in unseren Meetings und/oder mit der Qualität und Sinnhaftigkeit unserer User Stories.

Zudem hatten wir Stakeholder und Geldgeber aus dem Konzernumfeld im Projekt, die weit in die Zukunft blicken wollten: Wann wird ihr gewünschtes Feature ungefähr fertig? Wie teuer wird es wohl sein? Und die Antwort auf diese Fragen sollten am besten kurzfristig geliefert werden – natürlich ohne eine konkrete Beschreibung des Features zu haben. Wir sind ja »ädscheil« unterwegs. Die Liste von refineten Stories in unserem Backlog, die vielleicht die nächsten zwei bis drei Monate abgebildet hat, reichte ihnen häufig nicht aus. Sie wollten rollierend in die nächsten 6-12 Monate schauen können.

Für mich als Scrum Master war bei diesen Problemstellungen klar: Wenn wir die Stakeholder nicht überzeugen können, dass wir nur valide Aussagen für die nahe Zukunft treffen können, dann müssen wir neue Wege suchen.

Fail #1: Virtuelle Währungen helfen… bedingt!

Wir hatten Schätzungen in Story Points (SP) etabliert. Dafür benutzten wir eine leicht abgewandelte Fibonacci Skala im Planning Poker (Werte von 1, 2, 3, 5, 8, 13, 21, 34, 55 und 100), um Größenverhältnisse und Unsicherheiten abzubilden. Das funktionierte auch relativ gut (Wortspiel beabsichtigt), zumindest für User Stories. Auf Featureebene (man könnte es auch »Epic« nennen) war das schon schwieriger. In einem ersten Workshop probierten wir Schätzungen solcher Features mit Story Points in der Fibonacci Skala multipliziert mit 10 aus (also 10 SP, 20 SP, 30 SP, 50 SP…), um die Größen besser abbilden zu können. Entsprechend skalierten auch die Unsicherheiten und niemand wusste so richtig, ob die jeweilige Schätzung halbwegs valide war.

Da kam uns ein Gedanke: Wenn Features die Metaebene zu User Stories sind, dann wäre eine Abstraktionsebene zu Story Points doch Feature Points! Wir probierten also analog zu Story Points die Einführung einer weiteren virtuellen Währung, den Feature Points, aus.

Ohne lange zu schwafeln: Das hat nicht geklappt. Natürlich kann ein Team in Feature Points, Gummipunkten oder Giraffenhälsen schätzen. Die Übertragung auf “Was bedeutet das für unsere Planung?” gelang uns jedoch nicht. Es ist schon schwierig genug, mit Story Points einen zweiwöchigen Sprint halbwegs valide zu planen. Feature Points und ihr weiteres Abstraktionslevel haben bereits eine lineare Übersetzung in Story Points unmöglich gemacht. Entsprechend konnten wir keine Erkenntnisse über mehrere Monate hinweg daraus gewinnen. Mit dieser zweiten Gewichtseinheit für Arbeitspakete konnten wir unsere Planbarkeit nicht erhöhen und haben die Idee wieder verworfen.

Unsere Lösung: Feature Breakdown

Die Herausforderungen blieben bestehen:
1. Unsere Stakeholder wollen früh grob wissen, wie teuer (Zeit/Geld) ein Feature wird.
2. Wir wollen gute User Stories in unserem Fluss von Arbeitspaketen erhalten.

Wir versuchten einen neuen Ansatz, erstmal weg von Story Points. Unsere Annahme war, dass sich die Größen von User Stories in einem Feature gut genug mitteln, um allein durch ihre Anzahl Rückschlüsse auf die prognostizierte Dauer zu erhalten (in Anlehnung an »No Estimates«). Entsprechend haben wir ein Meetingformat entwickelt, das mit wenigen Teilnehmenden und engem Timeboxing das Herunterbrechen eines Features auf mehrere Storyüberschriften erlaubt.

Im Feature Breakdown stellt der PO, oder noch besser der jeweilige Stakeholder, kurz ein Feature vor. Es werden nur die wichtigsten Nachfragen vom Team gestellt und im Anschluss starten die Entwickler*innen und Fachexpert*innen sofort in Stillarbeit und für alle sichtbar damit, auf Stickies Überschriften für potentielle User Stories zu erstellen. Im Anschluss betrachten alle die Sammlung, clustern bei Bedarf und ergänzen noch minimal. Alle Phasen wurden in eine Timebox von insgesamt 5 Minuten gepresst. Das war vor allem bei der Einführung eine Herausforderung für die Moderator*in.

Bei uns hatten kleine Features etwa drei Stories, gigantische Features bis zu 25 Stories! Um ein begründetes Bauchgefühl für die Größe eines Features noch zu festigen, haben wir doch wieder eine neue Währung eingeführt, nämlich T-Shirt Größen. Wir hatten allerdings aus unserem Fehler bei Feature Points gelernt und diesmal direkt mit einer groben Übersetzung und Story Points gearbeitet. Unser Ziel war es, von einer filigranen Schätzung der Fibonacci Story Points auf gröbere Sammelbecken für die bereits bekannten Größen zu kommen. Die Entwickler*innen haben, nachdem sie die Storyüberschriften erstellt haben, jeweils für das gesamte Feature auf eins dieser T-Shirts gevotet. Dokumentiert haben wir dann meistens den Mittelwert bzw. den ungefähren Median der Abstimmung. Wir wollten keine intensiven Diskussionen, sondern eben ein kollektives und schnelles Bauchgefühl erfragen.

Wie aus Überschriften Aufgaben werden

Sobald der nun beschätzte Aufwand zu dem jeweiligen Nutzen für die Stakeholder in einem guten Verhältnis standen, wurde die jeweilige Story für die weitere Verarbeitung im Team freigegeben. Aus Storyüberschriften werden am besten User Stories, wenn sich alle Teilnehmenden jeweils im Nachgang um eine handvoll Stories kümmern und eine Patenschaft dafür übernehmen. Wir hatten keine dedizierten Requirements Engineers, sondern haben die meisten Aufgaben crossfunktional im Team verteilt. Bei uns beinhaltete das, eine echte User Story Formulierung in die Beschreibung aufzunehmen, Akzeptanzkriterien zu formulieren und die Story aufbereitet nochmal dem ganzen Team in einem Refinementmeeting zu präsentieren, damit wir schlussendlich auch unsere gewohnten Story Point Schätzungen für jede Story, und nicht nur für das Feature haben. Hier konnten wir dann auch kontrollieren, ob unsere ursprüngliche T-Shirt Schätzung mit der handfesteren, auf User Stories basierten Schätzung überein kam. Bei uns war das in ca. 75% der Fall.

Bei ganz großen Features haben wir gelegentlich ein anderes Format des Refinements gewählt und frisch gefundene User Stories auf unser Architekturdiagramm gemappt, arbeitsteilig und zeitgleich User Stories ausformuliert und schließlich mit Magic Estimation nach ihrem Effort sortiert. Dadurch waren wir in der Lage, in einem einstündigen Meeting 25 User Stories zu refinen und zu schätzen, wofür wir in unserem regulären Modus knapp 8 Refinementmeetings und 16 Stunden gebraucht hätten. Diese Geschwindigkeit war nur erreichbar, weil wir uns in diesem Format nicht mit Implementierungsdetails beschäftigt haben und lediglich die grobe visuelle Zuordnung einer Story zu unserer Architektur Hinweise auf Abhängigkeiten und zu verwendende Technologien gab.

Die konkrete Umsetzung einer Story wurde natürlich erst im Sprint Planning Topic 3 vorgenommen, meist mit dem frisch entwickelten Change Planning Model.

Outcome: Viel Licht und etwas Schatten

Mit dem Vorgang der Feature Breakdowns konnten wir unsere Ziele erreichen: Wir bekamen gute Stories in unseren Refinementflow und unsere Stakeholder erhielten leichtgewichtig grobe Schätzungen für zukünftige Features.

Das Engagement der Stakeholder in den Prozess hat aber auch noch andere Effekte gezeigt. Während unser Product Owner von ihnen früher häufig nur eine nichtssagende Liste von Einträgen aus konzernigen Excellisten erhalten hat, die mehr Fragen als Antworten lieferten, mussten nun Stakeholder neben Überschriften auch Vision und Zweck ihrer Features vermitteln. Sie erhielten damit Verantwortung für ihre eigene Vorbereitung und das schaffte stärkere Verbindlichkeiten in unserer Zusammenarbeit. Es zeigte den Stakeholdern auch, dass je realistischer eine Schätzung für sie sein soll, desto mehr Arbeit in den Schätzprozess investiert werden muss. Auch von ihnen. Wir konnten durch den direkten Dialog zwischen Stakeholdern und Scrum Team das Glaskugelstoryschreiben ablösen und handfeste User Stories erstellen.

Negative Konsequenzen unseres Feature Breakdown möchte ich hier allerdings nicht vorenthalten: Dadurch, dass wir so schnell auch grobe Ideen diverser Stakeholder in unseren Refinementprozess aufnehmen und schätzen konnten, wurde unser System schneller gefüllt, als wir es abarbeiten konnten. Unser Backlog hat sich aufgebläht und viele Stories, die nach unserer Definition of Ready auch »Ready for Sprint« waren, wurden wieder runter priorisiert, bis sie vielleicht irgendwann sogar überflüssig wurden. Aus meiner Erfahrung haben Story Punkte auch immer eine Halbwertszeit und lassen sich nur gut mit der Arbeit der letzten 8-14 Wochen vergleichen. Zu alte Schätzungen verlieren ihre Validität im Vergleich zu neueren Schätzungen und Aufgaben. Stories, die wir so intensiv vorbereiteten und dennoch lange liegen geblieben sind, erzeugten Aufwand bei ihrer erneuten Aufbereitung. Anders gesagt: Wir haben Waste produziert, weil wir die Tendenz hatten, zu weit in die Zukunft zu schauen und damit unseren Fokus verloren haben. Und zwar so stark, dass einige Dinge irgendwann auch ihre Relevanz für das Produkt verloren haben.

Für die Zukunft halte ich das Vorgehen immer noch für sehr schnell und erfolgreich, wenn man zusätzlich die beiden Regeln verfolgt, die Mike Cohn kürzlich in einem Trainingsvideo zu Story Point Estimations aufgestellt hat:

1. Only Estimate when the estimate will be used to make a decision.
2. Don’t estimate items that are so far down the product backlog. Their estimates are inconsequential.