IREB RE@Agile Primer

A daily ceremony to discuss the current state of work within a ➔sprint. The Daily Scrum is an element of ➔Scrum.

A team of people whose members have expertise in various functions of a task (for example, architecting, coding, testing, designing databases and user interfaces, etc.) 

A diagram plotting the units of work that remain to accomplish on a time scale.

1. (General) Able to move quickly and easily.

2. (General) Quick, smart, and clever.

3. (In software development) A (software) ➔product development approach which builds a product ➔incrementally by dividing work into ➔iterations of fixed duration (➔timeboxes). Agile development is characterized by focusing on delivering a working product in each iteration, collaboration with stakeholders with frequent feedback and adaptation of plans after each iteration based on feedback and changed requirements. 

A set of conditions (typically associated with a ➔user story) that must be fulfilled by any implementation. Such conditions may be, for example, expected outcomes for sample input data or expected speed or volume to be achieved.

Kürzere Iterationszeiten steigern das Arbeitspensum für die Stakeholder:

1. Stakeholder müssen während der gesamten Iteration verfügbar sein, um am Backlog mitzuarbeiten und Informationen für die nächste Iteration zu liefern.

 2. Stakeholder müssen die vom Team erarbeiteten Ergebnisse durchsehen und Feedback abgeben.

3. Stakeholder müssen immer wieder den Arbeitskontext wechseln (Tagesgeschäft vs.Projektarbeit).

Längere Iterationszeiten verringern den Druck, reduzieren aber auch die Möglichkeiten für die Produktentwicklung, das Backlog zu beeinflussen.

Die Iterationsdauer muss unter Berücksichtigung der Verfügbarkeit der Stakeholder festgelegt werden. Stakeholder sind in der Regel nicht zu 100 % für Entwicklungsaktivitäten verfügbar, da sie noch andere Verpflichtungen haben.

Faustregel: Eine kürzere Iterationsdauer ermöglicht häufiges Feedback und mehr Möglichkeiten, Fehler frühzeitig zu erkennen; daher beschleunigen kürzere Iterationszeiten die Entwicklungsaktivitäten tendenziell. Wenn eine kurze Zykluszeit ein inakzeptables Pensum für die Stakeholder darstellt, sollte für die Iterationsdauer ein Kompromiss gefunden werden.

Ein weiterer Faktor ist der durchschnittliche Umfang und die Komplexität von Backlog Items. Grössere oder komplexere Backlog Items erfordern mehr Zeit zum Verständnis und für die Analyse. Daher kann die Zykluszeit verlängert werden, um diese Backlog Items innerhalb einer einzigen Iteration abzuwickeln.

Die Entscheidung für längere oder kürzere Zykluszeiten muss gemeinsam im Team getroffen werden, unter Abwägung der Zeit, die für die Analyse benötigt wird, mit dem Ziel, frühzeitig Feedback zu erhalten. Veränderte Zykluszeiten beruhen immer auf dem Prinzip „Inspect and Adapt" (wobei bisherige Erfahrungen nicht immer eine Zukunftsgarantie sind). Die Änderung der Zykluszeit sollte vor, aber niemals während eines Sprints stattfinden. 

Der «richtige» Aktualisierungszyklus für das Product Backlog ist abhängig von der Skalierung und Detailierung der Anforderungen, deren Komplexität/Abhängigkeiten sowie von der Anzahl involvierter Entwicklungsteams. Zudem muss der Entscheidungsfindungsprozess der Organisation beachtet werden. In Organisationen in denen z.B. Entscheidungsgremien selten stattfinden, muss das Prinzip kontinuierlicher Verfeinerung konkret in Meetings umgesetzt werden, an denen alle betroffenen Stakeholder teilnehmen. Das RE dient zur Vorbereitung und als Entscheidungshilfe für solche Meetings.

Generell: Die Backlog Aktualisierung aufgrund des Sprint Review Feedback ist bei geringer Skalierung und bei detaillierten Anforderungen möglich, für die Auswirkungen einer Änderung schnell analysiert und erfasst werden können, und zwar in einer Umgebung mit ein oder zwei kleinen Entwicklungsteams. Anforderungen in komplexen Umgebungen mit vielen Abhängigkeiten können nicht kurzfristig geändert werden (Analysebedarf und Abhängigkeit der Stakeholder Verfügbarkeit für Wissenstransfer).

Die Bestimmung der Validität (= Gütekriterium) eines Backlog Items ist eng mit seinem Detaillierungsgrad verbunden. Der Aufwand für die Ausarbeitung und Validierung einer Anforderung vor der Implementierung muss dem Aufwand der Anforderungsimplementierung mit anschliessender Validierung in der ausgelieferten Software gegenüberstellt werden.

Kann eine Backlog Item mit tragbarem Aufwand vor der Implementierung durch die Stakeholder Präferenzen validiert werden, sollte die Validierung vorgelagert stattfinden.

Ebenfalls sollten Backlog Items mit hohem Risiko (z. B. kritische Geschäftsfunktionen, sicherheitsrelevante Funktionen, innovative Funktionalitäten) oder mit hohen Testkosten für die Implementierung (z. B. wenn die Software in einem teuren Prototyp getestet werden muss) vor der Implementierung validiert werden.

Typische Beispiele für diese Art von Anforderungen (inkl. Validierungsansatzes): das Benutzeroberflächendesign (= UI-Mock-ups), Berechtigungs- und Authentifizierungsmechanismen (= Reviews von Anwendungsfällen), in dem System zu speichernde Datenstrukturen (= Reviews von Datenmodellen) und Schnittstellenanforderungen zu vorhandenen Systemen (= Reviews von Aktivitätsdiagrammen).

Der Detaillierungsgrad eines Backlog Items beschränkt die Freiheit des Entwicklungsteams bei dessen Realisierung. Alle Aspekte eines Backlog Items, die nicht definiert worden sind, liegen in der Entscheidungsgewalt des Teams, was dem Team - innerhalb der definierten Geschäftsgrenzen - mehr Kreativität erlaubt.

Faustregel: Wenn das Entwicklungsteam über ausreichende Kompetenz für die Entscheidung über die Details eines Backlog Items verfügt (z. B. wenn ein Experte für Authentifizierungen und Berechtigungen im Team ist), dann sollte diese Entscheidung dem Team überlassen werden.

Agile Methoden lassen sich als ein kontinuierlicher, iterativer Prozess charakterisieren, in dem ein System basierend auf den Backlog Items inkrementell entwickelt wird. Aus Requirements-Engineering-Perspektive lassen sich fünf Parameter identifizieren, die diesen Prozess prägen:

• Definition erster Anforderungen
• Detaillierungsgrad für Backlog Items
• Validität von Backlog Items
• Feedback zum Backlog und dessen Aktualisierung
• Zeitplan für den Entwicklungszyklus

Vorab-RE vs. kontinuierlichem RE

Die erste Definition des Backlogs wird benötigt, um den iterativen Prozess zu starten. Dieses wird als «Vorabdefinition» verstanden. Ob diese Vorabdefinition eine vollständige und detaillierte Spezifikation aller Anforderungen ist hängt von den vorhandenen Informationen ab, die für die erste ersten Iteration benötigt wird. Abhängig von System und Kontext können Anforderungsunsicherheiten zu Prozessbeginn zu Verzögerungen, Kosten oder zum Scheitern des Projekts führen (=Vorteil Vorab-RE). Im Gegenzug kann sich ein zu später Start negativ auf die Markteinführungszeit oder auf Kundennutzenbefriedigung auswirken (= Nachteil Vorab-RE).

Lösung: Anforderungen welche grosse Auswirkungen auf die Architektur, auf die Realisierbarkeit der Lösung insgesamt oder auf zentrale Entscheidungen in Bezug auf Infrastruktur und Hardware haben, müssen zu einem früheren Zeitpunkt ermittelt und detailliert erfasst werden sollten (= Vorab-RE). Anforderungen mit geringeren Auswirkungen können dann im Verlauf der Iterationen in einem kontinuierlichen Prozess verfeinert werden (= kontinuierlichem RE).

In den iterativen und inkrementellen Prozessen agiler Entwicklung wird das Requirements Engineering zu einem kontinuierlichen Prozess, der Anforderungen just in time liefert und verfeinert, und zwar genau in der für den Entwicklungszyklus erforderlichen Detailtiefe.

Die zusätzlichen Abstraktionsschichten bedeuten, dass es mehr Rollen für das Management der RE-Aktivitäten gibt (Product Owner, Produktmanager, PortfolioManager oder Business-Analyst). Jede Rolle erstellt für ihren jeweiligen Problembereich entsprechende RE-Artefakte (Epics, Features, User-Storys und die Verfolgbarkeit zwischen diesen). Es sind zusätzliche Meetings für RE-Aktivitäten erforderlich (z. B. Story-Times, FeatureTimes, Systemdemos), und die Kommunikation mit Stakeholdern wird von den unterschiedlichen Rollen auf den verschiedenen Ebenen in der Organisation ausgeführt.

Durch die Skalierung werden umfassende Anforderungen zerlegt und angemessen unter den zahlreichen agilen Teams verteilt. Die RE-Techniken helfen bei der Strukturierung von Problemanalysen und bei der Verfeinerung von groben in detailliertere Anforderungen (z.B. Features und User-Storys für einzelne Teams). Durch diesen strukturierten Ansatz können teilweise autonome, agile Entwicklungsteam die Anforderungen teamintern weiter verfeinern.

Wenn Teams an unterschiedlichen Standorten arbeiten, kommt eine weitere Herausforderung hinzu. Die Komplexität beim Management der Kommunikation nimmt aufgrund möglicher Zeitverschiebungen oder sprachlicher Unterschiede zu. Die grösste Herausforderung liegt meist in den kulturellen Unterschieden. Da Kommunikation eine der Hauptaufgaben von Product Ownern und Produktmanagern ist, hat dies einen erheblichen Einfluss auf die erforderlichen Kompetenzen der RE-relevanten Rollen.

Es gibt zahlreiche Frameworks, welche eine Skalierung von Scrum und agilen Entwicklungsprozessen unterstützen:  

• Scaled Agile Framework (SAFe): SAFe ist eine Wissensdatenbank mit bewährten Erfolgsmustern für die Implementierung von Lean-Agile-Software- und -Systementwicklungen für Unternehmen.
• Large-Scale Scrum (LeSS): LeSS ist die Anwendung von Scrum auf zahlreiche Teams, die zusammen an einem Produkt arbeiten.
• Large Nexus: Nexus ist ein Framework, das auf das Zentrum der Skalierung abzielt: Cross-Team Abhängigkeiten und Integrationsprobleme.  
• Scrum@Scale: Das Scrum-at-Scale-Framework ist eine minimale Erweiterung des zentralen Scrum Frameworks, das die modulare Struktur im Kern des Scrum-Frameworks beibehält und zudem erlaubt, dass sich Scrum-Implementierungen massgeschneidert auf die einzigartigen Bedürfnisse des Unternehmens skalieren lassen.
• Scrum Disciplined Agile Delivery (DAD): Disciplined Agile AD ist ein Framework für Prozessentscheidungen für Unternehmen, die sich an Lean-Prinzipien orientieren. Es ist taktisch auf Teamebene und strategisch über das gesamte Unternehmen hinweg skalierbar.

Für die effiziente Teams Zusammenarbeit gibt es zwei Ansätze:

1. Methoden aus dem Vorgehen mit einem Team verwenden

2. Zusätzliche Konzepte zur Organisation der Kommunikation und Verantwortlichkeiten einführen

1. Methoden aus dem Vorgehen mit einem Team verwenden: Zusätzliche Rollen und Artefakte widersprechen der agilen Denkweise, erhöhen die Komplexität und führen zu mehr Verwaltungsaufwand. Die Kommunikation und Koordination zwischen den Teams wird gewöhnlich durch die Product Owner der Teams initiiert, dann jedoch von den Teamvertretern ausgeführt. Über Konstruktionen wie „Communities of Practice" können die Teammitglieder über die Teams hinweg Erfahrungen austauschen und Gesamtprozesse koordinieren.

2. Zusätzliche Konzepte einführen:  Bei diesem Ansatz werden grössere Probleme in kleinere Probleme unterteilt. Diese werden durch unterschiedliche Rollen für verschiedene Abstraktionsebenen gemanagt. Durch das Unterteilen müssen weitere Artefakte für die unterschiedlichen Abstraktionsebenen eingeführt werden (z. B. Business Epics, Architectural Epics, Investment-Themen, Features, User-Storys).

Abhängig von dem verwendeten Framework werden auch noch weitere Rollen mit Verantwortung für die unterschiedlichen Abstraktionsebenen eingeführt (z. B. PortfolioManager, Produktmanager, Product Owner). Aufgrund der steigenden Komplexität sind ausserdem zusätzliche Artefakte und Rollen erforderlich, um die Planung und Kommunikation unter den verschiedenen Teams zu managen und integrierte Ergebnisse für jede Iteration zu erzielen (z. B. Roadmaps und Release-Manager). Darüber hinaus müssen spezielle Meetings organisiert werden, um die Kommunikation zwischen neuen und bereits etablierten Rollen zu fördern. Das RE bietet zahlreiche Techniken, die dabei helfen könnten, grössere Probleme zu unterteilen und die neuen Rollen auf den unterschiedlichen Abstraktionsebenen zu unterstützen (z. B. Kontextmodellierung, Zielmodellierung).

Beide Ansätze haben ihre Vor- und Nachteile; die Anwendbarkeit ist individuell und unternehmensabhängig.

Nach welchen Dimensionen lassen sich Teams organisieren, dass eine cross-funktionale Zusammensetzung (Mindestgrösse) erlaubt und gleichzeitig eine effiziente (maximale Grösse) Kommunikation und Abstimmung ermöglicht?

• Das Organisieren nach funktionalen Linien (z. B. Geschäftsbereich, Funktion) hat den Vorteil, dass sich das betriebswirtschaftliche Wissen in einem einzigen Team konzentriert. Das kann die Ermittlung von Anforderungen erleichtern (Reduktion der Anzahl der zu berücksichtigenden Stakeholder). Ein Nachteil ist, dass die Bereitstellung von umfassenden Funktionalitäten in einem Geschäftsbereich unterschiedliche technische Besonderheiten involviert, wie UI-Design, Datenbanken und zentrale Plattformen wie ein ERP System, durch die man leicht an die Grenzen der maximalen Grösse eines effizienten Teams stösst.
• Alternativ liesse sich die Entwicklung auch nach technischen Linien (d. h. in Teams, die sich etwa auf technische Komponenten oder Plattformen) organisieren. Der Vorteil dieser Teams sind die tiefgehenden Kenntnisse in ihren jeweiligen technologischen Gebieten. Ein Nachteil sind die Abhängigkeiten, die zwischen den Teams entstehen, die zusammenarbeiten, um das gesamte Produktinkrement termingerecht zu liefern.

Die Skalierungs-Frameworks zeigen, wie man mit dieser Situation umgehen kann. Requirements-Engineering-Aktivitäten müssen auf das Framework ausgerichtet werden, um eine gemeinsame Sicht auf die lieferbaren Ergebnisse zu erreichen.  In diesem Szenario spielt das RE eine besonders wichtige Rolle: zuerst bei der Aufgliederung der Geschäftsziele und Anforderungen in einzelne Untersystemanforderungen, die dann Teams zugewiesen werden können, und zweitens bei der Begleitung der Entwicklung, um sicherzustellen, dass das Ergebnis einer integrierten Lösung erreicht und damit der betriebswirtschaftliche Nutzen geliefert wird.

Die beste Lösung kann eine Mischung aus allen Arten von Teams darstellen, um von den Ideen sog. Feature-Teams zu profitieren und gleichzeitig unternehmensspezifische Einschränkungen zu berücksichtigen.

Die agilen Werte direkter, täglicher, nicht-hierarchischer Kommunikation spiegeln sich typischerweise in kleinen, fest miteinander verwachsenen Teams wider. Empfehlung: Scrum Teams mit 5 bis 11 Mitglieder (3 bis 9 Entwicklungsteammitglieder + Product Owner + Scrum Master). Die Teammitglieder sollten sich im Idealfall physisch am selben Standort befinden und in Bezug auf betriebswirtschaftliche und technische Kompetenzen cross-funktional aufgestellt sein.

Faktoren welche das in grösseren Organisationen verhindern sind:

• Bei komplexen Problemen kann die Einbeziehung von Stakeholdern und Wissen aus verschiedenen Unternehmensbereichen erforderlich sein, die sich in einem einzigen Team nicht so einfach vereinen lassen.
• Bei komplexen Problemen kann zudem die Einbeziehung einer Reihe von technischen Experten und Wissen erforderlich sein, die sich in einem einzigen Team nicht so einfach vereinen lassen.
• Der bis zu einem festgelegten Einführungstermin erforderliche Umfang geht über das mit der erreichbaren Geschwindigkeit eines einzelnen Teams Mögliche hinaus.
• Mitarbeiter in globalen Unternehmen arbeiten unter Umständen an verschiedenen geografischen Standorten.

Der Begriff „Scaled Agile" (skalierte Agilität), wird verwendet wenn mehrere Teams zusammen an einem Produkt/einer Lösung mit gemeinsamen Zielen arbeiten. Bei Scaled-Agile-Ansätzen müssen Entscheidungen zur Organisation von Scrum-Teams getroffen werden und dazu, wie die Kommunikation unter den Teams koordiniert werden soll. Ziel dabei ist es, einen effizienten Ansatz für den Umgang mit komplexen Problemen zu erreichen und dabei möglichst viele Vorteile agiler Methoden beizubehalten.

Disziplinen und Teams: Agile Methoden, arbeiten mit cross-funktionalen Teams. Abgesehen von den Expertenrollen (PO und Scrum Master) decken die Teammitglieder unterschiedlichen Kompetenzbereiche ab und unterstützen gemeinsam die RE- oder Testaktivitäten. Ziel des Teams ist es, Kundenanforderungen vollständig zu liefern, unabhängig von technologischen oder organisatorischen Elementen.

IT-Manager: Streben in  Organisationen ein Gleichgewicht zwischen Spezialisten und Generalisten an. Die Teamstruktur spielt die Produkt- resp. Systemstruktur. Wenn ein Unternehmen seine Teams nach Komponenten / Systemen organisiert, ist eine Skalierung durch Steigerung der Anzahl von Teams nicht hilfreich (= erzeugt mehr Abhängigkeit). Skalierung ist nur bei Anz. Teammitgliedern möglich (= erzeugt Kommunikationsaufwand). Cross-funktionale Teams, die alle Fähigkeiten zur Auslieferung vollständiger Inkremente übernehmen, lassen sich leicht skalieren (aber Aufbau ist schwierig und zeitintensiv).

Product Owner vs. Projektmanager: POs tragen aufgrund der Priorisierung mehr Verantwortung als REs. Müssen aber dazu ermächtigt sein, Geschäftsentscheidungen zu treffen. Einige PM Tasks, sind in agilen Ansätzen nicht mehr erforderlich, da die Entwicklungsteams sich selbst organisieren (Anforderungen detailieren, aufgliedern und innerhalb des Teams zuweisen). In einem agilen Umfeld müssen IT-Manager ein klares Setting der Vision für die agile Entwicklung entwerfen und die kulturellen Voraussetzungen klar kommunizieren, damit dieser Ansatz erfolgreich sein kann.

Requirements Engineering: RE kann Teil des Entwicklungsteams sein oder ein eigenes Team bilden, welches den PO unterstützt. Beide Ansätze haben Vorteile und verletzten keine agilen Prinzipien.

Agilität verbessert direkte und nicht-hierarchische Beziehungen innerhalb der Organisation und ermöglichen mehr Flexibilität bei der Entwicklung von Produkten im Laufe der Zeit. In grösseren Unternehmen, die traditionell in Top-down-Managementstrukturen geführt werden, wird grosser Wert auf Planung und Berechenbarkeit gelegt (z.B. Projekt- und Ressourcenplanung).

Der agile Ansatz ist produktorientiert. Dabei wird ein Backlog mit Produktverbesserungen bearbeitet, die in einem iterativen Prozess kontinuierlicher Entwicklung implementiert werden. Agilität an sich definiert allerdings kein eigentliches Enddatum. So lange noch Verbesserungen ausstehen oder Vorteile zu realisieren sind, sollte die Arbeit fortgeführt werden, wenn die Vorteile gegenüber dem Aufwand bzw. den Kosten überwiegen.

Die Unterschiede in der Perspektive oder Terminologie diesen beiden können Spannungen und Missverständnisse zwischen agiler Softwareentwicklung und nicht-agilen Organisationen verursachen.

Ein Ansatz zur Auflösung solcher Spannungen ist, dass die Softwareentwicklung strikt nach agilen Prinzipien erfolgt, die Funktionen des Portfolio- und Programmmanagements dagegen ein höheres Level an Planung und Kontrolle bieten, für die Ansätze aus beiden Richtungen verwendet werden. Ein solcher Ansatz funktioniert nur, wenn konzeptuelle Lücken zwischen der geplanten Erfüllung von Geschäftszielen und Funktionalitäten auf Portfolio- und Programmlevel sowie einer iterativen und flexiblen Lieferung einzelner Softwarefunktionalitäten überbrückt werden können.

Durch RE kann eine Differenzierung der Anforderungen auf unterschiedlichen Abstraktionsebenen (Geschäftsebene = Portfolio und Programmebenen und detaillierte Softwareanforderungen = Entwicklungs-Backlog) stattfinden. Als Konsequenz werden Anforderungen als „Just-in-Time"-Anpassungen definiert und nur so detailliert spezifiziert, wie sie für das aktuelle Planungslevel gerade benötigt werden.

Es ist Aufgabe der Entwicklungsorganisation in einem Unternehmen, Lösungen und Services für Unternehmenskunden bereitzustellen (sowohl innerhalb als auch ausserhalb der Organisation).

Agile Entwicklungsprozesse stellen den Kunden in den Mittelpunkt der Produktentwicklung. Das bedeutet, dass der Kunde während des gesamten Lebenszyklus der Produktentwicklung einbezogen wird, dass aktiv Feedback zu gelieferten Inkrementen eingeholt wird und neue Anforderungen aufgenommen werden, die in Einklang mit den Anforderungen des Unternehmens stehen.

Durch die laufende Einbeziehung des Kunden wird auch das RE zu einem kontinuierlichen Prozess. Die verantwortliche Person (=Product Owner), sollte mit einer offenen und direkten Kommunikation mit dem Kunden austauschen, neue Bedürfnisse und veränderte Erwartungen erfragen und diese in einem Backlog erfassen.

In der Praxis kann diese Kommunikation auf verschiedene Weise stattfinden. Hat der Kunde täglich Zeit für die Zusammenarbeit mit dem Team, so kann die Kommunikation direkt und überwiegend informell stattfinden, und es müssen nur Ergebnisse oder Entscheidungen dokumentiert werden. Aufgrund von unterschiedlichen Faktoren (z.B. geografische Verteilung der Mitarbeiter oder einfach mangelnde Verfügbarkeit) ist eine direkte Interaktion nicht immer praktikabel. Daher muss der Austausch effizient geplant werden. Z.B. indem man Kundenvertreter zu regelmässigen Planungs- und Review-Meetings einlädt oder bereits in einer frühen Phase intensive Sitzungen in Timeboxes durchführt (z. B. Design Thinking) und die Ergebnisse im Backlog erfasst.

Die Organisationsstruktur eines Unternehmens beeinflusst die Anwendbarkeit von agilen Entwicklungsprozessen massgeblich. Agile Prinzipien sind leicht verständlich und agile Verfahren wie Scrum lassen sich bei Startup- oder kleinen Unternehmen einfach einsetzen. Bei grossen Organisationen mit festgefahrenen Denkmustern sind sie dagegen schwer zu implementieren. Die Einführung von agilen Entwicklungsmethoden scheitern oft an Organisationseinheiten, die nicht zu Veränderungen in der Lage ist und dadurch die Unterstützung, welche ein erfolgreiches Scrum Team benötigt, nicht geben können.

Wieso muss sich bei der Einführung von agilen Methoden das gesamte Unternehmen verändern?

1. Die nachfragende Organisation (= Auftraggeber) muss konstant «gute» Anforderungen liefern (INVEST-Prinzip), damit die Entwicklung in gleichmässigem Tempo voranschreiten kann.

2. Die Personalabteilung muss verstehen, welche Mitarbeiter sie einstellen muss, damit Scrum-Teams die geeignete Unterstützung erhalten.

Auch wenn agile Prozesse bereits in der Produktentwicklung eingeführt werden, arbeitet in vielen Fällen nicht unbedingt das gesamte Unternehmen nach agilen Prinzipien.

Ebenfalls herausfordernd ist, wenn zur Lösung eines komplexen Problems mehrere agile Teams benötigt werden.

In den agilen Entwicklungsprozessen stellen die Backlogs ein zentrales Artefakt für die Bearbeitung von Anforderungen dar. Anders als beim herkömmlichen RE wird nur die  beste Version aller Anforderungen zur Implementierung beibehalten. Backlog Items werden gelöscht, sobald das Produkt ausgeliefert wird (= Kein Versions- oder Änderungsmanagement).

Backlog Anforderungsmanagement:

1. Anforderungspriorisierung: Bestimmung des betriebswirtschaftlichen Werts, um zu entscheiden, wann diese Anforderungen implementiert wird. Je höher dieser ist, destso schneller wird die Anforderung implementiert. (Agilen Entwicklungsprojekten versuchen den höchsten betriebswirtschaftlichen Wert zu erfüllen).

2. Anforderungseinschätzung: Bestimmen, wie viel Arbeit die Erfüllung der Anforderungen bedeutet. 

Es sollte ein Ausgleich anstreben werden zwischen der Minimierung des Verwaltungsaufwands, der Möglichkeit einer frühen Auslieferung funktionierender Lösungen und den längerfristigen Bedürfnissen der Organisation (z.B. Einhaltung gesetzlicher Vorgaben oder Betriebsdokumentation).

Fazit: Die Ermittlung, Dokumentation, Validierung sowie das Anforderungsmanagement müssen in agilen Entwicklungsprozessen ausgeführt werden. Diese Techniken können bei agiler und nicht-agiler Entwicklung unterschiedlich sein, doch das Lernen von der jeweils anderen Richtung führt zur besten Lösung, da es die Stärken kombiniert und die Verschwendung oder den Verwaltungsaufwand reduziert. Diese Arbeitsweise steht für die fünf Werte von Scrum (Commitment, Mut, Konzentration, Offenheit und Respekt) und deren Darstellung in den drei Pfeilern von Scrum (Transparenz, Inspektion und Anpassung).

Beim RE liegt der Schwerpunkt der Anforderungsvalidierung auf Methoden wie Reviews, Walkthroughs, Inspektionen oder perspektivenbasiertem Lesen.

Bei Agile Methoden werden Anforderungen durch frühes und häufiges Feedback zu werthaltigen Produktinkrementen validiert. Ein bewährtes Verfahren dafür sind automatisierte Regressionstests, die eine kontinuierliche Validierung der Entwicklung und der damit verbundenen Anforderungen ermöglichen. Zum Ziel der Anforderungsvalidierung zählt zudem das Identifizieren fehlender, mehrdeutiger oder falscher Anforderungen sowie strittiger oder widersprüchlicher Anforderungen, bei denen Abstimmungen und Konfliktlösungstechniken angewandt werden können.

Da die iterative, inkrementelle Entwicklung bei agilen Methoden eine zentrale Strategie ist, sinkt der Bedarf an einer formalen Validierung von Dokumenten. Sie wird durch eine konstante Abstimmung unter allen Stakeholdern zu den Anforderungen ersetzt, sodass Konflikte frühzeitig erkannt und gelöst werden. Eine weitere Möglichkeit zur Validierung von Anforderungen sind automatisierte (Regressions-) Tests.

Die formale Validierung wird auch dadurch reduziert, dass schnelle Ergebnisse in Form von integrierten Produktinkrementen vorliegen. Wenn das Inkrement nicht allen Anforderungen sämtlicher Stakeholder entspricht, wird das Delta in Form von neuen Anforderungen in das Product Backlog aufgenommen und zusammen mit allen anderen Backlog Items bewertet und priorisiert.

Dennoch sind Walkthroughs des Product Backlogs, Besprechungen des betriebswirtschaftlichen Werts, Besprechungen von Risiken sowie sofortige Abstimmungen von Anforderungen allesamt nützliche Techniken im agilen Requirements Engineering. All diese Techniken können in Verfeinerungsmeetings angewendet werden.

In agilen Entwicklungsprozessen werden Anforderungen in Backlogs organisiert (z.B. Product und Sprint Backlog). Sie werden als Story-Cards dokumentiert und mit Anmerkungen zum betriebswirtschaftlichen Wert und der Priorität versehen. Story-Cards limitieren durch die Kartengrösse die notierten Informationen und erleichtern somit die Konzentration auf das Grundlegende.

Das Dokumentieren von Anforderungen ist kein Selbstzweck, sondern fördert die Stakeholderkommunikation. Der  Formalismus lässt sich minimieren, indem Details verbal kommuniziert werden und die Dokumentation auf das benötigte Minimum reduziert wird. Faktoren sind: der Projektumfang, der Anz. Stakeholder oder Regulatorien.

Die Verwendung eines „lebenden" Product Backlog ist effiziente, doch sie ist nicht immer ausreichend. Deshalb werden folgende Dokumentationsprinzipien angewendet:

1. Dokumentation für gesetzliche Zwecke: Die erforderliche Dokumentation muss aus den Gesetzen abgeleitet werden und ist untrennbarer Bestandteil des Produkts.
2. Dokumentation zum Zwecke der Bewahrung (z.B. für die gewährleistet Unabhängigkeit von der Erinnerung einzelner Teammitglieder): Das Team entscheidet, was zum Zwecke der Bewahrung dokumentiert wird.
3. Dokumentation für Kommunikationszwecke (geografisch verteilte Teams oder Sprachbarrieren verhindern eine direkte Kommunikation): Ein Dokument wird als zusätzliches Kommunikationsmittel erstellt, wenn Stakeholder oder das Entwicklungsteam dem Vorhandensein der Dokumentation einen Wert beimessen. Verlief die Kommunikation erfolgreich, sollte das Dokument archiviert werden.
4. Dokumentation zum Zwecke von Überlegungen (Aufschreiben = Teil des Erkenntnisprozesses): Die nachdenkende Person entscheidet über die Dokumentform, die ihre Denkvorgänge am besten unterstützt und muss dies nicht rechtfertigen. Das Dokument kann anschliessend kann verworfen werden.

Im agilen Entwicklungsprozess beruht das Ermitteln der Anforderungen auf einem intensiven Austausch der Stakeholder (inkl. Entwicklungsteam). Für die informelle, direkte Kommunikation kann eine Mischung aus Befragungen und Brainstorming angewendet werden. Für die Verfeinerung der Backlog Items können die XP Techniken wie «On-Site Customer» ebenfalls erfolgreich sein. Das Ziel ist ein eingehenderes Verständnis davon zu gewinnen, was tatsächlich benötigt wird.

Prototypen und Produktinkremente sind weitere Möglichkeit, um mehr über Anforderungen zu erfahren. Sobald ein Produktinkrement im Sprint Review oder in einem Demo-Meeting präsentiert wird, können neue Ideen entstehen, die direkt in das Product Backlog übernommen und vom Product Owner priorisiert werden können.

Das RE bietet zusätzliche Techniken zur Erkennung und Ermittlung von Anforderungen, als im Kontext der agilen Entwicklung angewendet werden. Dazu zählen Frage/Antwort-Techniken (z.B.  Fragebögen), Beobachtungstechniken, Artefakt-basierte Techniken (Wiederverwendung, Systemarchäologie usw.) oder Kreativitätstechniken wie Design Thinking. Diese Techniken unterstützen das Erfassen von Anforderungen im User-Story-Format. Sie dienen aber mehr als Basis für strukturierte Gespräche als eine Vorgabe für die Implementierung.

Somit können agile Entwicklungsprozesse in hohem Masse von nichtagilem RE profitieren, indem die verschiedenen RE Ermittlungstechniken angewendet werden. Intensive Kommunikation zwischen den Stakeholdern und schnelles Feedback durch Produktinkremente sind zwar hervorragende Ideen, doch hinter der Ermittlung von Anforderungen steckt noch mehr. Falls es z.B. extrem viele Stakeholder gibt, ist die verbale Kommunikation nicht ausreichend. Oder um innovative unterbewusste Anforderungen ans Tageslicht zu bringen, ist unter Umständen der Einsatz von Kreativitätstechniken erforderlich. Beim Erschliessen neuer Technologien sind Spikes (einfache Inkremente in Timeboxes zum Erschliessen potenzieller Lösungen) eine hervorragende Option.

Für eine erfolgreiche Entwicklung sind einige Artefakte sehr wichtig:

• Es ist ein bewährtes Verfahren, mit Visionen oder Zielen zu beginnen.
• Es ist ein bewährtes Verfahren, die wichtigsten Stakeholder immer zu identifizieren und zu kennen.
• Es ist ein bewährtes Verfahren, den Umfang explizit festzulegen und ihn vom Kontext abzugrenzen.

Auch wenn im nicht-agilen und im agilen RE unterschiedliche Begriffe verwendet werden, stimmt man in beiden Richtungen darin überein, dass ein Verständnis der Funktionalitäten ebenso wie der Geschäftsbegriffe notwendig ist, um funktionale Anforderungen zu erfassen.

Zudem sollten agile und nicht-agile Methoden Qualitätsanforderungen und Randbedingungen aufzeigen, da sie Designentscheidungen stark beeinflussen und viel Überarbeitungsaufwand resp. ein Produkt zur Folge haben, das den Erwartungen des Kunden nicht entspricht.

Um sicherzustellen, dass keinerlei relevante Aspekte vergessen gehen, werden bei nicht-agilen Methoden Systemanforderungen dokumentiert. In agilen Ansätzen wird die fehlende Dokumentation durch direkte Kommunikation ersetzt und rasche Feedbackschleifen werden durch   inkrementelle Produktentwicklung oder Prototypen ermöglicht (=zweites Prinzip des agilen Manifests).

In der agilen Welt wird empfohlen zu überlegen, was schriftlich erfasst werden muss, was besprochen und was in Form von Prototypen oder Inkrementen gezeigt werden kann. Die besten Ergebnisse werden erzielt, wenn Dokumentation, Kommunikation und Prototyping/inkrementelle Entwicklung gemäss den Randbedingungen und der Unternehmenskultur in einem ausgewogenen Verhältnis zueinander stehen.

Viele Stakeholder wollen keine Dokumente schreiben oder lesen, sie wollen sofortige Erfolge sehen. Die beste Möglichkeit, um die Stakeholder Bedürfnisse zu verstehen und Feedback zu erhalten, ist die Demonstration von Systemfunktionalitäten oder -Merkmalen in Form eines laufenden Systems. Dies kann durch minimale, inkrementelle Produkte erreicht werden. Im RE gibt es dafür zwei Arten:

• „Horizontale" Produktinkremente, durch die sich mehr Varianten für die Validierung präsentieren lassen („mehr von den richtigen Dingen tun")
• „Vertikale" Produktinkremente, mit denen geprüft werden kann, ob der Entwicklungsansatz richtig ist („das Richtige tun").

Durch Prototypen kann Feedback gefördert werden, da sie eine direkte Interaktion mit einem funktionierenden System ermöglichen. Merkmale der Benutzbarkeit, etwa die Reaktionszeit, sind sehr schwer zu spezifizieren, aber ganz leicht zu identifizieren, wenn man funktionierende Software nutzt. Prototypen können jedoch auch eine Frustrationsquelle darstellen - für Benutzer, wenn sie glauben, dass die Entwicklung bereits abgeschlossen ist, und für Entwickler, da sie häufig verworfen und später durch eine bessere Technologie ersetzt werden.

Bei agilen Methoden werden keine Prototypen, sondern Inkremente des „realen" Systems mit einer guten Qualität entwickelt und in kurzen Iterationen ausgeliefert. Basierend auf dem Benutzerfeedback kann durch Refactoring der entwickelte Code angepasst werden. Dies ist ein bewährtes agiles Verfahren, um auf sich ändernde funktionale oder Qualitätsanforderungen zu reagieren.

Im agilen Entwicklungsprozess wird der Begriff „Spike" für eine Entwicklungsiteration verwendet, die den expliziten Zweck hat, einen Komplexitätsbereich (z. B. die Systemarchitektur) zu verstehen und so das Risiko zu verringern. Das Prototyping ist eine valide Technik innerhalb von Spikes, bei der - anders als bei anderen agilen Iterationen - das primäre Ziel im Sammeln von Wissen besteht, und nicht im Entwickeln von funktionierendem Code.

Unter Akzeptanz- und Abnahmekriterien werden folgende zusammengefasst:

• Geschäftsanforderungen
• Artefakte
• „Definition of Ready" (DoR)
• „Definition of Done" (DoD)

Sie stellen die Qualität von Anforderungen und Produktinkrementen sicher.

„Definition of Done" (DoD) ist ein offizielles Scrum Artefakt und dient als Quality Gate für den agilen Entwicklungsprozess, während die „Definition of Ready" (DoR) ein bewährtes Verfahren ist, das die Erstellung nützlicher Anforderungen unterstützt und verhindern soll, dass das Team mit unqualifizierten Anforderungen überladen wird.

Die DoR ist hilfreich, um die Anforderungen im richtigen Detaillierungsgrad zu erstellen und ausreichend Informationen für die Abstimmung zwischen Product Owner/Requirements Engineer und dem Entwicklungsteam bereitzustellen.

Alle Arten von Anforderungen müssen validiert, geprüft oder getestet werden können. Deshalb müssen für alle Anforderungen eine Reihe von testbaren Kriterien vorhanden sein. Solche Kriterien erleichtern in der Regel zusätzlich das Verständnis, indem sie konkret die Erwartungen beschreiben.

Die Art der verwendeten Kriterien sollte der Granularitätsstufe der Anforderung entsprechen:

• Auf höheren Abstraktionsebenen (Vision, Ziele, Funktionen und Epics) werden gewöhnlich Erfolgskriterien definiert (es ist «messbar» ob eine benötigte Funktionalität/Fähigkeit bereitgestellt wird oder nicht).
• Auf niedrigeren Abstraktionsebenen können Akzeptanzkriterien definiert werden, die bei der Anforderungsabnahme erfüllt sein müssen.

Bei agilen und Nicht-agilen Methoden müssen Anforderungen prüfbar sein. Bei Nicht-agilen Methoden werden häufig Begriffe wie „Qualitätskriterien", „Abnahmekriterien" oder „Testfälle" verwendet; in agilen Prozessen trifft man häufiger auf Begriffe wie „Akzeptanzkriterien" (für User-Storys) oder „Erfolgskriterien" (für Epics oder Themen).

Qualitätsanforderungen und Randbedingungen werden unter dem Sammelbegriff „nicht-funktionale Anforderungen" zusammengefasst.

• Qualitätsanforderungen:
  • Qualitätsanforderungen beziehen sich auf bestimmte Qualitäten, die ein System aufweisen muss (z.B. Performance, Sicherheit, Benutzbarkeit).
  • Da beim agilen Entwicklungsprozess der Fokus auf funktionalen Kundenanforderungen liegt, besteht die Gefahr, dass Qualitätsanforderungen nicht explizit festgehalten werden.
  • Qualitätsanforderungen können nicht als User-Storys definiert werden, die innerhalb eines Sprints entwickelt werden können: Sie beschreiben vielmehr ein aus dem entwickelten Produkt entstehendes Attribut und müssen daher für alle User-Storys kontinuierlich getestet werden.
  • Es ist schwierig, durch Refactoring Qualitätsanforderungen in vorhandene Systeme zu integrieren. Daher ist es essentiell, Qualitätsanforderungen frühzeitig im Prozess zu berücksichtigen.

• Randbedingungen:
  • Randbedingungen schränken die Umsetzungsvarianten ein
  • Es gibt folgende Formen von Randbedingungen: organisatorische Randbedingungen (Budgetbegrenzungen, ein vorgegebener Entwicklungsprozess, usw.), technische Randbedingungen (erforderliche Systeme, Programmiersprachen, usw.) oder Einschränkungen der Umgebung (Regulatorien, Standards, Nomen, usw.)
  • Viele Randbedingungen können nicht inkrementell hinzugefügt werden und müssen daher schon früh im Prozess resp. bei Planungs- und Designentscheidungen berücksichtigt werden.

Ähnlich wie funktionale Anforderungen, treten Qualitätsanforderungen und Randbedingungen auf verschiedenen Abstraktionsebenen auf und sollten im Product Backlog dokumentiert, dem Team zugänglich gemacht und in jedem Sprint getestet werden. Daher kann es nützlich sein, diese zur Definition of Done hinzuzufügen und deren Validierung in Form von automatisierten Regressionstests zu implementieren.

Funktionale Anforderungen sind ohne ein klares Verständnis der verwendeten Begriffe unvollständig. Aus diesem Grund müssen alle relevanten betriebswirtschaftlichen Begriffe, die in einem Anforderungsartefakt verwendet werden, definiert werden. Die Mindestform ist eine Liste von Geschäftsbegriffen und Abkürzungen in alphabetischer Reihenfolge (= Glossar).

Bei sehr komplexen Geschäftsfeld, kann das Glossar z.B. in Klassen gruppiert oder grafisch Darstellung werden (= Informationsmodell). Solche Artefakte werden dann als Datenmodelle, Entity-Relationship-Diagramme oder UML-Klassendiagramme bezeichnet. Neben der Begriffsdefinition enthalten diese Modelle auch relevante Assoziationen zwischen den Entitäten, d. h. statische Beziehungen zwischen den Begriffen (= Mehrwert eines Informationsmodelles).

Auf der Definitionen von Geschäftsbegriffen basiert auch bei agilen Ansätzen das gemeinsames und abgestimmtes Verständnis der in Artefakten wie Epics und User-Storys verwendeten Begriffe.

Funktionale Anforderungen können in folgenden Spezifikationsnotationen erfasst werden:

Textuelle Spezifikationsformate

• Textuelle Anforderungen werden zwar von vielen Stakeholdern leichter verstanden, sie können aber auch von denselben Lesern leicht fehlinterpretiert werden.
• Die natürliche Sprache ist nicht so präzise und eindeutig

Vorlagenorientierte Spezifikationsformate

• Verringert Mehrdeutigkeit und stellt wechselseitige Abhängigkeiten dar (u.A. zwischen Daten und Prozessen)
• Beispiele: UML-Aktivitätsdiagramme, BPMN-Diagramme, Flussdiagramme, Zustandsdiagramme, Sequenzdiagramme usw.

Grafische Spezifikationsformate

• Grafische Modelle weisen ein höheres Maß an Formalität auf, wodurch unterschiedliche Interpretationen oder Missverständnisse vermieden werden.
• Je nach Perspektive/Aspekt eigenen sich unterschiedliche grafische Notationen
• Aktivitätsdiagramme oder BPMN-Diagramme = lineare Prozesse, die aufeinanderfolgende Schritte, Alternativen oder Wiederholungen aufweisen.
• Zustandsdiagramme = Zeigt auf, wie ein Ablauf durch asynchrone Ereignisse beeinflusst werden könnte.
• Sequenzdiagramme = „Spezifikationen nach Beispiel" (Szenarios ohne einen Anspruch auf Vollständigkeit)

Mit welcher Spezifikationsform ein gemeinsames Verständnis bei allen Stakeholdern sichergestellt und Unvollständigkeiten/Missverständnisse reduziert werden kann, hängt von den definierten RE Ziele ab. Je nachdem auf welche Wechselbeziehung fokussiert werden sollte (Modellierung von Prozessen und Daten, Daten und Interaktionen oder Prozessen und Schnittstellen) kristallisiert sich das anzuwendende Spezifikationsformat heraus.

Stakeholder kommunizieren ihre Bedürfnisse in unterschiedlichen Granularitätsstufen: von groben Anforderungen (z.B. Geschäftszielen), bis hin zu detaillierteren Systemanforderungen. Funktionale und Qualitätsanforderungen sollten daher auf unterschiedlichen Abstraktionsebenen besprochen und dokumentiert werden.

Bei nicht-agilen Methoden werden in einem Top-down- oder Bottom-up-Prozess die Visionen und Ziele (1. Ebene) in Use Cases (Anwendungsfälle) verfeinert (2. Ebene) und anschliessend gruppiert. Diese Unterteilung kann aufgrund der Systemfunktionalitäten, nach betriebswirtschaftlichen Objekten, Datenflüssen oder Komponenten bestehender Lösungen erfolgen. Auf der nächsten Granularitätsstufe wird für jeden Use Case die für die Fertigstellung der Funktion benötigten Schritte beschreiben (3. Ebene). Je nach Komplexität sind kann diese Beschreibung erfolgen in:

1. Verbale Beschreibung (reiner Text)
2. Anwendungsfallvorlagen (teilweise strukturiertes Format)
3. UML-Aktivitätsdiagramm, Datenflussdiagramm, BPMN, Kontextdiagramm, Zustandsdiagramm, usw.
    

Bei sehr komplexen Problemen können weitere Granularitätsstufen hinzukommen. Z.B. Zerlegung von Aktivitäten in Teilaktivitäten oder durch textuelle Anforderungsspezifikationen einzelner Aktivitäten. Auf diese Weise werden grobe Kundenanforderungen schrittweise in detailliertere Spezifikationen der erwarteten Lösungsfunktionalität verfeinert.

Bei agilen Methoden werden für die folgenden Granularitätsstufen verwendet:

1. Epics
2. Themes
3. Features
4. User-Storys

Übergeordnete Geschäftsziele (1. Ebene) und komplexe Funktionalitäten werden in Form von Epics oder Features (2. Ebene) erfasst und nach Themen gruppiert. Komplexe Themen werden in detailliertere User-Storys zerlegt (3. Ebene).

Ob ein Projekt dem Top-down-Prozess der Verfeinerung von Epics in Features und dann in User-Storys folgt, oder ob zuerst einzelne User-Storys mit allgemeinen Themen und Epics erfasst werden, die dann in einem Bottom-up-Prozess bearbeitet werden, hängt von Art des Projekts und den beteiligten Stakeholdern ab. In jedem Fall bieten agile Entwicklungsprozesse Artefakte, um das Gesamtbild und die entwicklungsbereiten Anforderungen zu besprechen und zu priorisieren.

Anforderungen müssen auf der Basis der Vision und der Ziele erfasst werden; sie sind durch das Kontextmodell begrenzt. Typischerweise unterscheidet man zwischen drei Arten von Anforderungen:

• funktionale Anforderungen
• Qualitätsanforderungen
• Randbedingungen

Kontextmodelle bieten folgenden Mehrwert im RE:

• Kontextmodelle haben zum Ziel bestimmte Eigenschaften der Umgebung (des Kontextes), in dem das System funktionieren sollte, zu beschreiben.
• In einem Kontextmodelle werden relevante Annahmen in strukturierter Weise dokumentiert. Dies bietet den Vorteil eine gemeinsame Sicht der operativen Systemumgebung für das Entwicklungsteam/Stakeholder zu etablieren, mit der alle einverstanden sind.
• Kontextmodelle sind leistungsstarke Artefakte, da sie klar zwischen dem zu entwickelnden System und dessen Kontext (z.B. Nachbarsystemen und menschlichen Benutzern) unterscheiden. Dadurch kann zwischen den Verantwortlichkeiten des Systems und den Verantwortlichkeiten von Nachbarsystemen oder menschlichen Benutzern unterschieden werden, die bei einem Vorgang zusammenarbeiten. Daher eignen sich Kontextmodelle auch zur Klärung und Spezifizierung der externen Schnittstellen des zu entwickelnden Systems.
• Ein Kontextmodell ist ein nützliches Artefakt, das in einem agilen Entwicklungsprozess zu empfehlen ist. Es grenzt den Bereich/Umfangs ab, in dem Analysten freie Entscheidungen treffen können, während die externen Schnittstellen (d. h. die Grenze zwischen Umfang und Kontext) mit den Nachbarsystemen abgestimmt werden müssen.
• Für Kontextmodelle sind alle Notationen geeignet, welche eindeutig zwischen dem zu entwickelnden System und externen Schnittstellen oder Personen/Systemen in der Umgebung differenzieren. Zudem muss die Beziehung zwischen diesen Elementen und dem zu entwickelnden System in einem angemessenen Detaillierungsgrad dokumentiert sein.
• Beispiel von Kontextmodellen: Kontextdiagramme für strukturierte Systemanalysen, Grafiken für Anwendungsfälle, UML-Komponentengrafiken oder UML-Klassendiagramme. Selbst einfache, von Hand gezeichnete Kastengrafikdiagramme können pragmatisch und nützlich sein.

Herkömmlichen Spezifikationsdokumenten und Backlogs unterscheiden sich in folgenden Punkten:

Im Requirements Engineering werden Anforderungen als Artefakte oder als Ergebnis des Ermittlungsprozesses (z.B. Benutzeranforderungsspezifikation oder Systemanforderungsspezifikation) bezeichnet, abhängig vom Autor und Detaillierungsgrad. Die Anforderungssammlung ist nicht notwendigerweise dokumentenbasiert, sondern einfach eine Sammlung von Anforderungen in jeglicher physischen Form (Papier, Repository-basiert, usw.).

Bei agilen Methoden wird der Begriff Product Backlog als zu implementierende Anforderungssammlung verwendet. Der Begriff Sprint Backlog wird für Anforderungen verwendet, die für die nächste Iteration/Sprint ausgewählt wurden. Auch hier ist die physische Erscheinungsform der Backlogs nicht relevant. Sie können aus Karteikarten oder Haftnotizen an einer Wand bestehen. Das Product Backlog muss angemessen detailliert, geschätzt, emergent und priorisiert wird. Für den Product Owner als Wertoptimierer ist die Priorisierung des Produkts das Wertvollste und Wichtigste.

Auch wenn die Bezeichnungen und die Behandlung unterschiedlich sind, beruhen alle Artefakte auf denselben Ideen und bieten eine Basis für die Ermittlung, die Dokumentation, die Abstimmung, die Validierung und das Management von Anforderungen. Die folgenden Elemente müssen unabhängig von der Dokumentationsform erfasst werden:

• Ziele und Visionen
• die Definition des Umfangs eines Systems
• funktionale Anforderungen
• Qualitätsanforderungen und Randbedingungen
• ein Glossar (d. h. Definitionen relevanter Begriffe und Abkürzungen).

Die Ansätze für Anforderungsspezifikaionen können in Notationen, in der Syntax und im Detaillierungsgrad variieren. Gar keine Spezifikation zu erstellen (d. h. ohne schriftlich erfasste Anforderungen, ausschließlich auf verbale Kommunikation zwischen Stakeholdern zu setzen), bildet keine Alternative, da schriftliche Dokumente häufig als Basis für Abstimmungen und Akzeptanztests sowie zur rechtlichen Absicherung dienen.

Je mehr alle Stakeholder miteinander kommunizieren, umso weniger Schreibarbeit ist erforderlich, doch die Ergebnisse = Anforderungen, sollten schriftlich oder grafisch erfasst werden.