Warum ein Product Owner Produkt-Dekomposition beherrschen sollte

Geschrieben von Rudolf Gysi am 14.06.2019

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, dass sich ein Product Owner (PO) 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 einmal sehr gut, da damit klar ist, dass wir uns überlegen sollten, aus welchen Features das Produkt besteht. Damit geraten wir als PO weniger in 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, desto mehr kommt das Gefühl auf, dass 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 bei den PBI-Besprechungen immer wieder in den Flughöhen. 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, dass 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, dass einzelne Teammitglieder dieses Produktbewusstsein erlangt haben. Es ist jedoch fraglich, ob diese Produkvision vom ganzen Team geteilt wird.

Hier kommt die Idee der Produkt-Dekomposition in das Spiel. Das ganze Team muss verstehen, was vom 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.

Produktdekomposition - Vom Investthema zum Task

Übersicht Produkt-Dekomposition

Dabei wird das Produkt auf verschiedenen Stufen zerlegt. Zuoberst stehen die „Investitionsthemen“. 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 müssen 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.

Jahresplanung mit Investitions Themen

Jahresplanung mit Investitionsthemen

Eine Ebene darunter befinden sich die Epics. Wenn das Team die Investitionthemen gut geordnet hat, ist nun der PO mit dem Entwicklungsteam dran. Aus was bestehen die Investitionsthemen? Wie liefern wir den versprochenen Wert? Aus der Investitionsplanung ist ersichtlich, bis wann welches Produktelement geliefert werden sollte. Die Epics werden den Investitionthemen zugeordnet und in die Reihenfolge gebracht, von der das Team glaubt, dass sie die richtige sei. Wenn wir uns die Grösse eines Epics anschauen, sind das Arbeitselemente, welche in 1 bis 3 Monaten geliefert sein sollten. Das Team erkennt, wenn mehrere Epics zu einem Investitionsthema 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 seinen Stakeholdern und bearbeitet die neue Situation. Die Klärungen helfen dabei, das PBL richtig zu priorisieren und gegebenenfalls die Grösse eines Investitionsthemas oder dessen Liefertermin anzupassen.

Quartalsplanung mit Epics

Quartalsplanung mit Epics

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. 

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, dass der Wert vom Team verstanden wurde.

Sprintplanung mit Product Backlog Items (User Stories)

Sprintplanung mit Product Backlog Items (User Stories)

Die untere 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 Stakeholders oder des PO beschreiben und umsetzen können.

Sprint Board

Sprint Board

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, dass die Dialoge mit den unterschiedlichen Stakeholdern nicht gut geführt wurden. Dass 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 Unternehmensstrukturen ist dies wichtig.

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

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

Rudolf Gysi

Über den Autor

Rudolf Gysi

Auf der Suche nach immer besserer Qualität entdeckte ich vor vielen Jahren die agilen Methoden in der IT. Seit 2010 unterstütze ich Teams beim Erlernen von Scrum und Kanban. Als Mitgründer der agilen Bewegung in der Schweizer Bundesbahn (SBB) habe ich den Aufbau der Trainings, der Agile Community und der Agilen Transformation seit 2011 mitgestaltet.

2018 bin ich als Coach für agile Produktentwicklung bei DasScrumTeam eingestiegen. Jetzt geht es darum Agilität in das Business zu tragen und IT und Business zu einem Team zusammenwachsen zu lassen.