Der Product Owner als Requirements Engineer

Professionelles Requirements Engineering in Scrum-Projekten [Best Practices]
Kommentare

Professionelles Requirements Engineering ist auch bei agilen Vorgehensweisen wie Scrum eine wesentliche Voraussetzung für den Projekterfolg. Doch wie fügt sich, vor allem bei komplexen Entwicklungsprojekten in größeren Unternehmen, die Erhebung, Dokumentation und Verwaltung von Anforderungen in das agile Vorgehensmodell ein? Wie kann das gemeinsam erarbeitete Fach- und Technologiewissen konserviert werden? Die meisten RE-Aktivitäten lassen sich in Scrum wiederfinden oder zwanglos ergänzen. Die Rolle des Requirements Engineers kommt dabei dem Product Owner zu.

Professionelles Requirements Engineering ist (nicht nur) in komplexen Entwicklungsprojekten ein Schlüsselfaktor für den Projekterfolg, unzählige Studien und Erfahrungsberichte wie z. B. der regelmäßige CHAOS-Report belegen das. Die wesentlichen Gründe hierfür liegen in der Vielzahl von Stakeholdern, die unterschiedliche Interessen haben, sowie in komplexen Sachverhalten, die für Einzelne kaum überschaubar sind. In Scrum, auf das wir uns im Folgenden wegen seiner Verbreitung fokussieren wollen, verwaltet der Product Owner die Anforderungen z. B. in Form von User Stories im Product Backlog. Scrum sagt jedoch nichts dazu aus, wie Anforderungen erarbeitet und qualitätsgesichert werden. Der Scrum Guide  sowie einschlägige Literatur [z. B. hier] hält sich zu diesem Thema eher bedeckt. Standardisierungen z. B. vom International Requirements Engineering Board IREB und andere Modelle beschreiben, wie Anforderungen erarbeitet und verwaltet werden, äußern sich aber nicht zur Einbettung des Requirements Engineering in die verschiedenen Vorgehensmodelle zur Softwareentwicklung.
Aber auch ein mit RE-Methoden systematisch erarbeitetes Product Backlog reicht nicht aus, wenn wir den gesamten Lebenszyklus eines Softwareprodukts betrachten. So fällt ein Großteil des Gesamtaufwands in der Wartungsphase – im Sinne der Produktpflege oder Produktweiterentwicklung – an. Manche Anwendungen, z. B. Bestandsführungs- oder Schadensysteme bei Versicherungen, sind zwanzig oder dreißig Jahre in Betrieb, sie stellen einen bedeutenden Vermögenswert des Unternehmens dar. Die ursprünglichen Entwicklungsteams sind dann wahrscheinlich nicht mehr greifbar, das Wissen über die Anwendung und die zugrunde liegenden Anforderungen muss daher dokumentiert und gepflegt werden.
Dieser Artikel beschreibt, wie professionelles Requirements Engineering in einem Scrum-Projekt erfolgt. Dabei steht die Entwicklung kundenspezifischer Individualsoftware im Vordergrund, nicht Standardsoftware für eine anonyme Nutzergruppe. In diesem Kontext muss der Product Owner häufig eine Vielzahl von Anforderungsgebern aus einem nicht agilen Umfeld mit unterschiedlichen, möglicherweise widersprüchlichen Auffassungen koordinieren.
Der Artikel soll keine Einführung in das Requirements Engineering oder in Scrum sein, stellt jedoch die in diesem Kontext relevanten Aspekte der beiden Vorgehensweisen kurz vor. Unsere Projekterfahrungen zeigen, dass professionelles Requirements Engineering in Scrum-Projekten notwendig und möglich ist. Es erfolgt durch den Product Owner in enger Zusammenarbeit mit dem Entwicklungsteam.
Requirements Engineering nach IREB
Das Requirements Engineering beschreibt die Erhebung, Dokumentation, Abstimmung und Verwaltung von Anforderungen und ihren Änderungen. Der Requirements Engineer

• beschreibt in der Produktvision die Idee und das Ziel der Software sowie ihren Nutzen aus Sicht des Auftraggebers.
• erstellt eine Liste aller relevanten Stakeholder und ihrer Interessen.
• grenzt im Systemkontext das zu erstellende System von seiner Umwelt ab.
• erstellt die Liste der Anforderungen auf einer High-Level-Ebene (d. h. ohne allzu sehr ins Detail zu gehen).
• dokumentiert und spezifiziert alle Anforderungen im Detail.
• lässt jede Anforderung von den betroffenen Stakeholdern prüfen und abstimmen.
• beschreibt und etabliert einen Änderungsprozess für Anforderungen.

Anforderungen beschreiben gewünschte Fähigkeiten oder Leistungen eines Produkts oder Prozesses. Weiterhin empfiehlt IEEE Vorgehensweisen für die Dokumentation und Kriterien für Anforderungen. Die Dokumentation kann natürlichsprachlich und/oder modellbasiert erfolgen. Für die natürlichsprachliche Dokumentation werden häufig Lasthefte oder so genannte Fachkonzepte erstellt, wobei es jedoch schwierig sein kann, aus Prosatext einzelne Anforderungen zu identifizieren. Daher schlagen z. B. Rupp und Pohl eine Satzschablone vor („Das System muss/soll dem <Benutzer> die Möglichkeit bieten, …“). Diese muss in der Regel durch weitere detaillierte Beschreibungen ergänzt werden.
RE-Modelle legen jedoch keinen Entwicklungsprozess fest. Klassisch definieren z. B. Wasserfall- oder V-Modell, wann welche RE-Aktivitäten stattfinden. Wie aber sieht das agile Vorgehen aus?

Agile Softwareentwicklung

Die agile Softwareentwicklung basiert auf dem Agilen Manifest. Insbesondere stellt es die direkte Kommunikation über eine umfassende Dokumentation (jedoch ohne eine Dokumentation als solche grundsätzlich abzulehnen).
Die Erfahrung hat uns gezeigt, dass sich durch die Trennung von Analyse und Implementierung komplexe Sachverhalte häufig nicht ausreichend vollständig und mit akzeptablem Aufwand in einer Spezifikation erfassen lassen. Aus Sicht des Requirements Engineering ermöglichen uns agile Vorgehensweisen durch intensive Kommunikation zwischen Anforderungsgeber und Entwickler unklare, unvollständige oder unverstandene Anforderungen an das Produkt zu handhaben, ohne in einer oft langwierigen Analysephase zu versuchen, alle Anforderungen vollständig zu durchdringen (was häufig trotzdem nicht gelingt). Das schnelle Feedback durch frühzeitige und häufige Auslieferungen erlaubt die ständige Anpassung und Optimierung der Anforderungen und schnelle Reaktionen auf geänderte Bedingungen. Aus der direkten Kommunikation am entstehenden Produkt erwächst so das gemeinsame Verständnis der Anforderungen.

Anforderungen und das Backlog in Scrum

In Scrum verwaltet der Product Owner (PO) im Product Backlog Anforderungen aus Nutzersicht, z. B. als User Story: „Als <Nutzer> möchte ich <Tätigkeit>, damit <Nutzen>“ mit Akzeptanzkriterien. Diese werden nach dem INVEST-Prinzip entworfen:

Independent (unabhängig)
Negotiable (verhandelbar)
Valueable (wertorientiert)
Estimatable (schätzbar)
Small (klein)
Testable (testbar)

Auch wenn sich allgemein User Stories durchgesetzt haben, macht Scrum keine Vorgaben zur Beschreibungsform. Falls erforderlich, können z. B. auch fachliche Klassenmodelle, Architekturmodelle, Prozessbeschreibungen oder Mockups dazu gehören. Neben funktionalen Anforderungen lassen sich aber auch Qualitätsanforderungen in Form von User Stories beschreiben („Als Benutzer möchte ich auch bei n parallel arbeitenden Benutzern nach x Sekunden eine Reaktion des Systems erhalten, damit die Kosten des Geschäftsvorfalls …“, „Als Produktentwickler möchte ich, dass neue Produkte mit maximal n Tagen Aufwand in die Software integriert werden können, damit wir Marktführer bleiben.“).
Die Akzeptanzkriterien sind ein wesentlicher Bestandteil der Anforderung: Sie beschreiben die Erwartungen des Anforderungsgebers an die Lösung, die über die kurze User Story hinausgehen. Sie können auch auf weitere Dokumente und Artefakte verweisen.

Probleme im nicht agilen Umfeld

Selten wird Individualsoftware „auf der grünen Wiese“ und für einen einzelnen Stakeholder als PO entwickelt. In der Regel ist sie eine Komponente in einer Anwendungslandschaft, mit einer Vielzahl von Stakeholdern:

• Der Fachbereich ist geprägt vom Tagesgeschäft der normalen Produktion.
• Die Aufgabe des IT-Betriebs ist zunächst die Sicherstellung der Produktionsfähigkeit sowie die Koordination allgemeiner Releasetermine.
• Die Unternehmensarchitektur (EAM) beschreibt die komplexe Anwendungslandschaft mit vielen Schnittstellen und macht Vorgaben zu technischen Rahmenbedingungen.
• Das Management benötigt Voraussagbarkeit zur Unternehmensplanung, Produkten, Ressourcen, Finanzen.
• Komplexe Hierarchien, z. B. Lenkungsausschuss; Programmleitung, IT-Board etc., schränken die entscheidende Verantwortung des PO ein.
• Gesetzliche Vorgaben erfordern eine definierte Funktionalität zu festgelegten Terminen (z. B. SEPA, Unisex-Tarife).
• Einen schönen Überblick über die verschiedenen nicht funktionalen Anforderungen nicht agiler Stakeholder in einem Unternehmen finden Sie hier.

Diese Rahmenbedingungen bilden in der Regel ein nicht agiles Umfeld, in denen sich agile Projekte bewegen müssen (Abb. 1). Vor dem Start eines agilen Projekts muss daher geprüft werden, inwieweit überhaupt die Voraussetzungen für agiles Arbeiten gegeben sind.

Abb. 1: Agiles Requirements Engineering im nicht-agilen Umfeld

Aufmacherbild: Businessman hand writing Software Engineering concept. von Shutterstock / Urheberrecht: new photo

[ header = Seite 2: RE klassisch und mit Scrum ]

RE klassisch und mit Scrum

Mit „klassischem“ Vorgehen wollen wir hier alle schwergewichtigen Vorgehensweisen wie Wasserfall, V-Modell, RUP und andere, auch iterative, Modelle zusammenfassen im Unterschied zu Modellen, die sich am agilen Manifest orientieren. Das besondere Kennzeichen des klassischen Vorgehens in Bezug auf das RE ist, dass die Anforderungsspezifikation zumindest für eine Iteration abgeschlossen sein muss, bevor die Entwicklungstätigkeit beginnt, während agil nur die im jeweiligen Sprint umzusetzenden Stories soweit spezifiziert sind, dass klar wird, was zu tun ist, um sie fertigzustellen. Details werden dabei erst während der Umsetzungen geklärt. So unterschiedlich beide Vorgehensweisen auch sind, gibt es doch deutliche Übereinstimmungen (Abb. 2).

Abb. 2: Anforderungsmanagement mit Scrum

In der initialen Phase benennt Scrum die gleichen Artefakte wie IREB: Die Produktvision ist immer ein wichtiger Schlüssel zum Erfolg. Product Owner, Stakeholder und Team entwickeln ein gemeinsames Verständnis des zu erstellenden Produkts. Die Beteiligung des Entwicklungsteams von Anfang an ist dabei ein wesentlicher Aspekt der agilen Werte.
Die Festlegung des Systemkontexts durch die System- und Kontextabgrenzung ist in jedem Vorgehensmodell ein länger andauernder Prozess. Zu Anfang besteht in der Regel eine „Grauzone“, wo genau die System- und Kontextgrenzen liegen, die während dieses Prozesses immer weiter reduziert wird. Beim agilen Vorgehen wird jedoch schon während der Abgrenzung mit der Umsetzung zentraler Anforderungen begonnen.
Zum Ermitteln von Anforderungen stehen, unabhängig vom Vorgehensmodell, die üblichen Techniken zur Verfügung: Interviews, Workshops, Dokumentenstudium, Kreativitätstechniken usw. Welche Methoden im konkreten Fall eingesetzt werden, hängt mehr von den Umständen als dem Vorgehensmodell ab.

Dem Ergebnis der Ermittlung, der Liste der Anforderung, entspricht in Scrum das Product Backlog, das zugleich zur Verwaltung der Anforderungen dient. Scrum fordert hier eine eindeutige Ordnung der Anforderungen, die bei nicht agilem Vorgehen häufig nur in der Releaseplanung besteht, also welche Anforderungen in welchem Release umgesetzt werden sollen.
Zur Dokumentation von Anforderungen beschreiben die RE-Modelle verschiedene natürlichsprachliche und modellbasierte Formen. Wie bereits erwähnt, schränkt Scrum die Beschreibungsform nicht ein, wobei jedoch die agilen Werte und das INVEST-Prinzip beachtet werden sollten. Die Qualitätskriterien für Anforderungen (z. B.: bewertet, eindeutig, korrekt, konsistent, prüfbar, verfolgbar, vollständig) sind auch für agiles Vorgehen evident. Die einzelne Anforderung wird Stück für Stück verfeinert bis sie vollständig verstanden ist, aber nicht bis ins letzte Detail vollständig dokumentiert, da sich PO, Anforderungsgeber und das Team direkt austauschen, vieles nur im Gespräch erläutert und nicht schriftlich festgehalten wird. Die Praxis zeigt, dass nur wichtige Eckpunkte einer User Story bereits im Vorfeld z. B. als Anhang oder Akzeptanzkriterien dokumentiert und neben der eigentlichen User Story als Diskussionsgrundlage bereitgestellt werden. Auf „Themes“, „Epics“ oder „Features“ als Gruppierungsmittel von Backlog-Einträgen gehen wir hier nicht im Einzelnen ein, die Ausführungen gelten aber auch für diese.

Auch die Vollständigkeit im Sinne einer Gesamtheit aller Anforderungen widerspricht agilem Vorgehen offensichtlich, da das Backlog keine vollständige Liste der Anforderungen an das Produkt ist, sondern der gegenwärtige Kenntnisstand, der sich durch das Feedback der Nutzer oder sich ändernde Rahmenbedingungen ständig ändert.
Ein wichtiger Aspekt von Scrum ist die eindeutige Reihenfolge der Backlog-Einträge. Beim klassischen Vorgehen erfolgt zwar meist auch eine Priorisierung der Anforderungen, sie beschränkt sich aber häufig nur auf wenige Stufen.
Zu den Methoden des RE gehört weiter das Prüfen und Abstimmen von Anforderungen zwischen verschiedenen Anforderungsgebern. In Scrum ist dies implizit eine Aufgabe des PO, ohne dass dies näher ausgeführt wird. Bei der hier im Fokus stehenden Entwicklung von Individualsoftware im normalerweise nicht agilen Umfeld ist das Prüfen und Abstimmen zwingend erforderlich, da die einzelnen Stakeholder unterschiedliche Auffassungen über Anforderungen oder Prioritäten haben können.

Ein wesentlicher Unterschied zwischen klassischem und agilem Vorgehen liegt im Umgang mit Änderungen von Anforderungen. Klassisch hat die Anforderungsspezifikation häufig den Charakter eines Vertrags zwischen Auftraggeber und Auftragnehmer. Daher ist bei nicht agilem Vorgehen ein eigener Änderungsprozess zur Änderung der bestehenden (abgenommenen und ggf. bereits umgesetzten) Dokumentation erforderlich. Dieser Änderungsprozess wird dabei leider allzu häufig als Änderungsverhinderungsprozess missbraucht, was letztendlich dem Produkt schadet. Das agile Vorgehen begrüßt daher Änderungen, sei es durch geänderte Rahmenbedingungen oder neue Erkenntnisse, als Verbesserungsmöglichkeit des Produkts. In Scrum können daher kleinere Änderungen auch während des Sprints jederzeit vorgenommen werden. Bei größeren Änderungen kann der PO neue Anforderungen für zukünftige Sprints in das Product Backlog aufnehmen, andere umpriorisieren, anpassen oder streichen. Es erfolgt jedoch keine Konsolidierung bereits abgenommener Backlog Items. Damit ist kein dedizierter Änderungsprozess erforderlich, weil jede Änderung als neue Anforderung betrachtet wird. Wie bei jeder Anforderung muss der PO mit den Stakeholdern das Ob und die Priorität aushandeln.
Wie erläutert, gibt es in Scrum kein Artefakt zur vollständigen Dokumentation der Anforderungen. Bereits realisierte Anforderungen befinden sich nicht mehr im Backlog, zukünftige sind noch nicht bekannt oder noch nicht detailliert.

Der Product Owner als Requirements Engineer

Scrum definiert nur drei Rollen: Der Product Owner ist verantwortlich für das Produkt, das Development-Team erstellt die Software und der Scrum Master achtet auf die Einhaltung der Regeln und ermöglicht dem Team ein ungestörtes Arbeiten. Für die Anforderungen und damit das Requirements Engineering ist der Product Owner verantwortlich. Zugleich ist er auch primärer Ansprechpartner für das Team in allen Detailfragen, die eben nicht vorab schriftlich festgelegt werden. Wie können nun die Aufgaben des PO mit denen des Requirements Engineer vereinbart werden?
Im klassischen Sinne entspricht der Product Owner am ehesten einem Produktmanager. Als solcher trägt er die alleinige Entscheidungshoheit über den Produktfortschritt, übernimmt Aufgaben wie die strategische Produktplanung, Definition eines Product Lifecycle, Auswertung der Marktanalyse (Standards, Innovationen, Wettbewerb) und pflegt gegebenenfalls den Kontakt mit dem Projektsponsor.

Auf der nächsten Ebene ist er für die Erhebung und das Management von Anforderungen zuständig (Abb. 2). Anhand der Priorisierung und der bisherigen Velocity des Teams ergibt sich eine gewisse Vorausschau für die Inhalte der nächsten Sprints. Anhand dieser Planung können nun die für spätere, in der Regel den übernächsten Sprint vorgesehenen Anforderungen ausgearbeitet werden, während die für den nächsten Sprint vorgesehenen in die Prüfung und Abstimmung gehen.
Das Prüfen und Abstimmen erfolgt in zwei Richtungen. Mit den Stakeholdern muss eine Übereinstimmung zu den fachlichen Inhalten und ihrer Korrektheit hergestellt werden, mit dem Team über die zur Realisierung erforderliche Klarheit. Für Ersteres stehen ihm die üblichen RE-Methoden zur Verfügung, für letzteres dienen regelmäßige Estimation Meetings und das Backlog Grooming (bzw. „Backlog Refining“).
Hier stellt der PO die Anforderungen dem Team vor und diskutiert mit diesem, bis es zu einer einhelligen Auffassung über die Lösung und den Aufwand zur Realisierung kommt (relativer Aufwand z. B. in Story Points). Kann kein gemeinsames Verständnis über die Anforderung gefunden werden, ist es ein Hinweis darauf, dass die Anforderung vom PO weiter verfeinert werden muss. Das Entwicklungsteam kann hierbei den PO bei seiner RE-Tätigkeit nachhaltig unterstützen, indem es Hinweise auf Abhängigkeiten und weitere Anforderungen geben kann.

Im Sprint Planning Meeting werden so viele Anforderungen in das Sprint Backlog übertragen, wie das Team zusichert, realisieren zu können. Die detaillierte Erarbeitung erfolgt während des Sprint im Dialog zwischen PO und Team („Individuen und Interaktionen …“), wobei signifikante Änderungen nicht gewünscht sind. Die Verantwortung des PO ist es dabei, dass im Sprint Planning Meeting genügend ausreichend beschriebene und abgestimmte Anforderungen vorliegen, damit dem Team nicht die Arbeit ausgeht.
Zusätzlich muss der PO auch noch in der Lage sein, situationsbedingt schnelle Entscheidungen zu treffen (er muss also flexibel sein), die er dann anschließend mit den Stakeholdern abstimmen kann.
Damit ist der Product Owner die zentrale Rolle in Scrum. Er benötigt sowohl das Fach-Know-how als Verantwortlicher für das Produkt als auch das Methoden-Know-how für das Requirements Engineering. Daneben haben sich Entscheidungskompetenz und kommunikative Fähigkeiten als Schlüsselqualifikationen herausgestellt.
Um allen Aufgaben gerecht zu werden, hat der PO die Möglichkeit, je nach Umfang und Aufwand durch einen Requirements Engineer oder ein RE-Team bei der operativen RE-Arbeit unterstützt zu werden. Abbildung 3 ist in diesem Sinne zu verstehen. Wenn der PO überwiegend als RE tätig ist und dem Team nicht als Ansprechpartner dienen kann, können die Werte der agilen Entwicklung und der Geist von Scrum nicht gelebt werden und wir haben es mit einem Fall von „ScrumBUT“ zu tun: Der PO schreibt lieber alles auf, statt mit dem Team zu kommunizieren.

Abb. 3: Der Product Owner als Requirements Engineer

[ header = Seite 3: Dokumentation der Ergebnisse ]

Exkurs: Agiles RE mit vielen Scrum-Teams
Innerhalb der Softwareentwicklung werden sowohl in fachlicher als auch in technischer Hinsicht unterschiedliche Maßnahmen notwendig, um den Product Owner vollumfänglich in seiner Tätigkeit als Requirements Engineer zu unterstützen. So können „virtuelle Teams“ aufgebaut und eingeführt werden. Das sind neue Teams bestehend aus Teammitgliedern einzelner Scrum-Teams. Diese virtuellen Teams analysieren die technischen Herausforderungen der Softwareprodukte und liefern unter anderem dem PO wichtige Hinweise für die Weiterentwicklung der Anwendungsarchitektur. Aus fachlicher Sicht kann der PO durch spezielle Kompetenzteams unterstützt werden, die ebenfalls virtuell organisiert sind. Diese Teams kümmern sich um konkrete fachliche Fragen und führen so Voranalysen durch, die dem PO für die Erstellung von Epics und User Stories dienlich sind. Die Teammitglieder können aus allen Bereichen des Unternehmens einbezogen werden, z. B. Vertrieb und Support. In großen und verteilten Projektumfeld sollten die eigentlichen Entwicklungsteams idealerweise als Featureteams organisiert werden. Zum einen regelt dies klar die Verantwortlichkeiten für die einzelnen Produktbereiche des Produktportfolios, zum anderen bauen die Teams so entsprechendes Fachwissen zusätzlich auf und unterstützen den PO in seiner Arbeit als Requirements Engineer. Die Definition der Aufgaben und Kompetenzen eines Product Owners (s. o.) zeigen, wie umfangreich und vielseitig diese Scrum-Rolle ist. Nach unserer Erfahrung ist es daher notwendig, dass der PO sich in dem einen oder anderen Aufgabenbereich durch zusätzliche Personen unterstützen lässt. Dies kann vor allem dann notwendig sein, wenn der PO durch das Produktmanagement gestellt wird.

Beispiel: Internationalisierung einer Kollaborationsplattform
An einem Beispiel möchten wir den RE-Prozess in einem Scrum-Projekt verdeutlichen. Eine Kollaborationsplattform soll als browserbasierte Anwendung umgesetzt werden und sich so leicht in Unternehmensportale einbetten lassen. Dies hat das Scrum-Team (PO, Dev-Team) bereits in den ersten drei Sprints anhand eines Prototyps herausgefunden und so definiert. Für dieses Produkt steht für den Produktteil „Persönlicher Bereich“ das Requirements Engineering an. Diesen Teil hat der Product Owner als Epic identifiziert. Seine eigenen Vorstellungen hat er bereits skizziert und als erste Version in User Stories überführt. Dabei nutzt er die gängige Form: „Als Angestellter möchte ich ein neues Dokument in meinem eigenen Bereich anlegen, um persönliche Notizen schreiben zu können.“ Die User Story erhält eine eindeutige ID, hier KP-12. Dies erleichtert die Klärung offener Fragen sowie die Dokumentation ungemein. Als Verantwortlicher für das Produkt hat der PO eigene Vorstellungen. Jedoch möchte er sich mit den Stakeholdern intensiv abstimmen, um weitere, relevante Anforderungen berücksichtigen zu können. Dazu hat er sich entschlossen, einen geeigneten Vertreter des Vertriebs, des Marketings und der Kommunikation sowie den Abteilungsleiter (Product Sponsor) in getrennten Terminen zu befragen. Im Gespräch mit einem Mitarbeiter aus Marketing und Kommunikation wurde erörtert, dass das Produkt international angeboten werden soll. Dabei müssen kulturelle Unterschiede einzelner Regionen weltweit berücksichtigt werden. Ganz konkret bedeutet dies, dass die Darstellung des Profils auch für den arabischen und asiatischen Markt geeignet sein muss; also auch rechtsbündig und entsprechende Zeichensätze darstellbar sind und unterstützt werden. Der PO notiert diese Informationen an den Anhang zu der User Story KP-12. Neben dieser User Story hat der PO bereits weitere als Teil der Epic „Persönlicher Bereich“ vorbereitet und diese ins Product Backlog gestellt. Um diese dem Entwicklungsteam vorzustellen, beruft er ein Backlog Refinement Meeting ein. Hier besprechen PO und Entwicklungsteam User Stories aus dem Product Backlog, um Unklarheiten zu identifizieren und offene Punkte zu besprechen. Auch dieses Meeting ist Teil des agilen Requirements Engineering, denn hier werden Anforderungen unter Zuhilfenahme von Akzeptanzkriterien konkretisiert; aber auch die erste technische Machbarkeit der User Story wird durch das Entwicklungsteams angesprochen. Normalerweise gibt es zwei Zustände, die eine besprochene User Story nach dem Meeting annehmen kann. Zum einen kann deutlich werden, dass die User Story (inklusive aller zusätzlichen Informationen, Dokumente usw.) noch nicht als fertig (abgestimmt) deklariert werden kann. Zum anderen sind sich alle Parteien einig und haben das gleiche Verständnis über die User Story erreicht; dann wird die Dauer der Umsetzung durch das Entwicklungsteam geschätzt. Konkret in unserem Beispiel mit User Story KP-12 stellt sich heraus, dass die Anforderung(en) des Marketings bezüglich der Internationalisierung aus Gründen des großen Umfangs in weitere User Stories ausgelagert werden sollte.

Dokumentation der Ergebnisse

Eine weitere offene Frage ist die nach einer Gesamtdokumentation des Produkts. Dies kann z. B. aufgrund gesetzlicher Vorgaben oder für die Wartungsphase erforderlich sein. Scrum macht keine Vorgaben zu einer Gesamtspezifikation. Die Summe der Backlog-Einträge kann diese nicht ersetzen, da aufgrund der inkrementellen Art der Produktentwicklung z. B. bei späteren Änderungen der Funktionalität die Backlog Items innerhalb des Product Backlogs nicht konsolidiert werden.
Mit den Akzeptanzkriterien und der Definition of Done (DoD) bietet uns Scrum die geeigneten Instrumente für die Dokumentation – dort legen der Product Owner und das Team in Übereinstimmung mit den Projektzielen fest, was zur Erledigung einer Aufgabe gehört:

• Neben den obligatorischen automatischen und manuellen Testfällen kann dies eine Gesamtspezifikation, Architektur- und Entwicklerdokumentation, UML-Modelle etc. umfassen. Kurz: alles, was PO, Anforderungsgeber und Team für wichtig halten.
• Es liegt in der Verantwortung des Scrum-Teams, dass die Dokumentation bei der Abnahme jeder Anforderung vollständig und für Betriebs- und Wartungszwecke ausreichend ist.
• Das Team berücksichtigt diese zu erbringenden Ergebnisse in der Aufwandsschätzung für jede Anforderung.
• Einzelne Aufgaben wie z. B. die Gesamtspezifikation können auch vom PO (bzw. dem RE-Team) übernommen werden, um das Team zu entlasten – je nach Vereinbarung über die DoD.
• In stark regulierten Branchen gehört eine umfassende Dokumentation zu den Qualitätsanforderungen, ohne deren Erfüllung das Produkt keine Zulassung erhält.
• Der PO muss abwägen, welcher Nutzen den Aufwand rechtfertigt.

Die Erfüllung der Akzeptanzkriterien und der Definition of Done ist das zentrale Kriterium zur Feststellung von „Fertig!“. Eine Dokumentation, die vom PO nicht abgenommen wird, heißt, dass die Aufgabe nicht erledigt ist und im nächsten Sprint abgeschlossen werden muss. Der PO darf natürlich nicht „weich“ werden und sie trotzdem abnehmen (außer ihm ist die Umsetzung weiterer Anforderungen wichtiger).
Damit steht am Ende jedes Sprints neben der lauffähigen Software auch die erforderliche Dokumentation zur Verfügung. Diese entspricht dabei genau den Anforderungen des POs, nicht mehr, nicht weniger und auch nicht anders.

Fazit

Ein kritischer Erfolgsfaktor für agile Projekte ist Vertrauen. Der Verzicht auf detaillierte schriftliche Vereinbarungen erfordert:

• Vertrauen darauf, dass mündliche Absprachen eingehalten statt schriftlich fixiert werden.
• Vertrauen des Managements in die Selbstorganisation des Entwicklungsteams.
• Vertrauen in die Entscheidungsfähigkeiten des Product Owners.
• Vertrauen zwischen Auftraggeber und Dienstleister.

Ohne dieses Vertrauen ist agiles Arbeiten nicht möglich. Dafür ergibt sich eine Reihe von Vorteilen insbesondere für den Fachbereich:

• Keine langen Spezifikations- und Testphasen am Beginn und Ende
• Dafür kontinuierliche Mitarbeit
  o Erstellung/Input für User Stories
  o Test der Software
  o Review-Meeting
•    Kein eigener Change-Prozess notwendig
•    Schnellere Einführung
•    Jederzeit neue Anforderungen möglich

Unsere Erfahrungen aus Scrum-Projekten lassen sich zu folgendem Fazit zusammenfassen:

• Sicherstellung der agilen Fähigkeiten auch beim Auftraggeber: In welchem Maße kann der Auftraggeber agil arbeiten?
• Unzureichend geklärte und kommunizierte Anforderungen sind schwierig zu schätzen.
• Bei neuen Erkenntnissen aktualisierte Schätzungen sind wichtig für eine realistische Releaseplanung.
• Entscheidend für die Schätzung ist die Qualität der User Stories und Akzeptanzkriterien.
• Über die genannten Anforderungen an die Kompetenz des Product Owners ist darüber hinaus auch noch ein gewisses Maß an technischem Know-how erforderlich, um
    o Lösungsvorschläge des Teams einschätzen und ihre Auswirkungen zu beurteilen
    o Die richtigen Fragen an die Stakeholder und das Team stellen zu können.

Eine ausführliche Darstellung unserer Erfahrungen des Product Owners als Requirements Engineer in einem konkreten Projekt finden Sie hier.
Diese Erfahrungen zeigen, dass sich Scrum mit professionellem Requirements Engineering verbinden lässt. Durch den RE-Vorlauf je Sprint sowie die Unterstützung des PO durch ein RE-Team gelangen wir zu einem erweiterten Scrum, als ScrumAND – Scrum plus zusätzliche Dinge, wie etwa zusätzliche Prozesse, die nicht die Scrum-Methodik verändern.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -