Blog

Anforderungsmanagement in Scrum – Gibt es nicht, oder doch?

Scrum macht keine Aussagen wie Anforderungen zur Entwicklung von Produkten oder Dienstleistungen erfasst und spezifiziert werden müssen. User Stories haben sich als guter und geeigneter Weg dafür gezeigt. Klassische Spezifikationsdokumente (Lastenhefte, Pflichtenhefte, Funktionale Spezifikationen) mit vielen Seiten Umfang werden Sie bei Scrum nicht finden. Scrum kommt mit weit weniger dokumentierten Anforderungen wie die klassische Anforderungsdokumentation aus.

Das macht Sinn für viele Anwendungsfälle. Umfangreiche Spezifikationen mit langer Erstellungszeit werden heute von der Zeit oftmals überholt. Agil sein heißt, sich rasch anpassen können.

Der Product Backlog ist eine geordnete Liste in der alle User Stories enthalten sind. In diesen sind letztendlich alle Anforderungen abgebildet.

Eine überzeugende und begeisternde Produktvision erstellen

Warum Produktvision?

Ausgangspunkt für eine Produktvision ist häufig eine Idee für ein Produkt oder eine Dienstleistung.

Die Produktvision ist eine Vision auf Produktebene und gibt die Richtung für ein neues Produkt oder Dienstleistung vor. Sie gibt Orientierung und eine gemeinsame Ausrichtung wohin die Reise geht und hilft damit bei der Koordination aller Beteiligten. Damit beschreibt sie  ein Bild der Zukunft für ein Produkt oder eine Dienstleistung, ist Leitbild und Leuchtturm für die Erreichung der Ziele, gibt Inspiration und trägt zum gemeinsamen (Team-)Spirit bei. Sie soll alle Stakeholder überzeugen, begeistern und ins Boot holen.

Die Produktvision ist Ausgangspunkt für den Product Backlog.

Darüber hinaus stellt sie sicher, dass alle Beteiligten von demselben reden und dient im weiteren Spezifikationsprozess als Leitlinie und Entscheidungshilfe. Anhand der Produktvision lassen sich die Anforderungen im Product Backlog eindeutiger priorisieren. Sie kann ein Kriterium dafür liefern, um die Wichtigkeit einer Anforderung einordnen zu können.

Alle Anforderungen müssen im Einklang mit der Produktvision stehen. Sie kann daher als Mittel zur Überprüfung der Anforderungen dienen und so auch zur Risikominimierung beitragen.

Eigenschaften einer guten Produktvision sind:

• mitreißend, motivierend, einnehmend
• bildhaft
• ambitioniert, sollte ein großes anspruchsvolles Ziel ansprechen
• Klar und stabil, klar formuliert, leicht zu verstehen, bleibt über die Zeit gleich
• Kurz und prägnant, damit sich jeder die Produktvision merken kann
• Gestützt, mitgetragen von allen Stakeholdern, insbesondere dem Management

Beispiele von Produktvisionen

"Wir wollen das einzige Job-Portal für die Stellenvermittlung im High Professional-Umfeld in Europa werden." ¹

Firma Polycom (Anbieter von Telepräsenz-, Video- und Audiolösungen), Produkt: Tischgerät für Telefonkonferenzen (Polycoms SoundStation: Kommunikations-„Spinne“ in Besprechungszimmern).

„Hervorragende Audioqualität: Mehr als eine Person können gleichzeitig sprechen und dennoch verstanden werden, Einfache Bedienung: keine irritierenden Knöpfe oder Kabel, Erstklassiges Erscheinungsbild: passt in das Besprechungszimmer der Geschäftsleitung“. ²

Wichtig ist, dass die Produktvision umfassend kommuniziert wird, damit jeder Beteiligte die Produktvision kennt!

Abbildung: Beschreibungsebenen von der Produktversion zum Sprint Backlog

Wie gelange ich zu einer guten Produktvision?

…und wie kann ich sicher sein, dass diese auch wirtschaftlich tragfähig ist und der Kunde das Produkt oder die Dienstleistung wirklich will?

Jedes Vorhaben entspringt einer Idee oder einem erkannten Bedarf und soll in der Regel Wert für Kunden oder das eigene Geschäft schaffen.

Viele Vorhaben und Ideen werden häufig aus der Annahme heraus initiiert, dass das Ergebnis des Vorhabens, also das Endprodukt oder die Dienstleistung wirklich einzigartig ist, unbedingt vom Kunden gebraucht und bei ihm so richtig einschlagen wird. Viele Vorteile und Nutzen sowohl für das eigene Unternehmen als auch für den Kunden werden gesehen.

Wie kann es gelingen, dass eine Produktidee auch wirklich belastbar ist und das Risiko eines teuren Scheiterns reduziert werden kann?

Die aus diesem Vorgehen resultierende Projektidee kann in einem gemeinsamen Workshop mit allen relevanten Stakeholdern (Geschäftsführung, Marketing, Controlling, Produktentwicklung, Entwicklerteam, Kunden etc) in eine Produktvision gegossen werden.

Tipp: Führen Sie zuvor eine Stakeholder-Analyse durch. Damit erkennen Sie wer direkt und indirekt von dem Thema betroffen ist und welche Einstellungen die Beteiligten zu diesem Thema haben. Und viel wichtiger: Sie vergessen keinen relevanten Beteiligten!

Produktvisionen, die in einem gemeinschaftlichen Prozess entstehen, werden stärker, tiefer und kompletter von allen Beteiligten verinnerlicht.

Von der Projektvision zum Product Backlog – Epics und User Stories erheben

Mit der Produktvision als „Kompass“ geht es nun darum die Anforderungen in Form von Epics und User Stories zu erheben.

Eins vorweg: Der Product Backlog unterliegt im gewissen Umfang einer dynamischen Veränderung. Agil sein heißt Änderungen  willkommen zu heißen (embrace change), ein wichtiges Konzept in Scrum. Das gilt  jedoch nicht für den Sprint Backlog, mit seinem kurzen Sprint-Zeitfenster.

Oftmals werden Anforderungen auf einer hohen Abstraktionsebene definiert, um den Beteiligten die Möglichkeit zu geben zunächst eine übergeordnete Sicht auf die Produktanforderungen einzunehmen. Damit liegt jedoch eine grobgranulare, aggregierte Sicht auf die Produktanforderungen vor, die auf die Details der Anforderungen noch nicht eingeht. Diese Form der Anforderungen wird Epic genannt.

Epics müssen im Rahmen einer Story Decomposition ggf. in mehrere User Stories zerlegt werden, um zu einem adäquaten Detaillierungsgrad zu kommen. Damit gelangt man vom Groben zum Feinen, d.h. zu einer niedrigeren Abstraktionsebene mit mehr Details und Informationen.

Abbildung: Von der Produktvision zum Sprint Backlog

Epics und User Stories werden so formuliert:

Als wer (Akteur, Rolle) möchte ich was (Inhalt, Ziel, Bedarf), damit warum (Wunsch, Nutzen, Vorteil, Gewinn)

Diese Beschreibungsform ist einfach in ihrer Form, aber effektiv und unterstützt die Formulierung der Anforderungen aus der Perspektive der verschiedenen Produktanwender. Sie ist in Alltagssprache formuliert und soll möglichst kurz gehalten werden.

Bei den Anforderungen kann es sich um Produkt- oder Dienstleistungsanforderungen handeln. Ziel von User Stories ist, die Anforderungen leicht zu verstehen und sie schrittweise zu verfeinern und zerlegen zu können. User Stories sind die Grundlage für den Dialog mit den Beteiligten.

Beispiel:

„Als Kunde“ möchte ich „einen Rabatt erhalten“, damit „meine vielen Einkäufe honoriert werden“.

Zur Erhebung der Anforderungen und deren Abbildung in Epics und User Stories bieten sich unterschiedliche Vorgehensweisen an.

• Arbeiten mit Erhebungskarten / Story-Cards
• Durchführung von Anwender- und Kundeninterviews
• Durchführung von Fokusgruppenmeetings
• Veranstaltung von Workshops und Anwendergruppenmeetings
• Fragebögen
• Dokumentenanalyse
• Modellierung (z.B. Protoyping)

Wir betrachten an dieser Stelle bevorzugt die Veranstaltung von Workshops als Erhebungsmethodik.

Veranstaltung von Workshops zur Erhebung von User Stories

Moderator und Initiator von Workshops zur Erhebung der Anforderungen ist der Product Owner. Zum Workshop werden von ihm alle relevanten Stakeholder (ggf. Geschäftsführung, Produktmanagement, Entwickler, Vertrieb, Marketing, Investoren, ggf. auch Kunden und Lieferanten, etc.) eingeladen.

Die Produktvision ist  Ausgangspunkt des Workshops. Sie muss von allen ausreichend verstanden und verinnerlicht werden. Der Product Owner stellt die Produktvision vor und stellt sicher, dass sie von allen Beteiligten wirklich tief und komplett verstanden wird. Idealerweise waren die vorgenannten Stakeholder an der Entwicklung der Produktvision zuvor beteiligt.

Ein guter Startpunkt für die nun nachfolgende Ableitung der User Stories ist die Definition von Anwenderrollen (siehe Formulierung von User Stories ….Als (Rolle/Akteur)….) und deren Ziele. Eine Anwenderrolle repräsentiert dabei eine Gruppe von Anwendern mit gleichen Anwendungszielen für das Produkt oder die Dienstleistung. So hat ein Kunde andere Ziele in Bezug auf die Nutzung als z.B. der Hersteller, Service etc. Anwenderrollen in diesem Kontext können je nach Art und Eigenschaften des Produkts/Dienstleistung sehr unterschiedlich sein: Informationssuchender, Besteller, Bediener, Berater, Administrator, Techniker, Konfigurator, Vertriebsmitarbeiter, weitere…..

Ausgehend von den Anwenderrollen können nun die User Stories formuliert werden. Dabei können Story Cards während der Workshop-Moderation genutzt werden.

Abbildung Story Cards (in Anlehnung an Wikipedia³)

Tipp:

Achten Sie auf klar und eindeutig formulierte User Stories. Führen Sie eine Story Decomposition für User Stories durch, die sehr hoch aggregiert sind. Hier sind die Epics gemeint, die weiter detailliert werden müssen. Vereinbaren Sie 3-5 Akzeptanzkriterien je User Story, die eindeutig festlegen, wann eine User Story als „fertig“ (siehe DoR – Definition  of Ready und DoD – Definition of Done weiter unten im Text) gilt. Für jede User Story sollte eine erste Aufwandschätzung durchgeführt werden.

Stellen Sie sicher, dass alle Beteiligten ein gemeinsames Verständnis zu den User Stories haben.

Product Backlog priorisieren

Die Priorisierung der User Stories im Backlog macht deutlich wie wichtig dieses Thema aus Sicht des Product Owners (und damit letztendlich der Stakeholder) ist. Vom Grundsatz her ist bei der Priorisierung immer zu beachten, dass Einklang mit der Produktvision herrscht!

Nach welchen Kriterien sollten User Stories priorisiert werden?

Hier bieten sich die Kriterien Wert (Value), Risiko & Unsicherheit (Risk & uncertainty), Eignung zur frühen Versionsfreigabe (Releaseability), Abhängigkeiten (Dependencies) an.

Wert: Die permanente Fokussierung auf den Wert für den Kunden, die das Produkt/Dienstleistung bietet, sichert ein nutzenmaximiertes Produkt, das vom Kunden angenommen wird. Die Priorisierung nach diesem Kriterium stellt sicher, dass diejenigen Funktionen mit dem größten Nutzen, soweit möglich, zuerst entstehen.

Risiko & Unsicherheit: Jede Entwicklung trägt Risiken und Unsicherheiten in sich. Beide haben einen großen Einfluss auf den Projekterfolg. User Stories mit hohen Risiken und Unsicherheiten sollten eine hohe Priorität haben. Gewonnene Erkenntnisse im Rahmen der Umsetzung und des Feedbacks der Stakeholder reduzieren frühzeitig Unsicherheiten und Risiken. Ein frühes mögliches Scheitern ist ein gezielter Ansatz, der es dem Scrum Team ermöglicht, rasch die eingeschlagene Richtung in der Entwicklung ggf. zu korrigieren.

Eignung zur Versionsfreigabe: Eine frühe Versionsfreigabe hilft Risiken frühzeitig zu mindern, da durch eine frühe und häufige Versionsfreigabe von Produktinkrementen wertvolles Feedback von den Stakeholdern erhalten wird. Dies kann dann wiederum Einfluss auf die Priorisierung des Backlogs nehmen. Darüber hinaus stellt ein Produktinkrement einem Kunden in dem Moment Wert zur Verfügung, in dem es ausgeliefert wird.

Abhängigkeiten: In jedem Product Backlog existieren Abhängigkeiten zwischen den User Stories. Bestimmte Eigenschaften müssen zuvor implementiert sein, da nachfolgende darauf aufbauen. Aufgrund dessen müssen gegebenenfalls zwei User Stories gleichzeitig in einem Sprint umgesetzt werden. Abhängigkeiten zwischen den User Stories lassen sich z.B. über einen Hierarchiebaum erkennen.

Eine Methodik zur Priorisierung ist der paarweiser Vergleich bzw. die Präferenzmatrix. Dabei wird jede User Story mit einer anderen verglichen, Story für Story und dabei entschieden, ob diese wichtiger als die andere ist. Mit Hilfe dieser Technik kann eine priorisierte Liste erstellt werden.

Definition of Ready und Definition of Done – Sicherung der Qualität von User Stories

DoR – Definition of Ready

Definition of Ready: Die Definition of Ready (DoR) gibt vor, in welchem Zustand User Stories sein müssen, bevor das Entwicklungsteam diese zur Sprintplanung und damit auch zur Umsetzung übernimmt.

Es geht also darum welche Eigenschaften eine User Story haben muss, bevor sie vom Entwicklungsteam akzeptiert wird. Dazu gehören Klarheit, Testbarkeit, Umsetzbarkeit.

Klarheit meint: Alle Entwickler haben ein gemeinsames Verständnis dazu, was die Story konkret bedeutet.

Testbarkeit meint: Ein effizienter Weg zur Feststellung, ob die Funktion/Produkt/umgesetzte User Story auch so arbeitet wie vorgesehen. Akzeptanzkriterien  (i.d.R. 3-5 pro User Story) sollen hier sicherstellen, dass jede Funktion/Eigenschaft auch getestet werden kann.

Umsetzbarkeit meint: Die User Story ist innerhalb eines Sprints, im Rahmen der Defition of Done, umsetzbar. Das bedeutet, dass die User Story klein genug sein muss und nicht zu komplex.

DoD - Definition of Done

Definition of Done: Wann gilt ein erarbeitetes Produktinkrement als abgeschlossen? Diese Frage wird von der Definition of Done beantwortet. Das Scrum Team einigt sich darauf nach welchen (Akzeptanz-)Kriterien festgestellt wird, ob ein Produktinkrement fertig ist. Letztendlich geht es hier um die Qualität des Produktinkrements.

Zu den Kriterien können unter anderem gehören: Tests sind durchgeführt, Dokumentation ist erstellt, Product Owner hat akzeptiert, Release ist veröffentlicht, Nutzung ist freigegeben etc.

Dabei können die Kriterien für DoD für jede User Story anders aussehen.

Fazit

Der Produktvision kommt eine zentrale Bedeutung zu. Sie ist der Kompass zum erfolgreichen Produktergebnis.

In Scrum gibt es kein klassisches Requirements Engineering / Anforderungsmanagement, der Product Backlog ist das Maß der Dinge: Er ist ein „lebendes“ Dokument und folgt dem agilen Ansatz in Scrum „Embrace Change“.

User Stories geben in leicht verständlicher Alltagssprache die Anforderungen an das Produkt oder die Dienstleistung wieder. Das erleichtert die Kommunikation mit allen Beteiligten.

Quellenangaben

¹ Projektmagazin, Ausgabe 2/2010, Agile SW-Entwicklung mit Scrum und User Stories, 27.01.2010, Ralf Wirdemann

² Agiles Produktmanagement mit Scrum, Erfolgreich als Product Owner arbeiten, Roman Pichler, 2. Korrigierte Auflage 2014, dpunkt.verlag GmbH

³ Wikipedia, https://de.wikipedia.org/wiki/User-Story#Story_Decomposition

Drucken