IREB RE@Agile Primer

An ➔iteration in ➔Agile development, particularly when using ➔Scrum.

A set of ➔Product Backlog items that is selected to be implemented in the current ➔sprint.

➔ User story 

A two-dimensional arrangement of ➔user stories. Helps to understand the functionality of the ➔product, identify gaps and plan ➔releases.

An analysis approach to prioritize work. It refers to the picture of the letter T: The horizontal line suggests to analyze a topic in full breath first, while the vertical line suggests to dig deeper into selected parts.

An agile technique for relative estimation of backlog items

A coherent set of actions or procedures for accomplishing a task or achieving an objective.

A collection of related ➔user stories

A fixed, non-extendable amount of time for completing a set of tasks

Characterizes work or activities to be performed at the beginning of a development project, before ➔Agile development can start. 

A description of a need from a user’s perspective together with the expected benefit when this need is satisfied.

User stories are typically written in natural language using a given phrase template. In ➔Agile development, user stories are the main means for communicating needs between a ➔Product Owner and the ➔development team.

The development capacity of a team in terms of the average amount of work that the team can complete in an iteration.

Minimum Viable Product (MVP) aus Lean Startup: Validiertes Lernen über den Kunden bei geringstem Aufwand.

Der Zweck eines Minimum Marketable Products (MMP) ist es, sofort Wert zu schaffen. Viele Produkte können bereits in einer einfachen „Version 1" genutzt werden, ohne dass diese Version alle gewünschten Funktionalitäten und Qualitäten umfasst; so erzielt das Produkt bereits Umsatz, mit dem die kontinuierliche Verbesserung (das sog. Continuous Improvement) des Produkts finanziert werden kann. 

• Basiert auf Lean Startup von Ries
• Verwandt mit Design Thinking, aber mit Fokus auf Entwicklung von Geschäftsideen, insbesondere mit schnellem und häufigem Feedback
• Der Produktentwicklungsansatz wird als „Build - Measure - Learn" (bauen, messen, lernen) bezeichnet, und der Schwerpunkt liegt dabei vor allem auf dem kontinuierlichen Lernen über die Bedürfnisse des Kunden. Mit Minimum Viable Product (MVP) ist sinngemäß eine Version eines neuen Produkts gemeint, die einem Team das Erfassen des maximal möglichen sogenannten validierten Lernens über Kunden bei geringstem Aufwand ermöglicht 

Product Backlog Einträge haben folgende Eigenschaften/ Qualitätsmerkmale:

I: „Independent of each other" - unabhängig voneinander

N: „Negotiable" - verhandelbar

V: „Valuable" - wertvoll, nützlich

E: „Estimable" - schätzbar

S: „Small enough to fit into one sprint" - klein genug für einen Sprint

T: „Testable" - testbar 

Ein Backlog muss “DEEP” sein:

Detailed appropriately,

Estimated,

Emergent,

Prioritized

d. h. angemessen detailliert, geschätzt, dynamisch, priorisiert

Eine Haltung und eine Toolbox entlang fünf Phasen, um die Bedürfnisse und Probleme der Kunden besser zu verstehen:

1. Hineinversetzen („Empathize"): In dieser Phase versetzt sich das Team in die Menschen, die das Problem haben, um ein Verständnis dafür zu entwickeln und das Problem zu lösen.
2. Definieren („Define"): In dieser Phase formuliert das Team das Problem neu, um ein gemeinsames Verständnis der Details des zu lösenden Problems zu erhalten.
3. Ideen finden („Ideate"): In dieser Phase konzentriert sich das Team auf die Generierung von Ideen. Das Ziel besteht hier nicht darin, die Idee zu entwickeln. Stattdessen entwickelt das Team so viele Ideen wie möglich. Am Ende dieser Phase wählt das Team die aussichtsreichsten Ideen für das Prototyping aus.
4. Prototypen entwickeln („Prototype"): In dieser Phase erstellt das Team sehr einfache Prototypen (nicht notwendigerweise Software!) aus den entwickelten Ideen. Das zugrundeliegende Prinzip ist, dass der Prototyp so realistisch und kostengünstig wie möglich sein soll.
5. Testen („Test"): In dieser Phase testet das Team den Prototyp mit realen Kunden, um Feedback zu deren Ideen einzuholen. Ein Hauptprinzip für diese Testphase ist „zeigen nicht darüber sprechen", d. h. der Prototyp sollte für sich selbst sprechen können, damit der Benutzer echtes Feedback abgeben kann. 

• Inspect: Feedback möglichst früh und schnell (z.B. Review)
• Adapt: Erkenntnisse sofort in den Prozess integrieren (Backlog Refinement, Sprint Planning, Massnahmen aus der Retrospektive) 

• Crystal ist eine Reihe von Methoden, die von Alistair Cockburn entwickelt wurden, die auf Projektgrösse und -komplexität angepasst werden können Crystal Clear kommt
• XP (Extreme Programming) am nächsten Lean Development stammt aus der Automobilindustrie (Kanban u.a.) mit dem Ziel, Verschwendungen im Prozess zu minimieren
• Scrum ist beinahe der Klassiker
• TDD (Test Driven Development) bedeutet, dass man zunächst den Testfall spezifiziert und somit bereits einen “Negativtest” hat
• XP (eXtreme Programming) ist der Vorgänger von Scrum und basierter auf direkter Kommunikation zwischen Entwickler und Kunde und vielen, heute gängige Prinzipien wie collective code ownership 

• Beste Möglichkeit, um Stakeholder-Bedürfnisse zu verstehen, ist die Demonstration am “echten” System mittels minimalsten Produktinkrementen
• Horizontale Produktinkremente: mehr Varianten für die Validierung (“mehr von den richtigen Dingen tun")
• Vertikale Produktinkremente: prüfen, ob der Entwicklungsansatz richtig ist (“das Richtige tun")
• Demgegenüber ist der “Spike”
• „Spike" wird in agilen Entwicklungsprozessen 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.
• Es wird nicht zwingend ein produktives Produktinkrement geschaffen 

Requirement Engineering (RE) ist gemäss IREB Definition: 

Ein systematischer und disziplinierter Ansatz für die Spezifikation und das Management von Anforderungen mit den folgenden Zielen:

• Verstehen und Dokumentieren der Wünsche und Bedürfnisse der Stakeholder
• Kennen der relevanten Anforderungen, Erreichen eines Konsenses der Stakeholder über diese Anforderungen, das Dokumentieren der Anforderungen nach vorgegebenen Standards und das systematische Managen der Anforderungen
• Spezifizieren und Managen von Anforderungen, um das Risiko der Auslieferung eines Systems zu minimieren, das nicht den Wünschen und Bedürfnissen der Stakeholder entspricht. 

• Im RE wird der Begriff "System" bevorzugt, da er die Tatsache betont, dass ein System eine Gruppe von Bestandteilen oder Elementen ist, die zusammen in einer Umgebung funktionieren. Die Umgebung bezeichnet man im RE als Systemkontext
• Die 4 Hauptaktivitäten des RE sind: Ermitteln, Dokumentation, Prüfen, Validierung/Abstimmung und Verwaltung von Anforderungen
• Ein zentraler Wert des IREB ist, dass das RE ein prozessunabhängiger Ansatz ist (= ein grosser Wissensfundus an Methoden und Techniken)
• IREB ist der Überzeugung, dass beide Ansätze (agil und nicht-agil) ihren Wert haben.

In der agilen Entwicklung // Manifest

• Einzelpersonen und Interaktion vor Prozesse/Werkzeuge
• Funktionierende Software vor umfassender Dokumentation
• Zusammenarbeit mit Kunden vor Vertragsverhandlung
• Reagieren auf Veränderungen vor Plan befolgen

Agile Prinzipien:

1. Zufriedenstellung des Kunden durch frühzeitige und kontinuierliche Auslieferung
2. Veränderte Anforderungen auch noch in späten Entwicklungsphasen
3. Funktionierende Software regelmässig innert weniger Wochen ausliefern
4. Stakeholder/Entwickler arbeiten täglich zusammen
5. Projekte mit motivierten Einzelpersonen
6. Persönliches Gespräch als effizienteste/effektivste Methode für Informationsvermittlung im Team
7. Funktionierende Software als primäres Mass für Fortschritt
8. Agile Prozesse fördern kontinuierliche Entwicklungen
9. Stetiges Augenmerk auf technischer Excellenz und gutes Design
10. Einfachheit ist wesentlich
11. Beste Architekturen, Anforderungen, Designs aus sich selbst organisierenden Teams
12. In regemässigen Abständen Nachdenken um effizienter zu werden.

Differenzierung nach "Prinzipien", "Verfahren" und "Aktivitäten" auf den drei Abstraktionsebenen:

• Ein Prinzip ist eine präskriptive Aussage, die abstrakt und falsifizierbar ist.
• Ein Verfahren/eine Technik ist eine Instanziierung eines Prinzips in einem bestimmten Kontext.
• Eine Aktivität ist eine reale oder geplante Ausführung eines Verfahren

Die wichtigen Begriffe zur Differenzierung der drei Definitionen sind präskriptiv, abstrakt und falsifizierbar. Präskriptiv bedeutet, dass die Aussage eine Aktion steuert, anstatt eine Tatsache oder eine Eigenschaft darzulegen. Ein Prinzip unterscheidet sich von einem Verfahren durch Abstraktheit. Ein Beispiel: „Eine Softwarefunktion vor der Auslieferung testen" ist präskriptiv, wohingegen „einen Unit-Test für jedes Softwarefeature erstellen" ein Verfahren basierend auf dem vorgegebenen Prinzip ist. Eine Aktivität zu diesem Beispiel wäre die Erstellung eines UnitTests für die Suchfunktion eines Bibliotheksystems. Falsifizierbarkeit bedeutet, dass eine Person mit hinreichendem Hintergrundwissen eine andere Meinung zu einem Prinzip haben kann. Das oben angeführte Prinzip („Eine Softwarefunktion...testen") erfüllt dieses Kriterium. 

• Das RE beschäftigt sich mit der systematischen Ermittlung und Dokumentation von Anforderungen als eigenständigen Artefakten, während bei agilen Entwicklungsprozessen die funktionierende Software im Vordergrund steht und nicht eine umfassende Dokumentation; auch werden Personen und Kommunikation höher bewertet als Prozesse und Werkzeuge.
• Ein wichtiger Unterschied zwischen der Anwendung von RE in agilen Entwicklungsprozessen und anderen Entwicklungsmethoden ist die zeitliche Abstimmung und der angewandte Prozess. 
• Das Manifest für agile Softwareentwicklung hebt den Wert eines Inkrements funktionierender Software (oder eines funktionierenden Produkts) gegenüber einer umfassenden Dokumentation hervor.

• Das Ziel der Auslieferung von Software auf ein klar definiertem Qualitätsniveau
• Dank agiler Methode kann funktionierende Software effizient und schneller ausgeliefert werden (geringere Zykluslaufzeit)
• Da RE stellt geeignete Technikgen bereit, mit deren Hilfe ein Verständnis der Wünsche und Anforderungen von Stakeholdern erlangt und die Software mit dem grössten Gewinn (Zuwachs an Business-Wert oder Liderung akuter Probleme) entwickelt werden kann. 
• RE vereinfacht:

1. Bedürfnisserkennung und Verständnis der Stakeholder für die Softwareentwicklung
2. Marktveränderungen erkennen und für Stakeholder Wettbewerbsvorteile generieren
3. Förderung effizienter Stakeholder Zusammenarbeit durch passende Techniken und Werkzeuge
4. Unterstützung verbaler Kommunikation durch passsende Techniken und Werkezuge
5. Das Verständnis um Stakeholder Anforderungen auf das Minimum reduzieren zu können. 

Das Manifest für agile Softwareentwicklung hebt den Wert eines Inkrements funktionierender Software (oder eines funktionierenden Produkts) gegenüber einer umfassenden Dokumentation hervor. Eine übertriebene Interpretation hatte den falschen Eindruck zur Folge, dass agile Methoden gänzlich auf Dokumentation verzichten. Diese Interpretation ist falsch: Zweckmäßige Dokumentation ist in agilen Entwicklungsprozessen nach wie vor erwünscht und zu empfehlen, allerdings nur dann, wenn sie die Entwicklung unterstützt oder Bestandteil des Produkts ist. In der Vergangenheit wurde es als Problem empfunden, dass in vielen Projekten Dokumentation ohne klar definierten Zweck oder Mehrwert erstellt wurde - diese Art von Dokumentation ist nach den agilen Prinzipien zu vermeiden. 

• RE und Entwicklungskompetenzen im selben Team können den Aufwand für Übergaben verringern
• Wenn RE_ Aufgaben im Team ausgeführt werden, kann das den Bedarf an vorab erstellter, umfassender Anforderungsdokumentation verringern (direkte Klärung innerhalb des Teams)
• Dokumentation von Ergebnissen aus den geführten Gesprächen und die Bewahrung von Wissen
• Inkrementelle Entwicklung ermöglicht die Optimierung vorhandener Ideen (die Qualität der Artefakte und/oder Software wird kontinuierlich verbessert)
• Das Risiko das zwischen den Kundenerwartungen und der Entwicklung grosse Lücken entstehen wird minimiert
• Kontinuierliche Verfeinerung ist ein Prinzip zur Ausreifung und Validierung. In regelmässigen Verfeinerungsmeetings wird mit dem Entwicklungsteam und den Stakeholdern die Anforderungen wiederkehrend durchgesehen und detailliert
• Durch das Verfahren der "Definition of Ready" Als "Quality Gate" wird validiert, dass eine Anforderung einer nachfolgenden Iteration zur Implementierung bereit ist
• Das RE vereinfacht das definieren eines ersten «Product Backlogs». Das RE bietet verschiedene Techniken, um die Stakeholder Anforderungen für das gewünschte Produkt richtig zu verstehen.

Das RE ist lediglich eine vorab erstellte Analyse. Missverständnis, da RE als Disziplin prozessunabhängig ist und nicht zwingend eine umfassende Vorarbeit erfordert. RE kann in jede Iteration integrierte Aktivität darstellen.

Vorab ist schlecht. Missverständnis, da die Vorbereitung auf eine iterative Entwicklung ein wesentlicher Bestandteil jedes nicht alltäglichen Entwicklungsprojekts ist. Agile Verfahren, die den Wert von Überlegungen im Vorfeld berücksichtigen, sind Story Mapping, Prototyping und das sog. Test Driven Development (TDD).

RE ist gleich Dokumentation. Missverständnis, da Dokumente bei z.B. der Einhaltung rechtlicher Vorgaben (Compliance), Bewahrung nützlicher Informationen, Vereinfachung der Kommunikation und bei gedanklichen Vorgängen unterstützen.

User-Storys sind ausreichend. Missverständnis, da User-Storys eine Methode für die Erfassung der Stakeholder Bedürfnisse sind. Sie zielen jedoch darauf ab, die Kommunikation in Gang zu setzen und stellen nicht die vollständige Spezifikation dar. Ein weit umfassenderes Bild von Anforderungen lässt sich durch eine Kombination von User-Storys mit anderen anerkannten RE Techniken wie Kontextdiagrammen, Prototyping, Anwendungsfällen und User Journeys erreichen.

Dokumentation ist wertlos, nur Code ist von bleibendem Wert. Missverständnis, da die Anforderungsdokumentation ebenso wie die Design-, Test- oder Betriebsdokumentation in bestimmten Kontexten ihre Daseinsberechtigung hat. Die Dokumente sind alle gleichermassen gültige und notwendige Artefakte, die aus dem Entwicklungsprozess für jedes nachhaltige Softwareprodukt entstehen.

Funktionierende Software ist der einzige Weg zur Validierung von Anforderungen: Missverständnis, Software ist als Mittel zur Validierung von Anforderungen zu bevorzugen, wenn die mit einem solchen Validierungsansatz verbundenen Kosten und Risiken verglichen mit dem Ergebnis akzeptabel sind. Sind die Kosten und/oder Risiken hoch, stellt RE verschiedene Tools zur Verfügung, die ein schnelles Feedback und eine rasche Anforderungsvalidierung ermöglichen, bevor auch nur eine einzige Zeile Code geschrieben wurde, beispielsweise Modelle für Benutzeroberflächen oder Story Boards

Agile und kulturelle Veränderungen sind unvereinbar. Agile Werte verändern die Unternehmenskultur (erfordert Zeit und qualifizierte Mitarbeiter)

Anforderungen als einheitliche Art von Informationen behandeln. Der benötigte Detailierungsgrad und unterschiedlichen Abstraktionsebene pro Anforderungen muss berücksichtigt werden. Z.B. Vision = hohe Abstraktionsebene und lange Gültigkeitsdauer.  Andere Anforderungen sind schnelllebiger – es müssen nicht alle Anforderungen einheitlich spezifiziert werden.

Den Zusammenhang aus den Augen verlieren. Bei agilen Methoden wird der Fokus nur auf Themen gelegt, die unmittelbar umgesetzt werden. Dadurch gerät der Gesamtzusammenhang aus dem Blickfeld. Lang- und mittelfristige Perspektiven schaffen (z. B. Verfeinerungs-Meetings).

Es wird sofort in Lösungen gedacht und spezifiziert. Noch bevor das Problem analysiert und der Nutzen/Bedarf des Stakeholders festgestellt wurde.

Stakeholder mit Informationen überladen. RE-Artefakte weisen eine hohe Informationsdichte auf, die einen grossen Review-Aufwand für Stakeholder darstellt.

Inkrementelle und iterative Ausarbeitung aller Themen. Nicht jedes Anforderungsthema muss detailliert und inkrementell entwickelt werden. Inkrementelle Entwicklungen eignen sich für komplexe Themen (z.B. Einkaufsprozess Onlineshop). Hochkomplexe Themen sind für inkrementelle Entwicklung nicht geeignet, da jede neue Erkenntnis zu einem völlig neuen Verständnis der bereits bekannten Informationen führt (z.B. Berechnungen von Versicherungspolicen).

Inkrementelle Entwicklung unterstützt möglicherweise keine radikalen oder bahnbrechenden Innovationen. Agile Entwicklungen mit inkrementellen Prozessen führen zu kontinuierlichen Innovationen. Radikale Innovationen entstehen, wenn unterschiedliche Ideen berücksichtigt und vorhandene Ideen neu kombiniert werden. Gemäss dem Prinzip «10. Prinzip - Maximieren nicht getaner Arbeit» werden keine alternativen Ideen in agilen Umgebungen entwickelt. Radikale Innovationen benötigt z.B. Lean-Startup-Ideen oder Design-Thinking-Ansätze.

Agilität beinhaltet mehr als Scrum. Besonders geeignete Ansätze für Innovationen sind: Design Thinking, Design-Sprint und Lean Startup

Diese Techniken zeigen, dass es Ansätze für konzeptuelle Arbeit in RE@Agile gibt, welche die Denkweise agiler Methoden teilen und daher gänzlich mit agilen, Softwareentwickelnden Unternehmen kompatibel sind. Diese Herangehensweisen sollten als eine neue Form des Wasserfall-Ansatzes berücksichtigt werden.

Sie können als Frameworks von agiler Entwicklung für das Design dedizierter Aspekte eines Systems verwendet werden. Alternativ können sie als Aktivitäten genutzt werden, die der agilen Entwicklung vorangehen. So helfen diese Ansätze, das begrenzte Potenzial für Innovationen in agilen Entwicklungsprozessen zu überwinden. 

3 Ansätze für Agilität in konzeptueller Arbeit (Kombinationen aus RE Ermittlungs- und Validierungstechniken).

Design Thinking  

• ein multidisziplinäres Team, das an dem Problem arbeitet; dieses Team bringt ein breit gefächertes Wissen mit, das für die Problemlösung benötigt wird;
• eine Arbeitsumgebung, in der das Team an Ideen arbeiten kann; und
• ein iterativer Prozess, der sich aus folgenden Phasen zusammensetzt: Hineinversetzen („Empathize") / Definieren („Define") / Ideen finden („Ideate as many as possible and choose one» / Prototypen entwickeln („Prototype") / Testen („Test")

Die Phasen des Design Thinking sind skalierbar und im Ablauf. Diese Methode entspricht dem agilen Wert „das Reagieren auf Veränderungen bewerten wir höher als das Befolgen eines Plans", «multidisziplinäre Team und die Arbeitsumgebung sind zentrale Elemente des Prozesses» sind und durch die Entwicklung von kostengünstigen und schlanken Prototyps, dem agilen Prinzip der «Einfachheit».

Der Design-Sprint ist ein 5-tägiger Entwicklungsworkshop mit Endkunden. Gearbeitet wird mit klar definierten «Timeboxes»;

• Wissen des Teams freisetzen / Ideen skizzieren / entscheiden, für welche Ideen Prototypen erstellt werden sollen / die ausgewählten Prototypen erstellen / die Ideen mit realen Kunden testen.
• Der entscheidende Unterschied im Vergleich zu agiler Entwicklung ist, dass der Prototyp keine Software sein muss

Lean Startup ist ein Ansatz zur Entwicklung von Geschäftsideen und zum Managen von Startups.

• Produktentwicklungsansatz „Build - Measure - Learn" führt zu kontinuierlichem Lernen über die Kundenbedürfnisse
• Mit dem Minimum Viable Product ist eine Version eines neuen Produkts gemeint, mit mimalem Aufwand das maximale Kundenfeedback ermöglicht.

Bei Lean Startup wird ein Kurswechsel, d. h. „eine strukturierte Kurskorrektur, um eine neue grundlegende Hypothese über das Produkt, die Strategie und den Wachstumsmotor» aufzustellen. Anstelle einer Ermittlung und Validierung der Anforderungen basierend auf Konzepten oder Dokumenten, werden diese Methoden anhand des realen Produkts durchgeführt. Das MVP muss nicht zwingend eine voll funktionsfähige, vollständige Software sein muss.

• Bei den Crystal Methoden wird für jedes Projekt ein eigens zugeschnittenes Prozessmodell benötigt. Abhängig von Größe, Komplexität und Kritikalität werden verschiedene Rollen, Aktivitäten und Artefakte angewendet. Crystal Clear, eine Methode für kleine und weniger kritische Projekte. Crystal Orange und Crystal Red wurden um einige Formalismen erweitert, um größere Projekte abwickeln zu können. Aus Anforderungsperspektive werden mit wenig formellen Anwendungsfallmodellen und Mock-ups gearbeitet.
• Lean Development und Kanban beruhen auf Prinzipien aus den 1940erJahren. Ziel dieser Ansätze ist es, sieben Arten von Verschwendung im Produktionsprozess aufzudecken (unfertige Vorprodukte, Überproduktion, Mängel,...) und diese bis zur endgültigen Lieferung schrittweise zu beseitigen.
• Scrum ist ein Framework zum Entwickeln und Erhalten komplexer Produkte. Das Framework ist auf eine iterative, inkrementelle Entwicklung ausgerichtet. Es gibt drei Schlüsselrollen: einen Product Owner (zum Managen des Product Backlog), ein Entwicklungsteam, das diese Anforderungen in kurzen Sprints implementiert und einen Scrum Master, der den Prozess überwacht und als Vermittler zwischen den anderen Rollen fungiert.
• TDD (Test Driven Development) beruht auf der Idee, dass vor dem Codieren eines Features zunächst der entsprechende Test verfasst wird. Die Testfälle sind sowohl eine exakte, als auch eine detaillierte Spezifikation der Anforderungen, die das Produkt erfüllen soll.
• XP (eXtreme Programming) Beim XP liegt der Schwerpunkt auf der direkten Kommunikation zwischen einem Kunden und einem Programmierer (der sog. On-Site Customer, der direkt neben dem Programmierer sitzt, ständig Anforderungen bespricht und unmittelbares Feedback in Form von implementierten Features erhält).  

Scrum ist ein schlankes Framework zur Entwicklung von Produkten in komplexen Umgebungen. Es gibt 3 Rollen (Scrum Master, Product Owner und Entwicklungsteam), 4 Ereignisse (Sprint-Planung, Daily-Scrum-Meeting, Sprint Review und Sprint-Retrospektive) und Artefakte (Product Backlog, Sprint Backlog, Sprint Goal/Sprint-Ziel und Definition of Done). Scrum empfiehlt keinerlei Engineering-Verfahren.

Scrum entwickelt Produkte iterativ und inkrementell in einer Folge von Sprints (max. 1 Monat). Jeder Sprint resultiert in einem Produktinkrement: Das ist ein Teilprodukt, das Endkunden in einer Produktionsumgebung potenziell verwenden können.

Der Sprint ist ein iterativer 'Plan-Do-Check-Act' Prozess. Jeder Sprint beginnt mit der Sprint-Planung, einem Ereignis, bei dem das Scrum-Team gemeinsam definiert, was im nächsten Produktinkrement ausgeliefert und wie das erreicht werden kann (Zerlegung).

Der Plan basiert auf dem Product Backlog (eine priorisierte und dynamische Liste aller Bedarfe für das Produkt). In der Sprint-Planung wird das Sprint-Ziel und Sprint Backlog (Auswahl der Items und deren Zerlegung für den Sprint) erstellt. Anschliessend beginnt das Scrum-Team mit der Implementierung des Produktinkrements.

Das Entwicklungsteam ist für die Umsetzung der ausgewählten Items in konkrete Ergebnisse verantwortlich, arbeitet mit dem Product Owner an der Verfeinerung der Product Backlog Items zusammen und gibt sein Feedback zur aktuellen Implementierung ab.

Die Mitglieder des Entwicklungsteams bringen sich jeden Tag in den Daily-Scrum-Meetings auf denselben Stand, um den Fortschritt zu beurteilen und das Sprint Backlog zu aktualisieren.

In der „Definition of Done" wird vereinbart, welche Teile einer Anforderung vom Entwicklungsteam erfüllt werden müssen. Wenn die Sprint Timebox vorüber ist, inspiziert das Scrum-Team in einem Sprint Review das Produktinkrement, und die wichtigsten Stakeholder bewerten die Ergebnisse des Sprints und besprechen die weiteren Schritte. Das Product Backlog wird entsprechend aktualisiert.

Der Sprint endet mit der Sprint-Retrospektive, in der das Scrum-Team bespricht, wie der letzte Sprint verlaufen ist, und wie es effizienter werden kann.

Im Scrum werden keine Requirements-Engineering-Techniken eingesetzt. Trotzdem ist es für RE relevant. Denn im «Product Backlog» werden die aufgeführten Items resp. Anforderungen gebündelt.

Das Backlog sollte „DEEP" (Detailed appropriately, Estimated, Emergent, Prioritized, d. h. angemessen detailliert, geschätzt, dynamisch, priorisiert) sein.

Alternativ gilt die «INVEST»-Regel:

I: „Independent of each other" - unabhängig voneinander

N: „Negotiable" - verhandelbar

V: „Valuable" - wertvoll, nützlich

E: „Estimable" - schätzbar

S: „Small enough to fit into one sprint" - klein genug für einen Sprint

T: „Testable" - testbar

Im RE werden ähnliche Kriterien für gute Anforderungen genannt:

• abgestimmt
• Eindeutig
• Notwendig
• Konsistent
• Prüfbar
• Realisierbar
• Verfolgbar
• Vollständig
• Verständlich

Die wichtigsten Verantwortlichkeiten eines Product Owners sind:

• Sicherstellen, dass das Entwicklungsteam konstanten betriebswirtschaftlichen Wert liefert: Das bedeutet, dass der Product Owner die längerfristige Vision für das Produkt und kurzfristige Bedürfnisse ins Gleichgewicht bringen muss, und er das Product Backlog aus betriebswirtschaftlicher Sicht priorisieren und die Ergebnisse des Entwicklungsteams zusammen mit den Stakeholdern am Ende jedes Sprints prüfen muss.
• Managen aller Stakeholder: Der Product Owner ist dafür verantwortlich, konsistente Anforderungen an das Team weiterzuleiten. Er muss Anforderungen aller Stakeholder erfassen und sicherstellen, dass sich die Anforderungen nicht widersprechen. Es muss etwaige Meinungsverschiedenheiten zwischen Stakeholdern lösen, um das Entwicklungsteam davon zu entlasten.
• Kontinuierliche Versorgung des Entwicklungsteams mit den hochrangigen Einträgen aus dem Backlog: Die Granularität dieser Anforderungen muss klein genug sein, damit sie sich für einen Sprint eignet. Für alle Fragen, die nach dem Sprint-Planungsmeeting entstehen, muss der Product Owner zur zügigen Klärung zur Verfügung stehen.

Im «Product Backlog» werden die aufgeführten Items resp. Anforderungen gebündelt.

• Je nach Granularität werden die Anforderungen in «Epics», «Features» und «User-Storys» zerlegt.  
• Es wird unterschieden zwischen funktionalen Anforderungen (Fähigkeit), Qualitätsanforderungen (Verhalten) und Randbedingungen (Umgebung)
• Und nach Anforderungsthemen gruppiert.

Innerhalb des Sprints gibt es das Backlog Refinement bei dem Anforderungen besprochen und verfeinert werden.

Mit der «Definition of Done» (DoD) entwickelt das Team ein gemeinsames Verständnis davon, wann ein Product Backlog Item vollständig und bereit für die Produktionsfreigabe ist.

Vergleicht man diese beiden Rollen, so zeigt sich, dass sowohl der Requirements Engineer als auch der Product Owner (gemeinsam mit allen Stakeholdern) die zentralen Aufgaben Ermitteln, Dokumentieren, Validieren und Managen von Anforderungen durchführen muss.

Die Notationen und Werkzeuge, die dabei zum Einsatz kommen, sind in agilen Entwicklungsprozessen jedoch in der Regel weniger formell:

• Story-Cards anstelle von Anforderungsdokumenten
• mehr Gespräche und weniger Schreibarbeit
• stärkere Betonung von aktuellen Statusanforderungen, weniger Betonung auf Versionierung und Verlauf

Es ist zwar wichtig, eine Gesamtverantwortung für Anforderungen von hoher Qualität kontinuierlich aufrechtzuerhalten, dabei ist die Rolle des Product Owners breiter gefächert als die eines herkömmlichen Requirements Engineers: Ein Product Owner ist für den Erfolg des Produkts insgesamt, das fortwährende Einholen von Feedback von den Stakeholdern sowie für das entsprechende Aktualisieren und Priorisieren des Backlogs verantwortlich.