Der Standardlebenszyklus eines ScrumTeams beginnt mit dem Startschuss einer Produktentwicklung.
Die meisten Unternehmen starten ihre agilen Experimente jedoch nicht gleichzeitig mit neuen Produkten, sondern migrieren alte Produktentwicklungen und Projekte hin zu Scrum.
Der Grund ist meist, dass man nicht mehr zufrieden mit den Erfolgen ist, welche eine andere Entwicklungsmethodik brachte. Wegkommen wollen diese Teams meist nicht vom „Wasserfall“-Modell, sondern viel mehr einer Methodik, welche sich am ehesten mit „Chaos-Entwicklung“ beschreiben lässt. Ein Team reagiert auf Zuruf, die Priorisierung von Themen wird meistens nach „Wer schreit am lautesten“ getätigt, und so richtig weiß eigentlich keiner, in welche Richtung es geht.
Doch wie gelingt nun der Wechsel von „Chaos“ hin zu Scrum? Und vor allem: wie erstelle ich ein erstes legitimes Product Backlog für diese Teams?
Eine Geschichte aus der Praxis
Genau diese zweite Frage beschäftigte mich kürzlich bei einem Kunden. Wie oben beschrieben gab es ein kleines Team (wir nennen sie nachfolgend die Biber) bestehend aus 4 Entwicklern und 2 Requirements Engineers. Auf dem selben Stockwerk wie dieses Team saß eines meiner ScrumTeams, welches durch einen (meiner besten) ScrumMaster betreut wurde. Nicht selten fragten die Biber meinen ScrumMaster oder mich in meiner Rolle als Agilen Coach, wie sie dies oder jenes umsetzen könnten; was ein agiler Weg für eine bestimmte Herausforderung wäre; oder wie sie ein schwieriges Meeting vorbereiten könnten.
Dass sie eigentlich auch gern Scrum ausprobieren wollten, war klar.
Long story short – nach 3 Monaten war es soweit. Gemeinsam mit meinem ScrumMaster gestalteten wir ein 2-tägiges Scrum Grundlagen Training, brachten die Biber auf ein Scrum Shu Level und starteten gemeinsam den ersten Sprint.
Recht schnell wurde jedoch klar, dass es kein geregeltes, geschweige denn sortiertes Product Backlog gab und Anforderungen von allen Seiten kamen. So führte ich folgenden Workshop mit ihnen durch:
Initial Product Backlog Creation Workshop
Fancy Name oder? Nur nicht ganz eingängig.
Wie lief dieser Workshop nun ab? Gemeinsam im Raum versammelten wir 4 verschiedene Parteien. Zum einen hatten wir die Moderatoren: Meinen ScrumMaster (als Feedbackgeber und Emotionenfühler) und mich, die Entwickler, die Requirements Enginners, aus denen sich im Nachgang auch ein Product Owner bilden sollte und die Wichtigsten; die Stakeholder.
Nacheinander schauten wir uns all die Aufgaben, die aktuell auf dem Tableau lagen, an und bewerteten diese.
Zuallererst fragte ich die Teilnehmer, ob sie eine Anforderung hätten, welche sowohl aus Wert als auch aus Aufwandssicht einfach einzuschätzen wäre. Recht schnell konnten sich die Beteiligten auf ein Item einigen.
Ich bat sie, das Item als Wert: 5, Aufwand: 3 anzusehen. Warum gerade 3 und 5? Mir war danach. Welches Item man nimmt und welchen Grundwert man für die folgenden Schätzungen nimmt, ist relativ egal. Hauptsache man hat einen Grundstock, welcher einem ermöglicht, den ganzen Rest ins Verhältnis zu setzen.
Jeder Teilnehmer in der Runde bekam ein Set Planning Poker Karten. Die Stakeholder und Requirement Engineers hatten die Aufgabe, mit einem „Wert“-Fokus zu schätzen. Die Entwickler hingegen (geschult im Umgang mit Storypoints) sollten den Aufwand/die Komplexität schätzen (Mehr dazu hier in diesem Beitrag).
Bei Unstimmigkeiten und größeren Differenzen diskutierten wir über die einzelnen Items. Sei es weil der Wert einen überraschenden Ausbrecher hat oder ein Entwickler ein Item deutlich größer geschätzt hat.
Nach ca. einer Stunde entstand somit nach und nach das obige Bild.
Da weder eine Priorisierung nur nach Wert, noch nur nach Aufwand sinnvoll wäre, zogen wir gemeinsam 4 Linien, welche unsere neue Priorisierung vorgab: von oben links nach unten rechts.
Das Team hatte sich somit eine Grundlage für ihr weiteres Arbeiten geschaffen und konnte fortan neue Anforderungen direkt in der bestehenden Priorisierung einordnen.
Auf die Frage, welches die größten Erfolgsfaktoren für die Biber waren, nannten sie neben der professionellen Begleitung auch das initiale Training, um alle Mitglieder auf den gleichen Stand zu bringen und somit gut gewappnet zu starten. Wenn du diesen Erfolgsfaktor auch nutzen möchtest, schau doch mal hier vorbei oder schreib uns für ein internes Teamtraining direkt an unter info@emendare.de.