Mein aktueller Kunde hat ein Stakeholder-Gremium, das sich regelmäßig trifft, um neue Anforderungen zu priorisieren, die das Entwicklungsteam baldmöglichst umsetzen soll. Es besteht aus Vertretern der relevanten Geschäftsbereiche, die jeweils mit einem Teil der Anforderungen im selben lauffähigen System zu unterschiedlichen Zeitpunkten „live“ gehen wollen. Die Stakeholder müssen sich also (trotz unterschiedlicher Interessen) auf einheitliche Priorität einigen, die der Product Owner dann dem Entwicklungsteam gegenüber vertritt.
Ausgangssituation: Priorität gemeinsam festlegen
Sich zu einigen ist nicht ganz einfach. Man muss dabei folgende Fragen gleichzeitig beantworten:
- Wie viel geschäftlichen Vorteil bringt mir ein bestimmtes Feature?
- Bin ich bereit, den geschätzten Entwicklungsaufwand zu genehmigen?
- Was meinen die anderen Stakeholder dazu?
- Kriegen wir einen Konsens hin, so dass wir besser zwei ganze anstelle von vier halben Features beauftragen können?
Gestern war ich beim ersten Treffen dieses Gremiums, eingeladen als Coach für agile Methoden und Produktivität. Um möglichst einfach auf einen Konsens über die Prioritäten zu kommen, spielten wir das Innovationsspiel Buy a feature. (Danke an Michael Mahlberg, der die Idee hatte, dieses Spiel zu nehmen!)
Der Product Owner stellte die Stories (Features) aus dem Product Backlog mit Hilfe von User Story Karten vor. Die Entwickler hatten den Aufwand für diese Stories vorher in Story Points abgeschätzt, der Product Owner hatte den Aufwand auf den Karten vermerkt.
Spielregeln
Die Spielregeln für „Buy a feature“ sind sehr einfach und wirkungsvoll:
- Jeder Stakeholder bekommt eine bestimmte Anzahl Münzen.
- Jedes Feature hat einen „Preis“, der durch den Entwicklungsaufwand bestimmt wird.
- Stakeholder „kaufen“ nun die Features, die sie für wichtig halten, indem sie die Münzen auf die Story-Karten legen. Da sie nicht alles kaufen können, müssen sie priorisieren.
- Wenn eine Karte so viele Münzen bekommen hat wie ihr Preis angibt, gilt sie als gekauft und kommt ans obere Ende des Product Backlogs.
Als Münzen eignen sich farbige Plättchen, wie sie im Flohspiel verwendet werden. Die gibt es im Spielzeuggeschäft auch einzeln zu kaufen, ca. 5 Cent pro Stück. Eine separate Farbe pro Geschäftsbereich ist günstig, dann können Spieler ihre Münzen auch wiederfinden und auf andere Features legen, um z.B. einen Konsens zu bekommen.
Die Randbedingungen hatte ich wie folgt gesetzt:
- Ich gab nur so viele Münzen aus wie Story-Points in den ersten Sprint passen, orientiert an der Velocity des Teams.
- Der Product Owner stellte ungefähr doppelt so viele Features vor wie in den Sprint passen, damit die Stakeholder genügend Auswahl hatten.
- Die Stakeholder aus einem Geschäftsbereich bekamen mehr Münzen als die anderen, weil der erste „Launch“ des neuen Systems im Wesentlichen die Belange dieses Geschäftsbereiches abdecken wird.
Der Ablauf des Spiels
Der Product Owner stellte die Features vor, jeweils als kurze Zusammenfassung der darin enthaltenen Funktionalität. Die Stakeholder stellten Fragen nach dem Inhalt, den Abhängigkeiten und der Abgrenzung der Features.
Danach bildeten die Geschäftsbereiche kleine Gruppen und diskutierten, welche Features für ihren Bereich Priorität bekommen sollten. Es bildete sich schnell eine diskutierende Traube von Leuten um die Karten, die auf dem Tisch lagen.
Nach ca. 10-15 Minuten begann der Sprecher des einen Geschäftsbereichs, seine Münzen auf die Features zu platzieren und argumentierte, warum er sich so entschieden hatte. Die anderen schlossen sich an und platzierten ebenfalls ihre Münzen. Da der Preis für manche Features zu hoch war, um durch einen einzelnen Bereich bezahlt zu werden, bildeten sich Allianzen um die Features, die als teuer und trotzdem wichtig erachtet wurden.
Eines der Features war besonders teuer, es handelte sich um die Entwicklung eines Grundkonzeptes, das für fast alle weiteren Sprints wichtig sein würde. Der Product Owner warb dafür, es trotz des hohen Preises zu kaufen. Einige Stakeholder argumentierten dagegen, mit der Begründung, je länger sie die lauffähigen Features testen könnten, die im ersten Sprint entstehen, umso besser. Ein Geschäftsbereich, dessen Launch-Datum noch weit in der Zukunft lag, sagte dann: „Für uns wäre dieses Feature extrem wichtig, doch ob das Konzept nun jetzt oder erst im nächsten Sprint kommt, ist uns egal. Wir stellen unser Geld deshalb den anderen zur Verfügung.“ Wer hätte das für möglich gehalten?
Zum Schluss blieben einige nur teilweise finanzierte Features übrig. Die Gruppe verteilte deren Münzen so, dass ganze Features gekauft werden konnten. Alle Münzen waren ausgegeben, zehn Features für den ersten Sprint standen damit fest.
Ich fragte noch nach der Priorität dieser Features untereinander, da das Spiel ja nur eine reine Ja/Nein-Aussage liefert. Diese Reihenfolge ergab sich sehr schnell aus den Feature-Abhängigkeiten und aus der Frage: „Wenn die Entwickler in Stress kommen sollten, welches Feature darf dann am ehesten aus dem Sprint fallen?“. Wir sortierten die Karten nach dieser Reihenfolge, das Ergebnis sah aus wie auf dem Foto links.
Feedback vor und nach dem Spiel
Für die Gruppe der Stakeholder war es neu, Entscheidungen in wichtigen Dingen mittels spielerischer Verfahren zu finden. Zwei meldeten vor Beginn des Spiels Bedenken an: „Sonst haben wir solche Entscheidungen immer durch Diskussion gefunden. Ich glaube nicht, dass wir so ein Spiel brauchen.“ Der Product Owner schlug vor, es erst einmal zu versuchen und falls es sich nicht bewährt, es wieder bleiben zu lassen. Ich erklärte, dass Diskussionen explizit erwünscht seien und niemand sofort kaufen müsse.
Nach dem Spiel fragte ich die Beteiligten nach ihrem Feedback. Es war einhellig positiv:
- „Die Visualisierung der Entscheidungen ist sehr gut.“
- „Man kommt sehr schnell zu einer Einigung.“
- „Es lockert diese Meetings auf und macht Spaß.“
Tja, da bleibt mir nur ein „Danke“ an die Erfinder dieses Spiels. Ich kann es wirklich empfehlen!
