Was statt Wie: So meistert Ihr Product Owner den Umgang mit dem Product Backlog

SMART DEVELOPMENT NEWS 02/2019

SDN 02/2019 - User Stories

von Dirk Meißner, Geschäftsführender Gesellschafter

 

Agile Führung und Arbeitsweisen bieten enorme Potenziale für die Entwicklung physischer Produkte unter unsicheren Markt- und Kundenanforderungen. Ein großes Effizienzpotenzial steckt in einer guten Klärung und einem gemeinsamen Verständnis der Produktanforderungen, die sich dann im Product Backlog widerspiegeln. Doch wie erstellt man einen zielführenden Product Backlog? Und wie schreibt man gute User Stories?

Die Schwierigkeiten im Umgang mit dem Product Backlog

Bei unserer Arbeit als agile Coaches erleben wir immer wieder, wie schwer es Product Ownern fällt, einen initialen Product Backlog zu schreiben und mit Backlog Refinement kontinuierlich zu pflegen. Meist waren die Product Owner vorher Projektleiter. Daher sind sie es gewohnt, die Planung für ihre Teams tätigkeitsorientiert zu erstellen.

Nun arbeiten ihre Development-Teams allerdings selbstorganisiert. Der Product Owner konzentriert und reduziert sich auf die Beschreibung des Was und überlässt seinem Development-Team die Beschreibung des Wie.

Dieser Perspektivwechsel erfordert einen neuen Fokus. Statt sich auf Tätigkeiten (Wie) zu konzentrieren, müssen Product Owner sich auf das Objekt und dessen Nutzen (Was) fokussieren. Nur so können sie Anforderungen sinnvoll priorisieren. Was ist für den Kunden wichtiger? Funktion 1, 2, oder 3? Verfügbarkeit? Lebensdauer? Und so weiter.

Ein Beispiel verdeutlicht den veränderten Fokus des Product Owners sehr treffend:

Stellen sie sich eine Torte vor. Beim klassischen Vorgehen nach Wasserfall-orientierter Planung schaffen Sie zuerst den Tortenboden, dann die Schichten und am Schluss die Verzierung. Bei agiler Vorgehensweise lieferen Sie Produktinkremente zu den vom Kunden am höchsten priorisierten Anforderungen möglichst früh, um Feedback zu erhalten. Sie liefern also möglichst schnell das erste vollständige Tortenstück.

SDN 02/2019 - Nutzenorientierte Planung im Product Backlog

Nutzenorientierte Planung im Product Backlog

Wie User Stories den Blick auf das „Was“ schärfen

Das User-Story-Template unterstützt diese Fokussierung. Der Product Owner versetzt sich in die Rolle des Kunden. Der Kunde, das können in diesem Fall verschiedene Persona-Kategorien sein, z. B. Endnutzer, OEM-Verantwortliche, Flotten-Manager, Kundendienst-Techniker, Montagemitarbeiter oder Einkäufer.

Die User Story wird nach einem bewährten Schema formuliert:

Als <Persona> will ich <Anforderung>, um <Nutzen>.

Es ist wichtig zu verstehen, dass Anforderungen an physische Produkte von verschiedenen Persona-Kategorien kommen können. Nur so werden wirklich alle Anforderungen im Product Backlog erfasst.

Die User Story wird um Acceptance Criteria ergänzt, die genau definieren, wann die User Story „Done“ ist. Diese Akzeptanzkriterien wirken User-Story-spezifisch in Ergänzung zu der User-Story-übergreifenden Definition of Done und sind extrem wichtig für die Anforderungsklärung.

Die User Story wird idealerweise so geschnitten, dass sie in einen Sprint passt. Sprintübergreifende User Stories nennen wir in Anlehnung an Skalierungs-Frameworks EPIC oder Feature. Oft ergeben sich dabei aus den Akzeptanzkriterien der jeweils übergeordneten Ebene die User Stories der nächsten Ebene. So auch im nachfolgenden Beispiel:

SDN 02/2019 - Detaillieren von Anforderungen

Beispiel eines EPIC, eines Features zu diesem EPIC sowie einer Story zu diesem Feature aus einem Vorentwicklungsprojekt zur Entwicklung einer neuen (hier nicht genannten) Technologie.

Nutzenorienterte User Stories in der Vor- und Serienentwicklung

In der Vorentwicklung fällt die nutzenorientierte Formulierung der Items im Product Backlog relativ leicht. Es geht vorrangig um den Nachweis der Funktionalität, der grundsätzlichen Herstellbarkeit und der Erreichbarkeit der Herstellkostenziele.

In der Serienentwicklung fällt die Nutzenorientierung bei der Formulierung der Product-Backlog-Items deutlich schwerer:

  • Neben den funktionalen Produktanforderungen müssen auch nicht-funktionale Produktanforderungen formuliert werden, wie Verfügbarkeit, Recyclingfähigkeit etc.
  • Neben den funktionalen und nicht-funktionalen Produktanforderungen kommen weitere Anforderungen aus dem Produktentstehungsprozess hinzu, wie Lieferantenauswahl, Montagekonzept etc. Für diese sind im Laufe der Serienentwicklung bis zum Serien- und Verkaufsstart Ergebnisse zu liefern.
  • Die Erfüllung der Anforderungen wird fast immer über mehrere Musterstufen hinweg nachgewiesen, die teilweise so vom Kunden vorgegeben sind (A-Muster, B-Muster, C-Muster).

In der Serienentwicklung können wir in einem hybriden Ansatz ein EPIC in Features zerlegen, z. B. den Musterstufen. Wir zerlegen das Projekt in Etappen, die den Phasen des Produktentstehungsprozesses entsprechen können. Product-Backlog-Items ordnen wir dann in einer übergeordneten Planung den Etappen zu. Die Darstellung ist dem Story Mapping also sehr ähnlich, hat aber zusätzlich eine eindeutige zeitliche Komponente.

SDN 02/2019 - Beispiel einer zeitlichen Aufplanung eines EPIC

Beispiel einer zeitlichen Aufplanung eines EPIC im Product Backlogs nach Etappen aus einem Projekt zur Entwicklung einer neuen elektronischen Waschmaschinensteuerung.

Fazit

Der Übergang von der tätigkeitsorientierten Planung hin zur nutzenorientierten Planung fällt Product Ownern in der Entwicklung physischer Produkte schwer. In den meisten Fällen benötigen sie hierfür eine intensive Anleitung durch Fachkräfte oder Berater, die bereits Erfahrung mit agilen Hardware-Projekten gesammelt haben.

Diese Hilfestellung sollten Sie Ihrem Product Owner auf gar keinen Fall verwehren. Nur wenn ihm diese wichtige Umstellung gelingt, sind eine wertorientierte Priorisierung der Product-Backlog-Items sowie eine klare Trennung zwischen WAS und WIE möglich.

Das User-Story-Format unterstützt die Formulierung der Anforderungen optimal. Während sich User Stories in der Vorentwicklung meist noch sehr gut formulieren lassen, ist dies in der Serienentwicklung jedoch deutlich anspruchsvoller. Zumal hier oft eine objektbezogene Ergebnisformulierung benötigt wird.