MVP-Backlog

Was steht im MVP-Backlog?

Nachdem die äussere und innere Struktur des Produktes geklärt ist, geht es jetzt darum das MVP-Produkt-Backlog aufzubauen. Ein Produkt-Backlog ist eine priorisierte Liste von Anforderungen, sogenannten Backlog-Items. Die einzelnen Backlog-Items sind sehr kurz gehalten und aus Sicht des Benutzers beschrieben.

Praktik und Beschreibung

Produktdekomposition klären

Zuerst muss die Produktdekomposition mit dem Team geklärt werden. Falls nötig müssen die Begriffe Epic, User Story und Produkt Backlog jetzt eingeführt werden.

 

Backlog-Items gemeinsam schreiben

Auf Basis der Story Map werden im Team die ersten Backlog-Items fürs MVP beschrieben. In den meisten Fällen werden dies Epic’s und User Stories sein. Hier kann eine Erarbeitung in Kleingruppen Sinn machen. Wichtig ist, alles anschliessend im Plenum zu teilen und zu finalisieren.

Ein Epic sollte so umfangreich sein, dass er in 1-3 Monaten fertiggestellt werden kann. Der genaue Wert muss mit dem Team auf der Produktdekomposition ausgehandelt werden. Eine User Story sollte so klein sein, dass sie in einer Iteration umgesetzt werden kann. Die Epic’s sowie die User Stories bilden nur den heutigen Stand des Irrtums ab. Ganz sicher werden sie noch oftmals vom Team / Produkt Owner angepasst werden müssen, bevor sie in die Produktentwicklung gehen. Dieses Wissen kann dem Team den Druck nehmen, gleich hier alles perfekt machen zu wollen.

 

Formulierung der Backlog-Items

Bei den Epic’s und den User Stories sollte die Satzstruktur (Als <Persona> will ich <Funktionalität>, damit ich <Nutzen>.) sowie  mindestens zwei Akzeptanzkriterien beschrieben werden. Gerne können parallel auch erste Visualisierungen von Modellen, Benutzeroberflächen etc. erstellt werden. Dies immer einfach mit Papier und Bleistift.

 

Das ganze MVP ins MVP-Backlog transportieren

Ich tendiere dazu jeweils das ganze MVP ins MVP-Backlog zu transportieren. Dies bedeutet ordentlich viel Arbeit für das Team. Es können locker 5-6 Epic's und dann 20 - 30 User Stories geschrieben werden müssen. Mir ist bewusst das dies "eigentlich" die Arbeit des Produkt Owner ist. Aber so kann ich sicherstellen, dass all das erarbeitete Wissen zum Produkt aus der Iteration Zero in die Backlog-Items gegossen werden. Wir sind mit der Praktik erst fertig, wenn alle Epic's und User Storis beschrieben sind.

 

Schätzen der Backlog-Items

Nach dem Formulieren der Backlog-Items werden sie gemeinsam geschätzt. Dies oft mit Planning-Poker-Karten und mit Story Points. Es werden unterschiedliche Schätzungen vorgenommen:

- Komplexität mit Story Points

- Business Value

- Technische Komplexität

- Fachliche Komplexität

etc.

Welche Schätzungen vorgenommen werden sollen muss das Team und der Produkt Owner vor dem Schätzen gemeinsam definieren.

 

Digitalisieren des MVP-Backlogs

Die Digitalisierung des MVP-Backlogs ist nicht mehr Teil der Iteration Zero. Macht aber durchaus Sinn, insbesondere bei verteilten Teams.

Beispiel aus der Praxis

Im Team aus der Medizinbranche haben wir damit gestartet das erste Epic für unsere primäre Persona zu beschreiben. Dabei haben wir auf der Story Map, welche uns ja als Basis dient, visualisiert, welche Post-It's in welchem Epic integriert werden.

Nach den ersten zwei Epic war die Methodik bekannt und wir haben in 3-er Gruppen die einzelnen Epics formuliert. Dies hat sicher 1 Stunde in anspruch genommen. Anschliessend haben wir alle Epic's einander vorgestellt und das Feedback des Plenums direkt integriert. Da wir das ganze auf Flipchart's gemacht haben, ging das sehr fix.

 

In einer weiteren Session haben wir dann aus den Epic's die User Stories geschrieben. Wobei wir hier gleich wie bei den Epics vorgegangen sind.

 

Es hat sich gezeicht, dass zuerst der Satz / die Beschreibung und dann die Akzeptanzkriterien formuliert werden.  Hier reichen zwei Akzeptanzkriterien aus. Erst zum Schluss soll dem Backlog-Item ein aussagekräftiger Titel verpasst werden.

Was steckt dahinter?

Prinzipien der agilen Produktentwicklung

Spätestens bei dieser Praktik müssen alle Teilnehmer die Prinzipien der agilen Produktentwicklung kennen. Was ist ein Produkt Backlog? Wie wird damit gearbeitet? Warum schreiben wir jetzt nur die Epic’s für das MVP? Was passiert mit all den anderen Anforderungen sie wir jetzt nicht beschreiben?

 

Erleichterter Start 

Ziel dieser Praktik ist, dass alle im Team wissen, was in den ersten paar Iterationen umgesetzt wird. Dies erleichtert den Start in die Produktentwicklung. Falls die (Software-) Produktentwickler beim dieser Praktik noch nicht im Team sind, macht es Sinn, die User Stories noch nicht zu Formulieren. Erst wenn dann das Team komplett ist, kann mit dem Ausformulieren der User Stories viel Wissen transportiert werden.

 

Alles wird auf Flipchart's erarbeitet

Indem alle Formulierungen der Backlog-Items auf Flipchart vorhanden sind, sind Anpassungen an den Backlog-Items im Workshop sehr einfach machbar. Dies wird auch notwendig sein, da erst durch den Prozess des Formulierens das Schneiden der Backlog-Items machbar wird. Digitale Backlogs sind gut und recht aber nicht hilfreich für eine interaktive Zusammenarbeit.

 

Anschlussfähigkeit an andere Projekt-Methoden

Falls die Produktentwicklung nicht agil mit Scrum stattfindet, kann hier auch ein beliebig anderes Arbeitsgefäss gemeinsam beschrieben werden. Wichtig ist, dies vor der Erarbeitung mit dem Team abzuklären und die Struktur von diesem Arbeitsgefäss festzulegen. Zudem müssen die Arbeitshierarchien festgelegt werden.