Eigentlich dachte ich, dass das Thema der Organisation einer Produktentwicklung schon lange durch ist. Aber ich musste feststellen, dass das meine «Bubble» Innensicht war. Deshalb habe ich hier mal die Grundzüge pragmatischer und trotzdem erfolgreicher Produktentwicklung aufgeschrieben. Und bei Fragen: einfach kommen.

Struktur in der agilen Produktentwicklung

Oft wird agil als ungeplant verstanden. Da bin ich aber ganz anderer Meinung und Verfechter von Roadmaps und Initatives und klaren Strukturen. Agil bedeutet nur, dass man nicht über ein Jahr hinweg stur die geplanten Arbeiten durchführt, sondern sich alle paar Wochen hinterfragt ob man das Richtige richtig tut. Klar, oder? Die meisten unerfahrenen Product Owner tun sich dann schwer den Wald vor lauter Bäumen zu sehen und die benötigte Struktur zu schaffen. Mein Tipp: Ich schlage immer sehr rasch ein paar grobe Eckpunkte als Initative ein. Eine Initative ist ein definierter Schwerpunkt in der Produktentwicklung für ein paar Monate. Beispiele für Initatives:

  • Launch eines Single Feature MVP in drei Monaten
  • Ausbau Product Led Growth in den nächsten sechs Monaten
  • Redesign des Frontend auf neues CI/CD bis Mitte Jahr

Da gibt dir und dem Team rasch einen Fokus in euerer Arbeit. Kann auch mal falsch sein, aber besser falsch als nichts. Sobald die Initative klar ist, stülpe ich Struktur über das Produkt. Die Struktur hilft mir, mich nicht in der Flut von Ideen zu verlieren. Halt wie man einen Elefanten isst: Stück nach Stück.

Dein Produkt kannst du in mehrere, sogenannte Epics unterteilen. Diese umfassen mehrere Funktionen, welche wiederum die eigentlichen Anforderungen in Form von Stories enthalten.

Ein konkretes Beispiel zum besseren Verständnis:

  • Produkt: Die Produktvision als Leitmotiv Beispiel: Ermögliche allen Mitarbeitenden, einen Arbeitsplatz zu reservieren und Arbeitskolleg*innen im Büro zu finden.
  • Epic: Die Ansammlung von Funktionalitäten innerhalb des Produkts Beispiel: Sitzplatzreservation
  • Feature: Eine einzelne Funktionalität im Epic Beispiel: Arbeitsplatz als Favorit speichern
  • Story: Funktionalität des Features (Beschreibung, wie sich das Feature für den Nutzer verhalten soll)

Beispiel: Als Mitarbeiter einer Firma möchte ich meine Lieblingsarbeitsplätze mit einem Klick zu einem Favoriten machen, damit ich auf meinem Dashboard eine Reservation mit einem Klick machen kann.
Die Story folgt dabei einer einfachen, aber sehr wertvollen Struktur (in englisch, da Entwickler oft weltweit verteilt arbeiten):

As a [user] I must/should be able to [functionality] such that I [value provided by functionality]

Du kannst dir vorstellen, dass du dein Produkt in dieser Struktur recht rasch in einzelnen Epic und Features definiert hast. Was dann oft der Fall ist, dass sich hinter einigen wenigen Features viele Stories verbergen.

Verantwortung und Prozesse in der agilen Produktentwicklung

Was ich leider oft auch sehe ist, dass das Tech Team gut nach Scrum organisiert ist und sein Planning im Griff hat, während im Business Team mit dem PO eher nach Best-Effort gearbeitet wird. Entsprechend fehlt es an Priorisierung, Klarheit der Arbeitsinhalte und die Effizienz schwächelt. Wenn dann das Tech Team noch richtig gut performed, ist das Business Team – auf Deutsch – im Scheiss. Sie liefern immer nur kurz vor knapp die Stories an das Tech Team und dadurch leidet die Produktequalität massiv. Deshalb müssen klare Verantwortlichkeiten und Prozesse etabliert werden.

Der grundsätzliche Ablauf in der agile Produktentwicklung funktioniert folgendermassen:

  1. Der Product Owner bricht sein Produkt in Epic und Features herunter und priorisiert diese dann im Backlog klar nach seinem Wunsch. Das Backlog ist eine Liste – oft in Jira gemacht – welche als zentrales Arbeitsmittel für die Produktentwicklung dient.
  2. Das Business Team, wo der Product Owner auch Teil davon ist, bricht diese Features dann in einzelne Stories mit entsprechenden Akzeptanzkriterien für das Testing herunter. Parallel entwickelt ein UX Designer die notwendigen Screens, beispielsweise im Figma, als Teil der Stories.
  3. Das Tech Team nimmt dann die fertig definierten Stories und entwickelt daraus den Produktbestandteil.

Damit das zeitlich und inhaltlich immer gut aufeinander abgestimmt passiert, gibt es aus Scrum heraus auch ein guter Vorschlag den ich immer wieder aufgreife. Dabei organisiere ich Business Sprints und Tech Sprints. Der Business Sprint liefert dabei zeitversetzt voraus die zu entwickelnden Stories. Damit das Business Team gut funktioniert, arbeite ich mit denselben Meetingstrukturen wie in Scrum:

  1. Im Sprint Planning wird, basierend auf dem priorisierten Backlog, soviel Arbeit in die nächsten zwei Wochen reingepackt wie nur möglich.
  2. Im Demo und Retro Meeting wird dem Product Owner das Ergebnis der Arbeit präsentiert. Also entweder die Stories und Designs oder das fertige Produkt durch das entsprechende Team. Zudem wird besprochen was gut funktioniert hat und wie das Team noch besser werden kann. Dadurch hat man automatisch eine selbstlernende Organisation kreiert. Nützlich, oder?
  3. Als Sync-Meeting zwischen den beiden Teams wird ein Refinement in der Mitte der zweiten Business Sprint Woche organisiert. Im Refinement kommen die Business und Tech Teams zusammen und das Tech Team stellt dabei dem Business Team Fragen über Fragen zu den Ergebnissen aus dem aktuellen Sprint. Das Ziel vom Meeting ist gegenseitige Klarheit für den nächsten Sprint zu schaffen. Ein gutes Mindset für die Techies: Fragen wie ein Vierjähriger: Warum? Warum? Warum? Warum? Warum?

Brennpunkt Product Owner

Als Product Owner bist du der Dreh- und Angelpunkt für die Teams. Neben der Produktvision, der Roadmap Planung und dem gesamten Stakeholder Management bist du auch noch in fast allen Meetings mit dabei. Du musst neben dem Tagesgeschäft die nahe und ferne Zukunft im Blick behalten und den Kundenwert des Produktes maximieren. Krass viel, oder? Damit du nicht völlig untergehst, empfehle ich dir, dich zeitlich klar zu organisieren. Die folgende Aufteilung der Zeit hat sich dabei für mich bewährt:

Und noch ein Wort zum Product Owner: Du bist das Aushängeschild des Teams und wirst von Kunden, Peers und Stakeholdern immer wieder mit Wünschen bombardiert. Nimm diese Ernst. Aber überlege gleichzeitig ob diese Inputs dich in deiner Initiative jetzt oder erst in sechs Monaten weiterbringen und entsprechend priorisiert werden müssen. Meine Standardantwort für Wünsche und Ideen ist deshalb immer:

Super, danke für deinen coolen Input. Ich nehme die Idee gerne ins Product Backlog auf und priorisiere diese gleichwertig mit dem Rest der Anforderungen.

Produktentwicklung für Fortgeschrittene

Klar, das was ich hier beschrieben habe ist nur die erste, grobe Struktur. Aber wenn du das richtig hast, dann bist du schon fast bei 80/20 angelangt. Die Teams die schon auf dem Level sind, quäle ich dann mit Themen wie Definition of Done, CI/CD Prozesse, Testabdeckung, Automatisierung bis hin zu Scrum of Scrums. Und aufmerksame Leserinnen und Leser haben spätestens hier gefragt wo denn der Scrum Master bleibt. In grossen Teams ist der Scrum Master unabdinglich aber in kleinen Teams, insbesondere Startups, wird diese Rolle implizit übernommen. Wenn du dich durch diesen Blogpost bis hierhin durchgearbeitet hast, wahrscheinlich sogar von dir. Cheers 😀

Agile Organisation product product owner produktentwicklung startup Venture Builder