SOFA-Talk / Best Practices für das Scrum Refinement

Markus Stroh - 18.4.2019

Ich möchte Euch wieder einmal Impressionen aus unserem ARITHNEA-internen Austauschformat, dem SOFA-Talk, liefern. Das Scrum Open Forum ARITHNEA hat sich erneut in breiter Kollegen-Runde getroffen und sich im freien Austausch zu agilen Themen beschäftigt. Auf den beiden roten Sofas saßen diesmal Volker Bogacki (Projektleiter und Vertreter der Scrum Initiative), Kai Mütz (Entwickler), Christiane Röder (Entwickler) und ich selbst, Markus Stroh (Scrum Master, Vertreter der Scrum Initiative) und Zuschauer vor Ort sowie Remote.


Das Thema diesmal:

„Wie kommt die Story in das Product Backlog? – Best practices für Refinements“

Wie so oft begann der Kick-Off mit einem Blick in den Scrum Guide. Der sorgt an dieser Stelle nicht für viel Aufklärung. Fest steht, dass eine stetige Pflege des Product Backlogs passieren soll und muss. Zudem ist das Product Backlog als ein lebendiges Artefakt definiert, das solange Bestand hat, wie auch das Produkt besteht. Für die Aufwände dürfen wir bis zu 10% der Entwicklungskapazitäten investieren. Die Umsetzung an sich ist im Scrum Guide jedoch nicht vorgeschrieben oder skizziert.

Aus persönlichen Erfahrungswerten heraus und dem Austausch mit den Entwicklerkollegen wurde schnell klar, dass das Thema Refinement je nach Projekt unterschiedlich betrachtet wird und das durchaus sinnvoll sein kann. Während einige Projekte auf feste Termine in festen Zyklen setzen – beispielsweise jeden Dienstag und Donnerstag ein bis zwei Stunden – so gibt es in anderen Projekten eine flexiblere Vorgehensweise nach Bedarf oder mit einmaligen Terminen pro Sprint, die dann deutlich länger ausfallen. Nachdem wir diese Punkte ausführlich in der Runde ausdiskutiert hatten, kamen wir zu ein paar grundlegenden Erkenntnissen:

  • Es gibt erst einmal keine Vorgaben dazu im Scrum Guide.

  • Es wird in Projekten unterschiedlich gehandhabt und das ist auch durchaus sinnvoll.

  • Bestimmte Entwicklergruppen bevorzugen eher seltene, aber längere Termine. Wobei die meisten Entwicklergruppen häufiger mit kürzeren Refinements besser klar kommen, weil der Fokus mit der Zeit sinkt.

  • Sinnvolle Meetingräume und passendes Equipment erleichtern die Durchführung.

  • Letzte Erkenntnis, die mir heraushebenswert erscheint: Der Modus eines Refinements kann und sollte sich an der Projektsituation sinnvoll anpassen.

Ich möchte im Weiteren auf einzelne Themen gezielter eingehen und hoffentlich sinnvolle Lösungsansätze mitgeben.

 

Anpassen des Refinement-Modus an die aktuellen Projektgegebenheiten

Dieser Punkt erscheint mir von gravierender Wichtigkeit, weshalb ich gerne ein paar Sätze dazu verlieren möchte, was damit genau gemeint ist. Damit unsere Entwicklungsteams arbeiten können, brauchen sie ein volles Sprint Backlog, welches sich aus dem Product Backlog ableitet. Das bedeutet, dass das Product Backlog immer zu einem ausreichenden Grad befüllt und bereit zur Abarbeitung sein sollte. Zusätzlich sollte auch immer etwas Spielraum parat stehen, um auf Veränderungen im Sprint und Optionen zur Verbesserung des Durchsatzes reagieren zu können.

Entsprechend leitet sich daraus ab: Ist das Product Backlog leer, dann sollten – oder müssen – wir die Schlagzahl von Refinement-Terminen erhöhen, um sicherzustellen, dass der Projektablauf nicht gefährdet wird. Umgekehrt bedeutet das jedoch auch, dass wir in Zeiten wo das Product Backlog übermäßig voll mit vorbereiteten Items (meist User Stories) ist, auch die Anzahl unserer Termine herunterdrehen können, um mehr Effizienz und Fokus an die Entwicklerteams weiterreichen zu können.

Im Optimalfall pendelt sich irgendwann ein Vorgehen ein, das genügend Vorausplanung und Bewegungsspielraum bietet, dabei aber schlank und effizient bleibt. Denn was wir auch nicht wollen: Abfall produzieren. Sind Stories zu weit in die Zukunft „fertig“, so steigt auch die Gefahr, dass sich Details noch einmal ändern oder Features sogar gänzlich hinfällig werden. Abhängig von der Projektlaufzeit ist ein Planungshorizont von 1-2 Sprints auf jeden Fall erstrebenswert.

 

Vorbereitung mittels Pre-Refinements für mehr Effizienz

Wie bei den meisten Themen kann auch das Refinement von ein wenig Vorarbeit massiv profitieren. Da im Refinement im Optimalfall das komplette Entwicklungsteam anwesend ist, plus Product Owner oder delegierter Storyschreiber, merkt man schnell, dass Missverständnisse zu großen Zeitverlusten führen können. Damit das möglichst nicht passiert kann man mit Pre-Refinements eine Instanz vorschalten - am besten mit einem oder zwei Tagen Differenz zum eigentlichen Refinement – um dort mit dem Storyschreiber und 1-2 Experten aus dem Umsetzungsteam in eine Vorabklärung zu gehen. Gibt es noch generell offene Fragen? Gibt es Unsicherheiten beim Storyschreiber? Kann man Formulierungen vielleicht schon ein wenig konkretisieren und die Story mit einem Screenshot oder einem Wireframe auch visuell aufwerten? Gibt es Akzeptanzkriterien und sind diese auch grundlegend verständlich und korrekt? Mit dieser einfachen Vorgehensweise kann eine Story im Vorfeld enorm präzisiert werden und für weniger Verlustzeit in der großen Runde sorgen.

Wichtig: In dieser Runde sollten möglichst keine Lösungen am Team vorbei vorgegeben werden und es sollte auch keine „schnelle Vorabschätzung“ durchgeführt werden. Das sorgt sonst für falsche Erwartungshaltungen und könnte den Verlauf des eigentlichen Refinements nachhaltig (negativ) beeinflussen. Auch Experten können sich mal irren - deshalb gehen wir damit ja auch in die gesamte Runde - und eventuell kommen doch noch neue Punkte auf, die klären zu sind. Dann ist die Enttäuschung oft groß und es entsteht Unverständnis.

 

Team-Setup und Räume

Um Weiterhin einen positiven Ablauf herzustellen, sollten klare Meeting-Räume gebucht werden und Termine allen bekannt sein. Im Optimalfall sind es sich wiederholende Zyklen, die so Teil des gewohnten Tagesablaufs werden. Vom Arbeitsplatz getrennte Meetingräume sorgen für Fokus und reduzieren Ablenkungspotentiale.

In verteilten Teams ist Sharing-Ausstattung von Vorteil, ebenso wie gute Mikrofone oder Telefonspinnen. Wenn alle Seiten ihre Webcam zusätzlich aktivieren, dann hilft das frühzeitig zu erkennen, ob es noch Unklarheiten gibt oder wo ein Kollege zu Wort kommen möchte. Die allgemeine Transparenz wird dadurch gesteigert.

Wie bereits erwähnt sollte das komplette Team anwesend sein. Denn möglicherweise haben Kollegen unterschiedliche Erfahrungswerte, die sie einbringen können, oder sehen Risiken, die ansonsten verborgen blieben. Die investierten Aufwände rechnen sich häufig massiv in der Umsetzung. Ein Moderator, beispielsweise der Scrum Master, sollte immer dabei sein und für sauberen Gesprächsfluss sorgen, Punkte auch noch einmal kritisch hinterfragen und auf die Storyqualität im Generellen achten.

 

Durch Timeboxen noch einen Gang höher schalten – „Slotting“

Im sogenannten „Slotting“ führt man Timeboxen ein, für die sich Storyschreiber anmelden können. Diese können beispielsweise 15 Minuten groß sein und für eine Story sollte im Optimalfall ein Slot genügen, für komplexere Themen vielleicht mal zwei. Durch vorzeitige Anmeldung haben die Storyschreiber eine klare Deadline, das Team kann sich vorbereiten und wir haben – ganz wie sonst auch bei Scrum – klare Zeitfenster, die uns helfen effizient zu bleiben. Alle Anwesenden sollten auf die Zeit achten, eine knappe und fokussierte Vorstellung mit anschließender Besprechung der Fragen kann ebenfalls positiv zuarbeiten. Wird die Timebox gerissen, dann sollte innerhalb von 1-2 Minuten entschieden werden, ob man zeitnah zu einem sinnvollen Ergebnis kommt oder die Story noch so unklar ist, dass sie noch einmal getrennt besprochen beziehungsweise ausgearbeitet werden muss.

Das Vorgehen ist anstrengend und erfordert eine hohe Disziplin bei allen Teilnehmern. Ein konsequenter Moderator ist dringend empfehlenswert. Der Lohn der Übung sind sehr effiziente Refinements ohne viele Reibungsverluste, denn alle lernen im Verlauf der Zeit dazu und der Ablauf wird immer runder.

Hier ein kleines Beispiel von Slotplanungen, in die sich die Storyschreiber frühzeitig eintragen sollten:

 

Zeitslot Story Storyschreiber EST
14:00 – 14:15 US – Flyout Navigation Lydia  
14:15 – 14:30 US – Anonymous Cart Checkout Peter  
14:30 – 14:45 US – Simple user data migration Ingo  

 

Viel Erfolg beim Ausprobieren im eigenen Alltag!

Take-away

Refinements sind ein essentielles und wichtiges Thema in Scrum, obgleich im Scrum Guide selbst erst einmal wenige Vorgaben (oder Hilfstellungen) gegeben werden. Die hier beschriebenen Schritte haben sich für uns als praktikabel herausgestellt und fanden in der Diskussionsrunde generell Zuspruch. Natürlich gibt es auch hier in jedem Team und Projekt Feinheiten die man beachten und gegebenenfalls justieren sollte.

 

Tags: Agile Business - Beratung & Strategie - Inside-ARITHNEA

Kommentar

newsletter-phone

Arithnea Newsletter

Ob Technikhotline oder virtueller Bankberater – dank innovativer KI-Technologien erobern sich Chatbots zunehmend breite Anwendungsfelder. Der Unterschied zwischen menschlichem und digitalem Ansprechpartner wird dabei immer weniger wahrnehmbar.