This entry is part 3 of 4 in the series Agile Produktplanung

Das APP-Framework – Vorstellung

Die Agile Produktplanung (APP) basiert wie Scrum auf der empirischen Prozesssteuerung. Sie ist wie Scrum ein Framework, das bewusst unvollständig ist und Raum für situatives Lernen lässt. Es bietet die Essenz, die für ein einheitliches Verständnis von Anforderungen in komplexen Umfeldern notwendig ist. Wir beschreiten also mit APP einen Weg kontinuierlichen Lernens und Verbesserns.

APP folgt der Idee, den Feedback-Zyklus von der Vision bis zum lieferfähigen Inkrement möglichst oft und schnell zu durchlaufen. Jeder Sprint soll uns der Vision ein Stück näherbringen.

Für Transparenz sorgt eine kontinuierliche Planung über drei Ebenen hinweg. Die Planung wird durch die kontinuierliche Verfeinerung von Anforderungen unterstützt. Dabei müssen wir das Große und Ganze im Blick behalten, Optionen für die nächste Lieferung klären und just-in-time die Detailanforderungen für das nächste Inkrement spezifizieren.

Übersicht Agile Produktplanung APP

Nach der Umsetzung im Sprint, überprüfen wir das Inkrement und erfassen etwaige geänderte oder neue Anforderungen. Auch überprüfen wir das Vorgehen, den Umgang mit Anforderungen und passen ihn gegebenenfalls an.
Danach beschreiben wir jeweils Regeln, geeignete Artefakte, Praktiken und Ereignisse für die verschiedenen Prozessbausteine und die Zusammenarbeit.
Lassen Sie uns nun die einzelnen Prozessbausteine detaillierter beschreiben.

Das große Ganze im Blick haben

Eine Produktvision ist der Nordstern für die Entwicklung. Sie adressiert die Zielgruppe, die Kundenbedürfnisse und gibt die Richtung für alle Beteiligten an der Entwicklung vor. Sie sorgt für Motivation, als Team an einem Strang zu ziehen, um gemeinsam ein herausforderndes Ziel zu erreichen.

Die Produktvision ist der Ausgangspunkt für die Feedback-Schleife und damit für die kontinuierliche Verfeinerung. Hier beginnt die Stakeholder-Analyse und das Stakeholder-Management. Der relevante Kontext und die Systemgrenze werden definiert und adäquat dokumentiert, eine Schnittstellenbeschreibung zeigt die Abhängigkeiten des zu entwickelnden Systems von anderen Systemen.

Optionen für die nächste Lieferung klären

Agile Vorgehensweisen entkoppeln die Erstellung und die Lieferung von Systeminkrementen voneinander. Hier beantwortet der Product Owner die für ihn wichtigste Frage: Wann kann ich meinem Kunden das nächste Mal etwas Wertvolles liefern?

Die Planung der Lieferung kann dabei auch mehrere Sprints umfassen. Aber auch hier verzichten wir weitgehend auf Details der Anforderungen. Die Details und damit die Beschreibungstiefe der Anforderungen müssen so ausgestaltet sein, dass das Team versteht, welchen Wert die nächste Lieferung für die Anwender haben soll. 

Just-in-time Anforderungen für das nächste Inkrement klären

Hier ermitteln und dokumentieren wir die Details der Anforderungen für das nächste Inkrement.

Die klassische Anforderungsanalyse erstellen wir kontinuierlich im Rahmen des Refinements (Scrum Guide 2017: „Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Product Owner und das Entwicklungsteam gemeinsam die Product-Backlog-Einträge detaillieren.“) Dabei müssen wir die Anforderungen auf Machbarkeit, Nutzen und Geschäftswert, Risiko, Qualitätskriterien, Größe und Priorität untersuchen und bewerten.

Die Anforderungsanalyse umfasst also:

  • Anforderungen verfeinern
  • Machbarkeit analysieren
  • Nutzen und Geschäftswert ermitteln
  • Größe schätzen
  • Risiko bewerten
  • Qualität der Anforderungen verbessern
  • Konflikte und Abhängigkeiten hinsichtlich der Anforderungen auflösen

Basierend auf diesen Untersuchungen und Bewertungen können wir nun das Produkt Backlog für die Umsetzung passend zusammenstellen. Was heißt das genau? Das heißt, dass wir Backlogelemente auswählen, die „bereit“ für den nächsten Sprint sind (Definition of Ready).

Aber auch während der Umsetzung im Sprint können wir Anforderungen noch weiter detaillieren, wenn neue Erkenntnisse gewonnen werden.

Inkrement überprüfen und Anforderungen anpassen

Das Inkrement, das wir im Sprint erstellt haben, bietet uns die Basis für unsere Überprüfung. Hier sehen wir, ob wir das Richtige geliefert haben.

Bei Scrum wird diese Überprüfung im Rahmen des Sprint Reviews durchgeführt. Hierbei ist es entscheidend, dass auch wirkliche Benutzer am Review teilnehmen, denn nur sie können echtes Feedback geben. Hier entscheidet sich dann, ob das gemeinsame Verständnis der Anforderungen im Scrum-Team auch das Verständnis der Stakeholder war, ob also alle Ebenen des Informationsmodells (Warum/Was/Wie/Wie genau) wirklich zusammenpassen.

Die notwendigen Änderungen der Anforderungen und auch neue Anforderungen, sowie neue Ideen der Stakeholder, können wir im Rahmen des Reviews aufnehmen.

Wie können wir uns den letzten Prozessbaustein erklären und was hat es mit der Zusammenarbeit auf sich? Das ersehnte Fazit aus den Teilen 1 bis 3 gibt es im 4. und letzten Teil dieser Blogreihe zum Produktmanagement in genau zwei Wochen.  Seien Sie gespannt!

Wer die Spannung nicht aushält, dem gebe ich den Tipp an meinem Training teilzunehmen: Möchten Sie bereits jetzt mehr zur Agilen Produktplanung erfahren? Dann empfehle ich das mehrtägige Curriculum zu APP , für Sie, oder auch zusammen im Team.

Series Navigation<< Agile Produktplanung (APP) – MissverständnisseAgile Produktplanung (APP) – ein Fazit >>