Produkt Dekomposition: Warum ein Product Owner das Thema beherrschen sollte.

Wer im Internet nach dem Begriff „Produkt Dekomposition“ sucht wird im Moment nicht sehr viele Treffer landen. Jedenfalls nicht im dem Zusammenhang wie er in der Agile Produktentwicklung verwendet wird.

Gemäss Wikipedia ist der Begriff in der Informatik folgendermassen definiert:„Sequentielle Zerlegung eines Systems in seine Teilfunktionen.“

Im wesentlichen geht es darum, das sich ein Product Owner (PO) sich damit auseinandersetzt wie er sein Produkt an den Markt bringen möchte. Natürlich gibt es dazu in den entsprechenden Foren und Medien sehr viele Praktiken und Prinzipien die helfen sollen das Produkt gut zu schneiden.

Schauen wir hier einmal die Produkt Dekomposition an. Ausgehend von der Definition zerlegen wir das Produkt in Teilfunktionen. Das ist schon mal sehr gut, da damit klar ist das wir uns überlegen sollten aus welchen Features das Produkt besteht. Damit geraten wir als PO weniger in die Versuchung das Produkt in Komponenten zu zerlegen.

In den Planning Sessions überlegen nun der PO und das Entwicklerteam wie sie das Produkt produzieren und ausliefern sollen. Dabei werden die Funktionen zerlegt und geschätzt. Die entstandenen Backlog Items (PBI) werden dann auch noch sauber im Product Backlog (PBL) nach Wert oder Komplexität eingeordnet. Wir sind bereit für den Sprint.

Je mehr Sprints vergehen kommt das Gefühl auf, das die Produktentwicklung wenig zielgerichtet ist. Was ist jetzt wichtig?
Haben wir die richtigen Dinge priorisiert? Warum kriegen wir diese User Story (US) nicht fertig?
Werden wir das Minimal Viable Product (MVP) auch wirklich hinkriegen?
Das Team diskutiert und schätzt und ordnet. Das Gefühl von Unsicherheit wird nicht kleiner.

Diese Teamszenen kann man als Coach fast jeden Tag in einem Team erleben.
Der PO hat den Top Stakeholder versprochen zu liefern, das Team will seine Zusagen einhalten. Die Dialoge in den Plannings und Refinements werden hitziger. PO und Team verlieren sich immer wieder in den Flughöhen bei den PBI Besprechungen. Einmal diskutiert man auf dem atomaren Niveau einer Funktion. Danach prägen Philosophische Exkurse den Dialog im Team.
Das Meeting geht zu Ende und man einigt sich hurtig auf die Reihenfolge im PBL und die Schätzungen. Natürlich verläuft der nächste Sprint nicht besser. Natürlich müssen wir besser planen, schätzen und priorisieren. Die Definition of Done (DoD) war ja eigentlich auch nicht so klar. Hat jemand die Akzeptanzkriterien der Story gelesen?

Warum passieren diese Szenen in fast jedem Team?
Ich vermute das der Fokus fehlt und sich das Team mit dem PO zu wenig um die Planungsaspekte der Agilen Produktentwicklung kümmert. Das Bewusstsein, wie sich das Produkt zusammensetzt, in welcher zeitlichen Abfolge Was geliefert werden sollte und die Grösse der Produktfunktionen ist oft nicht klar. Es ist möglich, das einzelne Teammitglieder dieses Produktbewusstsein erlangt haben. Es ist jedoch fraglich ob diese Produktinformation vom ganzen Team geteilt wird.

Hier kommt die Idee der Produkt Dekomposition in das Spiel. Das ganze Team muss verstehen was von dem Produkt zu welchem Zeitpunkt geliefert werden muss. Um diesen Dialog möglichst fokussiert und zielgerichtet führen zu können muss das ganze Team verstanden haben wie das Produkt zerlegt wird.

Dabei wird das Produkt auf verschiedenen Stufen zerlegt. Zuoberst stehen die „Investitions Themen“. Ich Nenne die so, da auf dieser Flughöhe vor allem Stakeholder miteinander sprechen die von der Technologie oder den Details nicht so viel wissen. Das müssen sie auch nicht. Es geht um eine langfristige Ausrichtung und um strategische Themen. Diese Gruppe beschäftigt sich sehr stark mit dem „WAS“ und dem Markt. Dabei ist der Fokus auch auf finanzielle Themen gerichtet. Folgende Fragen interessieren:
Wie lange können wir am Markt mit dem MVP operieren?
Wann muss mindestens 1000 Kunden auf dem Produkt gebucht sein?
Wie messen wir den Erfolg?
Wann geht uns das Geld aus?
Wann müssen wir skalieren?
Diese Themen werden in einem Startup natürlich auch vom Team geführt. Da passiert dieser Dialog von selber. In grösseren Unternehmen sind an diesem Themenbereich meistens Menschen beteiligt die mit der Umsetzung direkt nichts zu tun haben.

Eine Ebene darunter befinden sich die Epics. Wenn das Team die Investition Themen gut geordnet hat ist nun der PO mit dem Entwicklungsteam dran. Aus was bestehen die Investition Themen. Wie liefern wir den versprochenen Wert? Aus der Investitionsplanung ist ersichtlich bis wann welches Produktelement geliefert werden sollte. Die Epics werden den Investition Themen zugeordnet und in die Reihenfolge gebracht welche das Team glaubt sei die richtige. Wenn wir uns die Grösse eines Epics anschauen sind das Arbeitselemente welche in 1 bis 3 Monaten geliefert sein sollten. Das Team erkenn, wenn mehrere Epics zu einem Investition Thema gehören und der gewünschte Release gefährdet wird. Das ist nun der richtige Zeitpunkt um mit dem PO zu reden und zu klären ob wirklich so viel geliefert werden soll. Der PO hat mit seinem Team zusammen gelernt und trägt die Informationen nun zu seinem Stakeholder und bearbeitet die neue Situation. Die Klärungen helfen dabei das PBL richtig zu priorisieren und gegebenenfalls die Grösse eines Investition Themas oder dessen Liefertermin anzupassen.

Die Ebene unter den Epics nenne ich die User Stories oder Product Backlog Items. Diese Arbeitsstücke sind einigermassen definiert. Das sind Elemente welche innerhalb eines Sprints geliefert werden sollen. Das heisst die maximale Aufwandschätzung sollte 4 Wochen nicht übersteigen. Sogar wenn das Team Kanban verwendet bin ich der Meinung das diese Produktelemente nicht grösser sein sollten. Ab hier macht eine Sprintplanung absolut Sinn. Hier muss auch Klarheit über das „WIE“ liefern wir diese Produktfunktion herrschen. Wenn der PO Epics zum Planning mitbringt sind die Basis-Philosophischen Dialoge schon ziemlich gut geführt.
Das Team weiss WAS der PO den Stakeholdern verprochen hat. Der Fokus der Dialoge liegt aus dem WIE liefern wir dieses Produktinkrement? Wenn das Team mit dem PO diskutiert warum das gebaut werden soll, dann ist es vermutlich besser den Sprint nicht mit einem Produktinkrement zu planen von dem nicht sicher ist das der Wert vom Team verstanden wurde.

Die unterste Ebene in der Produkt-Dekomposition wird durch die Tasks beschrieben. Das sind Arbeitselemente die zu einem Epic zählen und vom Aufwand 1 bis 3 Tage gross sein sollten. Diese Tasks sollte das Team unabhängig eines Stakeholder oder des PO beschreiben und umsetzen können.

Mit verschiedenen Teams habe ich bereits versucht mit dieser Methode mehr Fokus in die Plannings und Refinements zu bringen. Bisher habe ich sehr gute Erfahrungen damit gemacht. Wenn ein Team diese Strukturen legt, wird oft klar, das die Dialoge mit den unterschiedlichen Stakeholdern nicht gut geführt wurden. Das Erwartungen an Information und Produkt nicht geklärt wurden. Für mich ist dies eines der wichtigsten Lernelemente eines Teams. Klärt die Kommunikations-Strukturen. Werdet euch bewusst mit wem ihr über was sprechen müsst. Speziell für Teams in grösseren Unternehmens Strukturen ist dies wichtig.

Ein sehr guter Nebeneffekt sind die Fragen welche das Team nach oben in das Portfolio richtet. Muss das Investitions Thema wirklich so gross sein? Was gehört wirklich dazu? Es werden Verzichtsdialoge geführt um den tatsächlichen Wert des Produkt-inkrements zu klären.

Probiert die Idee der Produkt Dekomposition mal in euren Teams aus. Über Feedback oder Erfahrungen würden wir uns sehr freuen!