Bei Product Ownern können verschiedene Probleme im Zusammenhang mit dem Requirements Engineering, also dem Prozess der systematischen Erfassung, Analyse, Dokumentation und Verwaltung von Anforderungen an ein Produkt, auftreten.
Das ist ärgerlich, denn Anforderungsmanagement ist ein Erfolgskriterium in der Produktentwicklung!
Wie wäre es, wenn es da ein einfaches und vielfach bewährtes Werkzeug, eine Art Cheat Sheet gäbe, das POs und damit alle am Entwicklungsprozess Beteiligten in diesem Prozess leitet, Transparenz erhöht und Kollaboration fördert?
Häufige Probleme im Requirements Engineering
Zunächst stellt sich die Frage, was denn häufige Probleme im Requirements Engineering sind. Aus meiner Erfahrung heraus gibt es mindestens sechs wirklich weit verbreitete Probleme im Prozess des Anforderungsmanagements:
1. Mangelnde Einbindung der thematisch notwendigen Personen
Wenn der Product Owner nicht ausreichend mit den relevanten Stakeholdern kommuniziert und deren Bedürfnisse und Anforderungen nicht berücksichtigt, können wichtige Perspektiven übersehen werden.
Das Gleiche kann passieren, wenn das Entwicklungsteam nicht frühzeitig in den Anforderungsprozess einbezogen wird. Dann können potenzielle technische Einschränkungen oder Lösungen übersehen werden.
2. Unklare Anforderungen / ungenügende Dokumentation
Oftmals sind Anforderungen nicht klar formuliert oder unvollständig. Das kann zu Missverständnissen zwischen dem Entwicklungsteam, dem Product Owner und den Stakeholdern führen, was letztendlich zu fehlerhaften oder unzureichenden Funktionen führt.
Das Gleiche gilt, wenn Anforderungen nicht klar dokumentiert werden. Das kann es schwierig machen, den Fortschritt der Entwicklung zu verfolgen und sicherzustellen, dass die richtigen Funktionen entwickelt werden.
3. Ständige Anforderungsänderungen
Wenn Anforderungen während des Entwicklungsprozesses häufig geändert werden, kann das zu Verzögerungen, erhöhten Kosten und Frustration sowohl beim Entwicklungsteam als auch beim Product Owner und letztlich den Stakeholdern führen.
4. Mangelnde Kommunikation
Eine unzureichende Kommunikation zwischen dem Product Owner, den Stakeholdern und dem Entwicklungsteam kann zu Missverständnissen, Fehlinterpretationen und Fehlern bei der Umsetzung führen.
5. Mangelnde / fehlende technische Machbarkeit-Prüfung
Manchmal können Anforderungen technisch nicht umsetzbar sein. Gründe sind meist Einschränkungen durch die vorhandene Technologie oder Zeit- und Ressourcenbeschränkungen.
6. Fehlende Testszenarien
Wenn die Testfälle für die Anforderungen nicht ausreichend definiert sind, kann das zu unzureichender Qualitätssicherung und fehlerhafter Software führen.
Was kann diese Probleme lindern?
Aus meiner Sicht gibt es hier eine ganz Menge an Optionen, welche die sechs oben skizzierten Herausforderungen lindern. Dazu gehören bspw.:
- Alle relevanten Personen an einen „Tisch“ bringen und somit Schwarmintelligenz nutzen
- Requirements schriftlich festhalten
- Requirements – wo möglich / nötig – visualisieren
- Explizit machen, was nicht umgesetzt wird
- Requirementsänderungen besprechen und verhandeln, Auswirkungen und an der Entscheidung Beteiligte festhalten
- Eine zentrale Dokumentation schaffen, diese im Unternehmen öffentlich zugänglich machen und im Epic verlinken
- Fragen immer unter Verwendung der Dokumentation klären
- Technische Belange der Requirements explizit challengen und dokumentieren
- Testoptionen und Umgang mit diesen klären und dokumentieren
- „Testdrehbücher“ entwicklen und dokumentieren
Die Lösung: Das Requirements Sheet
In meiner beruflichen Vergangenheit hat sich das sogenannte Requirements Sheet sehr bewährt. Ursprünglich mal im Newsletter von Atlassian als Template entdeckt, habe ich es an das mir gegebene Umfeld kontinuierlich angepasst und über viele Jahre weiterentwickelt.
Ein Requirements Sheet hat grundsätzlich das Ziel, alle für die Umsetzung notwendigen Informationen zu Anforderungen zu dokumentieren. Gleichzeitig soll es sie für alle Beteiligten transparent machen und so letztlich auch noch die Erwartungen an das Produkt schärfen.
Es dient als Referenz für alle Phasen der Produktentwicklung, von der Konzeption und Entwicklung über die Umsetzung bis hin zur Qualitätssicherung und Review des Outcomes.
Im Standard verfügt solch eine Anforderungsdokument Inhalte wie:
- funktionale Anforderungen
- nicht-funktionale Anforderungen
- Benutzeranforderungen
- Technische Anforderungen
- Design-Anforderungen
- Liefer- und Zeitplan
- Budget und Ressourcen
- Abnahmekriterien
Anhand meines aktuell in Verwendung befindlichen Requirements Sheets möchte ich dir nachfolgend mögliche Ansätze für die sechs oben aufgeführten, häufigen Probleme im Zusammenhang mit Requirements vorstellen.
1. Mangelnde Einbindung der thematisch notwendigen Personen
Ein Requirements Sheet ist bzgl. der Einbindung der thematisch notwendigen Personen zwar kein Garant für eine Verbesserung. Aber eine entsprechender Abschnitt (siehe Abb. 1) zur Aufführung aller thematisch notwendigen Personen im Dokument veranlasst gerade beim initialen Meeting und damit dem ersten Befüllen des Sheets alle Beteiligten, über ggf. noch fehlende, notwendige Personen nachzudenken und diese ebenfalls einzutragen.
Sollte man im weiteren Lebenszyklus des Dokuments feststellen, dass man noch weitere Wissensträger benötigt, ist auch das keine Beinbruch. Man trägt sie einfach nach.
Dieser Abschnitt im Requirements Sheet sorgt aber gleichzeitig auch noch für Synergien und unterstützt bspw. bzüglich mangelnder Kommunikation. Dazu etwas später mehr.
2. Unklare Anforderungen / ungenügende Dokumentation
Ein Requirements Sheet kann auch bzgl. der Klarstellung und ausreichenden Dokumentation von Anforderungen sehr gut unterstützen. So kann man bspw. die Feature-Requirements zusammen mit Zusatzinformationen, wie Begründungen, in einem Bereich Anforderungen (siehe Abb. 2) auflisten.
Die Priorität kann zusammen mit der technischen Gewissheit gesetzt und in kritischen Fällen farblich (bspw. rot) markiert werden. Das wiederum signalisiert allen Beteiligten kommende Probleme und sollte mindestens zur zeitgerechten Sichtung der Problematik animieren.
Existierende Tickets sollten aus meiner Erfahrung heraus dort ebenfalls dokumentiert werden. Das zeigt in einigen Systemen auch allen Beteiligten den entsprechenden Status der Umsetzung auf. Notwendig, weil einige Beteiligte schlicht nicht in die Sprint-Boards oder Backlogs schauen.
Last but not least kann man über die Liste auch noch funktionale Reviews abbilden, bspw. durch den Einsatz von Checkboxen. Ich habe sehr gute Erfahrungen damit gemacht, entsprechende Feature-Zeilen dann im positiven Review-Fall leicht grün und im Falle einer negativen Review leicht rot einzufärben. Dadurch ist die Erfassung des Fortschritts in der Liste schon beim Durchscrollen möglich.
Sollte das Produkt mehrere Komponenten haben, so ist es zur Erhöhung der Übersichtlichkeit und vielleicht auch der thematischen Trennung ratsam, diese durch Subsektionen in der Liste abzugrenzen.
Es geht bei den Anforderungen aber nicht nur um Feature-Anforderungen! Es sollte daher auch für UI / UX, sowie technische, rechtliche und ethische Anforderungen entsprechende Abschnitte im Dokument geben
3. Ständige Anforderungsänderungen
Anforderungsänderungen lassen sich nicht gänzlich vermeiden und basierend auf fortwährendem Lernen ist es sogar ratsam, diese auf Basis neuer Erkenntnisse zu begrüßen! Ein Requirements Sheet kann auch hier wieder in mehrerlei Hinsicht unterstützen.
Indem man einen Dokumenten-Verantwortlichen, ohne dessen Beisein oder Wissen Inhalte nicht geändert werden dürfen, bestimmt, werden schon mal unkontrollierte Änderungen erschwert. Meiner Erfahrung nach sollte man auch den Status am Beginn des Dokuments gut für alle sichtbar machen. Damit kann dann jeder Leser den Inhalt des Dokuments bzgl. seines Status einordnen (siehe Abb. 3).
DRAFT signalisiert allen Beteiligte, dass das Dokument noch nicht vollständig ist. REFINEMENT zeigt Änderungs- und damit Diskussionsbedarf an. Und AGREED macht deutlich, dass das Dokument inhaltlich auf dem aktuellen Stand ist.
Auch ist eine Art „Meeting Log“ hat sich in meiner Erfahrung als sehr wertvoll erwiesen (siehe Abb. 4). In diesem wird das Datum eines jeden Meetings in Verbindung mit den groben Themen und den Beteiligten geführt. Dies unterstützt zusammen mit einer Versionierung, mögliche Ansprechpartner direkt auszumachen. Zusätzlich hilft es auch, im Nachhinein Learnings generieren zu können.
4. Mangelnde Kommunikation
Kommunikation ist schwer! Aber mit einem Requirements Sheet, in dem alle Beteiligten digital markiert sind und somit bei jedem Update des Dokuments eine entsprechende Update-E-Mail bekommen, ist zumindest die Gefahr verringert, dass Beteiligte Informationen – bspw. in Form von Änderungen – nicht weitergetragen bekommen.
Wenn man das Requirments Sheet auch aktiv als Arbeitsbasis für die Klärung von Fragen oder die Festlegung von Anforderungen nutzt, bewegt man sich nicht mehr im Bereich von Vermutungen, sondern im Bereich von verhandelten Tatsachen. Das setzt natürlich einen disziplinierten Umgang mit dem Dokument voraus!
Genauso sollte man Fragen und deren Antworten festhalten und auch die Antwortgeber direkt taggen. So können einfachere Fragen ggf. sogar schon asynchron geklärt und damit Kapazität gespart werden.
In der Kommunikation gilt grundsätzlich, Dinge explizit zu machen. Deshalb sollte man Hinweise zum besseren Verständnis in Form von Notizen (wann immer als nötig empfunden) hinzufügen. Nur so kann man letztlich sicherstellen, dass Unbeteiligte den gleichen Wissensstand haben können und sich selbst Beteiligten nach einigen Wochen noch an wichtige Details oder Beweggründe erinnern können.
5. Technische Machbarkeit
Die technisch Machbarkeit wird meiner Erfahrung nach häufig recht oberflächlich betrachtet. Auch hier hilft ein Requirements Sheet mit einer vorgegebenen Struktur den technisch Beteiligten, sich immer gleich mit dieser Problematik auseinanderzusetzen (siehe PDF).
Dabei sind die Ansprüche von Team zu Team und von Organisation zu Organisation durchaus unterschiedlich. Es gilt also eine entsprechende Struktur zu finden, die die Produktentwicklung vor überraschenden technischen Problemen bewahrt.
6. Fehlende Testszenarien
Umfangreiche Tests werden trotz des Ansatzes des Test-Driven Development (TDD) meist eher stiefmütterlich, meist nachgelagert und damit vielfach zu spät betrachtet. Auch hier kann ein entsprechender Abschnitt im Requirements Sheet wieder gut unterstützen (siehe PDF).
Mit einem entsprechenden Test-Abschnitt im Dokument sorgt man grundsätzlich mal dafür, dass das Thema bewusst unter den Tisch fällt.
In einem solchen Abschnitt setzt man sich explizit mit möglichen Testarten und deren Ausprägung auseinander. Indem man diese frühzeitig definiert und ausarbeitet, kann man dann auch von vornherein die Qualität des erzeugten Produktes reproduzierbar sicherstellen.
Key Takeaways
Die oben aufgeführten Gründe für häufige Probleme im Anforderungsmanagement sind natürlich nur die oberflächlich beobachteten, negativen Auswirkungen. Die Symptome sozusagen. Die eigentlichen Gründe, die Krankheit an sich, sind aus meiner Sicht andere, aber immer wieder die gleichen.
Da diese zahlreich sind, möchte ich mich für die Key Takeaways nur auf zwei beziehen.
1. Transparenz
Transparenz im agilen Kontext bedeutet, dass alle relevanten Informationen und Aspekte eines Projekts oder Arbeitsprozesses für alle Teammitglieder und Stakeholder klar und offen zugänglich sind. Transparenz fördert offene Kommunikation, Vertrauen und Zusammenarbeit, was wiederum zu effizienterer Arbeit und besseren Ergebnissen führt.
Genau hier wirkt das Requirements Sheet durch seinen Aufbau und genutzte Automatismen, wie bspw. Benachrichtigungsfunktion und Versionierung und damit der Förderung von:
- Sichtbarkeit
- automatisierte Informationsverteilung (24/7)
- Einbindung notwendiger Personen
- geteilte Verantwortung
- offene Kommunikation
- frühzeitige Erkennung von Problemen
2. Explizitheit
Explizitheit bedeutet, Informationen, Absichten, Regeln oder Anforderungen klar und eindeutig zu formulieren, um Missverständnisse zu minimieren und eine klare Kommunikation zu gewährleisten.
Auch hier zahlt das Requirements Sheet deutlich auf eine Verbesserung ein. So gibt es
- eine klare Struktur vor,
- ein Stück weit sogar einen Prozess vor
- die Möglichkeit Task Owner zu führen
- die Möglichkeit Fälligkeitsdaten für Aufgaben zu führen.
Gerade in Bezug auf Struktur und Prozess sei angemerkt, dass diese durch kontinuierliches Lernen stetig an die vorherrschenden Bedingungen und Bedürfnisse angepasst werden können und sogar sollten!
Tipps
Abschließend noch ein paar erfahrungsbasierte Tipps für die Einführung bzw. Umsetzung von mir:
- Finde den Break-Even-Punkt zwischen zu viel und zu wenig Dokumentation.
- Bei größeren Aufgaben: Schneide sie kleiner, erzeuge stattdessen einzelnen Requirements Sheets und verlinke sie nötigenfalls miteinander.
- Mache dir Gedanken über die Priorisierung der einzelnen Abschnitte im Requirements Sheet.
- Visualisiere Informationen wann immer möglich!
Tim Schneider
#productownership #leadershipexcellence #agilist
Ich liebe das Kollaborieren und gemeinsame Schaffen von Mehrwert im agilen Umfeld. Leadership Excellence und Prozesse sind meine Passion, ohne dabei den Menschen aus dem Auge zu verlieren. Bei MAYFLOWER bringe ich diese Expertise u. a. im Consulting ein.
Schreibe einen Kommentar