Scrum: Product Backlog – Organisation im agilen Projekt

Produktvision - Grundstein des Product Backlogs

Kernaufgabe des Product Owners ist, ein neues Produkt oder einen neuen Service kommerziell erfolgreich zu machen. Aus einer Produktidee entsteht die Produktvision. Sie skizziert das Große und Ganze und ist der Grundstein des Product Backlogs.

Die Produktvision hilft dem Produkt, das Licht der Welt zu erblicken, indem sie darstellt, warum das Unternehmen glaubt, dass das neue Produkt den Kunden begeistern wird. Sie formuliert Annahmen, welche Funktionen für den Kunden wichtig sind. Die Annahmen wurden durch Statistiken, Studien oder Markttrends bestätigt.

Im Mittelpunkt der Vision steht also das „Was“. Es beschreibt das Produkt und den Nutzwert für den Kunden. Die Vision beschreibt nicht, in welcher Art und Weise das Produkt entwickelt oder mit welchen Methoden, Werkzeugen oder Prozessen es realisiert werden soll.

Die Produktvision stellt sich unabhängig von der späteren technischen Lösung dar. Das Ziel des Product Owners ist es, dem Kunden die in der Produktvision versprochenen Funktionen zügig bereitzustellen.

Je schneller, desto besser, denn die Wettbewerber haben das gleiche Ziel. Time to Market, wer schafft es am schnellsten? Doch bei aller Eile darf der Produkt Owner dem Kunden nicht etwas versprechen, das er nicht einhalten kann. Er darf den Kunden nicht enttäuschen. Deshalb konzentriert er sich zunächst auf den Kern, die bekannten und wichtigsten Anforderungen, um im weiteren Projektverlauf, Sprint für Sprint, weitere Kundenwünsche zu realisieren.

Mit dieser Strategie erfüllt der Product Owner das Kundenversprechen. Dabei gilt der Grundsatz: Was bereits ausgeliefert wurde, muss funktionieren!

Merkmale des Product Backlogs

Im traditionellen Projektmanagement ist es das Lastenheft, welches alle Anforderungen des Kunden (Auftraggeber) an den Projektleiter (Auftragnehmer) beschreibt.

Das Lastenheft entsteht in der Anforderungsphase kurz nach der Initiierung des Projektes. „Die Anforderungen in einem Lastenheft sollten durch ihre Formulierung so allgemein wie möglich und so einschränkend wie nötig formuliert werden.

Hierdurch hat der Auftragnehmer die Möglichkeit, optimale Lösungen zu erarbeiten, ohne durch zu konkrete Anforderungen in seiner Lösungskompetenz eingeschränkt zu sein“, ist in Wikipedia über das Lastenheft zu finden.

Im agilen Projektmanagement sind Anforderungen im Product Backlog aufgelistet. Dieses zeichnet sich durch folgende Merkmale aus:

• Der agile Projektleiter nutzt unter anderem Scrum als Verfahren, das ursprünglich aus der Softwareentwicklung stammt. Die agile Arbeitstechnik kommt mit weinigen Regeln, Rollen und Artefakten aus. Das Product Backlog ist ein Artefakt. In der Archäologie sind Artefakte Gegenstände, die durch den Menschen erzeugt oder verändert wurden. In der Forensik, der Wissenschaft, in der kriminelle Handlungen systematisch untersucht werden, sind es Spuren, die in der Zeit zwischen der Tat und der Spurensicherung am Tatort (meist versehentlich) hinterlassen wurden. Für den Bereich Projektmanagement gilt: Artefakte dienen dazu, die Übersicht zu behalten, denn mit ihrer Hilfe überwachen Produkt Owner, Scrum Master und Entwicklerteam die Arbeitsergebnisse während eines Sprints.

• Der Product Owner ist für den kommerziellen Erfolg des Produktes verantwortlich. Deshalb sind Einträge im Backlog nach Priorität sortiert. Das Wichtigste steht am Anfang der Liste, das Entwicklerteam arbeitet das Wichtigste zuerst ab.

• Um welche Einträge handelt es sich? Hauptsächlich sind das User Storys. Sie beschreiben Anforderungen aus der Perspektive des Kunden. Je genauer der Product Owner die Kundenwünsche beschreibt, desto genauer kann das Entwicklerteam den Realisierungsaufwand schätzen.

• User Storys sind in unterschiedlichen Reifegraden formuliert. Einige sind detailliert spezifiziert, andere nur grob und unvollständig skizziert. Je kleiner und konkreter der Inhalt einer User Story ist, desto weiter oben in der Liste sollte sie stehen.

• Die Mitglieder des Entwicklerteams realisieren die User Storys im Backlog in einer Abfolge von Sprints. Während der Sprint-Planung entscheiden sie, wie viele Anforderungen im nächsten Sprint realisiert werden. Dafür nutzen sie ein Sprint Backlog.

• Schafft es das Team nicht, die für den Sprint geplanten Storys abzuarbeiten, kehren diese zurück ins Backlog. Sie werden dann in einem der folgenden Sprints fertiggestellt. Auch Fehler (Bugs) landen im Backlog. Beide Rückkehrer gelten als „nicht fertig“, weil sie nicht produktionsreif sind und deshalb nicht an den Kunden ausgeliefert werden konnten.

• Im Gegensatz zum traditionellen Lastenheft ist das Backlog ein lebendes Dokument, dessen Inhalte sich während des Projektes ständig ändern. User Storys, die gerade nicht im aktuellen Sprint realisiert werden, können ohne Weiteres verändert werden.

Sieben Tipps für Product Owner

1.    Das Backlog ist das wichtigste Werkzeug des Product Owners. Pflegen Sie es, halten Sie die Liste aktuell. Nutzen Sie dafür eine einfache Tabelle. Bei kleineren Vorhaben nutzen Sie einfache Klebezettel an der Wand.

2.    Versprechen Sie nichts, was Sie nicht halten können. Die Produktvision beschreibt das Produktversprechen als Großes und Ganzes. Es gibt dem Kunden eine Perspektive. Die Funktionen, die Sie ausliefern, müssen fehlerfrei funktionieren.

3.    Beachten Sie die Empfehlungen effizientes Anforderungsmanagement. Bleiben Sie im Anforderungsraum und beschreiben das „Was“. Widerstehen Sie der Versuchung, Lösungen vorzugeben. Delegieren Sie die Suche nach dem „Wie“ an das Entwicklerteam.

4.    Sobald Sie das Gefühl haben, dass Sie die wesentlichsten User Storys in Ihrer Liste gesammelt haben, fokussieren Sie sich auf diejenigen, die dem Kunden den größten Nutzen versprechen. Beschreiben Sie die Anforderungen so detailliert wie möglich. Je kleinteiliger sie sind, desto präziser kann das Team den Entwicklungsaufwand schätzen.

5.    Stehen Sie dem Team für Rückfragen zur Verfügung, insbesondere wenn es zu unterschiedlichen Interpretationen der Anforderungen kommt. Sorgen Sie für Klarheit. Schieben Sie alle anderen Aktivitäten zur Seite und beantworten die Fragen der Entwickler. Lassen Sie Ihre Vorstellungen direkt in die Entwicklungsarbeit einfließen. Vermeiden Sie Missverständnisse!

6.    Sorgen Sie dafür, dass sowohl Scrum Master, Entwicklerteam und Stakeholder Leserechte zum Product Backlog erhalten.

7.    Projektarbeit ist leider nicht frei von Fehlern (Bugs). Gehen Sie davon aus, dass es nach jedem Sprint zu Fehlersituationen kommen wird. Fehlerhafte Liefergegenstände kehren in das Product Backlog zurück.