Ist der häufig in agil arbeitenden Organisationen zu hörende Satz „wir arbeiten agil und benötigen kein RE mehr“ tatsächlich zutreffend? Ist die Zeit des RE durch die Verbreitung von agilen Methoden (z.B. durch das Scrum-Framework) abgelaufen? Der Eindruck könnte auf den ersten Blick entstehen, da die Aktivitäten des Requirements Engineering in der agilen Entwicklung nicht isoliert betrachtet werden. Auf den zweiten Blick stellt sich heraus, dass Kenntnisse rund um RE-Methoden im agilen Umfeld nötiger sind denn je. Dies ergibt sich aus der Tatsache, dass immer größere Organisationen den Umstieg von ihren an Phasen und Dokumenten orientierten Prozessen zu einer agilen Entwicklung anstreben. Dies hat zur Folge, dass diese Organisationen häufig nicht individuell für genau einen Kunden implementieren, sondern zahlreiche Produkte für eine größere Kundenanzahl entwickeln. In einem agil-skalierten Umfeld. Ein kleines Beispiel: In einem Review Meeting mit mehreren anwesenden Stakeholdern erhalten die Anwesenden einen Einblick in die bisherige Produktimplementierung und ergänzen die bisherige Implementierung mit neuen Wünschen - also mit weiteren Kundenanforderungen. Diese Anforderungen können sich widersprechen und schon muss der Product Owner die Anforderungen konsolidieren – eine typische RE-Aktivität. Dieser Vortrag orientiert sich an zahlreichen dieser kleinen Beispiele, die in der alltäglichen Praxis vorkommen, und belegt dadurch die wachsende Bedeutung von RE-Kenntnissen im agil-skalierten Umfeld.

1. Andreas Becker
Agile-by-HOOD
18.03.2014
RE und Scrum –
auf den zweiten Blick ein geniales Team

2. Inhalt
• Einleitung
• Refinement
• Vision
• Planung
• Abstimmung
• Erhebung und Feedback
• Weitere Rollen
• Zusammenfassung oder muss es immer Scrum sein?

3. Klassische RE-Aktivitäten
3
Umfang definieren
(Scoping)
Erheben
Spezifizieren
VerwaltenModellieren
Konsolidieren
Konkretisieren
Ableiten
Abstimmen /
Review
Abnehmen
Stakeholder-
Management

4. Scrum: 3 – 3 – 5
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Definiton
of Done
Stand:
Scrum Guide 2013

5. In welchem Umfeld arbeiten Sie?
6
Kunde Product
Owner
ScrumMaster
Entwicklerteam
Kunde
Product
Owner
ScrumMaster
Entwicklerteam
Kunde =
Kunde
Kunde
Kunde
Kunde
Kunde
Kunde Kunde
Kunde
KundeKunde
Kunde
Kunde
Kunde Kunde
Kunde
Kunde

6. Refinement

7. Scrum - Framework
8
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Definiton
of Done
Scrum Guide 2013
User
Stor
y

8. User Story
9
Als Administrator
möchte ich Nutzer des
Portal sperren
können, um Missbrauch
zu verhindern
Rolle
Funktionalität
Nutzen / Grund
Kommunikationsgrundlage

9. Quelle: http://www.informit.com/articles/article.aspx?p=1928232&seqNum=4
Backlog Refinement

10. Scrum - Framework
11
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Definiton
of Done
Scrum Guide 2013
Story Time
User
Stor
y
„…10% der Zeit des Entwicklungsteams für die Beschäftigung mit zukünftigen Anforderungen…“

11. Akzeptanzkriterien – es müssen nicht immer Stichworte sein
12
Tabellen
Als Nutzer möchte ich mein Profil löschen können,
um keine Daten im Netz zu hinterlassen.
 Given - der Nutzer ist eingeloggt
 and er hat keine aktuellen Buchungen von
Mitfahrgelegenheiten
 When - der Löschbutton wird betätigt
 die Anfrage wird bestätigt
 Then - der Nutzer bekommt eine Bestätigungs-
eMail
 and die Daten des Nutzers werden aus der
Datenbank gelöscht
Konkretes Beispiel

12. Schätzung und Dialog
13
User
Stor
y

13. Von der Idee zur Umsetzung
14
Epic
User Story
Erste Vorstellung der
User Story +
Akzeptanzkriterien
Vollständig verstandene User Story
+ Akzeptanzkriterien
Kommunikative Ergänzungen zur User Story
R
E
F
I
N
E
M
E
N
T
Sprint Planning
Story Time
Sprint
Product Backlog
Schätzung der User Story Story Time

14. Backlog-Management
Agilität erleben
Portfolio
Backlog
Feature
Backlog
Product Backlogs
Sprint Backlogs
NFA
Architektur-
entscheidungen
User
Story
User
Story
User
Story
User
Story
User
Story
User
Story
Task
Task
Task
Task
Task
Task
Task
Task
Task
GesetzeGf-Ziele
Use Case
Feature …..
1. -----
2. -----
3. -----
4. -----
5. -----
6. -----
1. -----
2. -----
3. -----
4. -----
5. -----
6. -----
1. -----
2. -----
3. -----
4. -----
5. -----
6. -----
1. -----
2. -----
3. -----
4. -----
5. -----
6. -----
1. -----
2. -----
3. -----
4. -----
5. -----
6. -----
1. -----
2. -----
3. -----
4. -----
5. -----
6. -----
1. -----
2. -----
3. -----
4. -----
5. -----
6. -----
1. -----
2. -----
3. -----
4. -----
5. -----
6. -----
…
…
….
Nachverfolgbarkeit
z.B. Sicherheits-
anforderungen
Akzeptanz-
kriterienAkzeptanz-
kriterienAkzeptanz-
kriterien

15. Status „Ready“ und „Done“
• READY – Qualität der User Story (Anforderungen)
• DONE – Abnahmekriterien für User Story (Anforderungen)
16
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkreme
ntSprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
R
E
A
D
Y
D
O
N
E

16. Vision

17. Scrum
18
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Definiton
of Done
Scrum Guide 2013
Vision

18. Quelle: Alice im Wunderland, Film 2010

19. "Würdest Du mir bitte
sagen, welchen Weg ich
einschlagen muss?"
"Das hängt in
beträchtlichem Maße
davon ab, wohin du gehen
willst"
"Oh, das ist mir ziemlich
gleichgültig"
"Dann ist es auch einerlei,
welchen Weg du
einschlägst"
Quelle „Alice im Wunderland“
Lewis Carroll / 26. 11 1865

20. Vision Board
21

21. Planung

22. „Wir können nicht hinter den Horizont
schauen“ (Mike Cohn)
-24-

23. Scrum
25
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Definiton
of Done
Scrum Guide 2013

24. Abhängig vom Planungskontext sind unterschiedliche
Planungshorizonte* notwendig
*: basierend auf Ellen Gottesdiener
PO und ManagementPO-Team
Scrum-Team
Sprint Release
(1-6 Monate)
Roadmap
(6 Mon. – 2 Jahre)

25. Ziele der Planungshorizonte
*: basierend auf Ellen Gottesdiener
 Ausblick auf
kommende
Themen /
Epics / Feature
 Gemeinsames
Verständnis erzielen
 Konkrete Fragen des
Teams beantworten
 Akzeptanzkriterien
ergänzen
 User Stories schätzen
 Ermittlung von
Abhängigkeiten
 Epics / Feature
 Epics in User Stories
splitten
 Grobe Varianten
erörtern und schätzen
Nächste
1-2 Sprints
Release-
Vorschau
Das große Ganze
Roadmap

26. Abstimmung

27. Scrum – ein Blick ins Daily
29
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Definiton
of Done
Scrum Guide 2013

28. Daily - Scrum
30
„…und ich
mach die
Toten“
…Ich mache den
Task
„DB-Modell“
anpassen …
…Ich mache den
Task „Menueleiste
anpassen„…
?
„…die Toten
machen wir
nicht…“

29. Scrum – mit vielen POs
31
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Definiton
of Done
Scrum Guide 2013
PRE Planning

30. Product Owner Pre-Planning
-32-
Velocity
Velocity
Velocity
Produktvision
 Abgleich der geplanten
Backlog Items mit
Strategie
 Fachliche
Abhängigkeiten
 Technische
Abhängigkeiten
 Know How Transfer
Sprint
oder
Release
Architektur-
Vision
Chief
Product Owner
PO Pre-Planning
Product Owner
Product Owner
Product Owner
Abgestimmtes
Backlog

31. Anforderungserhebung

32. 34

33. Sprint Review – die traurige Realität
ScrumMaster
Entwicklerteam
Product Owner

34. Sprint Review als Feedback- und Erhebungsworkshop
„Das Ergebnis des Sprint Reviews ist ein potentiell neu organisiertes
Product Backlog, bei dem die am höchsten bewerteten Product
Backlog-Einträge am wahrscheinlichsten für das nächste Sprint
Planning ausgewählt werden.“
Quelle: Scrum Guide 2013
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Definiton
of Done

35. Umdenken
Funktionale Dekomposition Agiles nutzenorientiertes Umfeld
Epic
User Story 1 User Story 2 User Story 3  

Epic 1
User Story 1

Epic 2
User Story 1

Feedback
Potentiell
lieferbares
Produkt-
inkrement
Feedback
Potentiell
lieferbares
Produkt-
inkrement
User Story 2
User Story 3



36. Feedback im agil skalierten Umfeld
Hotline
Endanwender
Session-basiertes Testen
….
Beta-Kunden /
Pilotierung
Endanwender EndanwenderPilotierungskunden
Optionale Nutzung
Product
Owner
Review-Event
(Feedback- & Erhebungsworkshop)
Videoaufzeichung
Scouts beim
Endkunden
Usability
Prototyping
UX
Usability Testing

37. Rollen im Business-Team

38. Der PO – ein Superheld?
40
Product Owner

39. Terminator
Quelle: http://www.fuenf-filmfreunde.de/2009/04/23/ist-arnold-schwarzenegger-im-neuen-terminator-salvation-doch-zu-sehen/

40. NORMator
Quelle: http://prem666.deviantart.com/art/Terminator-Robot-Face-398031009

41. NORMator – der Mann / die Frau für das regulierte Umfeld
NORMator

42. Dokumentation
44
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkreme
ntSprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Definiton
of Done
NORMatorDoR / DoD
Sprint Notes
Team Charta
Architecture
Notes
Release
Notes
Test
Documentation
Prozess

43. NORMator im Überblick
Agilität erleben 45
NORMator
Validierung der Gebrauchstauglichkeit
- User
- Gebrauchsformen
- Szenarien
- Schnittstellen
Risikomanagement
- Risikoanalyse
- Maßnahmen
- Dokumentation
Traceability
sicherstellen
……
Vollständigkeit der Dokumentation
- Prozessvorgehen
- Sprintnachweis
- Architektur
- Teamcharta
- ….

44. Business-Team mit PO und NORMator
46
NORMator
Product Owner

45. Der Business Analyst – was wird aus ihm?
47
Business Analyst

46. Story Mapping
Prozess (zeitlicher Ablauf)
… … … ……
Aktivitäten
R
a
n
k
i
n
g
Aufgaben/ Tasks
……..
……..
……..
……..
…….. ……..
…….. ……..
……..
……..
……..
……..
……..
……..

47. Story Mapping – Beispiel „Buchversand“
Prozess (zeitlicher Ablauf)
Buchung
finden
Angebote
sichern
Bestellen-
daten
Bestellinfor-
mationen
Zahlungs-
möglichkeiten
Aktivitäten
R
a
n
k
i
n
g
Aufgaben/ Tasks
Warenkorb
legen
Merkliste
speichern
Wunschliste
speichern
Lieferadresse
eingeben
Rechnungs-
adresse
eingeben
Voraus-
überweisung
Per PayPal
zahlen
Bestellstatus-
Informationen
einsehen
Kreditkarte
nutzen
Suche durch
Titel
Suche nach
Autor
Suche nach
ISBN-Nr
……..
Per Rechnung
zahlen

48. Business-Team mit PO, BA und NORMator
50
NORMator
Product Owner
Business
Analyst
Prozess (zeitlicher Ablauf)
Aktivitäten
R
a
n
k
i
n
g
Aufgaben / Tasks

49. Zusammenfassung

50. Scrum und mögliche Erweiterungen
52
Product
Backlog
Sprint
Backlog
Potentiell
lieferbares
Produktinkrement
Sprint Planning Review
Retrospektive
Daily Sprint
Sprint
Max. 30 Tage
Scrum Guide 2013
Story Time
User
Stor
y
Vision
R
E
A
D
Y
D
O
N
E
PRE Planning
NORMator

51. Software-Entwicklung ist häufig komplex
Technologie
Anforderungen
bekannt unbekannt
bekanntunbekannt

52. Merkmale eines agilen Requirements Engineering –
es muss nicht immer Scrum sein
 RE ist eine kontinuierliche Tätigkeit und endet nicht nach einer Phase
 Abkehr von der Vorstellung einer vollständigen Spezifikation /
Änderungen sind willkommen
 Direkte Kommunikation steht im Mittelpunkt und nicht die Spezifikation
 „Wert“ einzelner Funktionen steht im Fokus und beeinflussen Rangfolge
 Kontinuierliches Feedback
 Teammitglieder und deren Know-how werden involviert
 Abkehr einer „in Stein gemeißelten“ Kosten- und Zeitplanung am Anfang
eines Projekts
 Verschwendung vermeiden

53. Das Agile Manifest – 12 Prinzipien
-55-
Unsere höchste Priorität ist es, den Kunden durch frühe und
kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
Heiße Anforderungsänderungen selbst spät in der
Entwicklung willkommen. Agile Prozesse nutzen
Veränderungen zum Wettbewerbsvorteil des Kunden.
Liefere funktionierende Software regelmäßig
innerhalb weniger Wochen oder Monate
und bevorzuge dabei die kürzere Zeitspanne.
Fachexperten und Entwickler müssen
während des Projektes täglich
zusammenarbeiten.
Errichte Projekte rund um motivierte Individuen. Gib ihnen
das Umfeld und die Unterstützung, die sie benötigen und
vertraue darauf, dass sie die Aufgabe erledigen.
Die effizienteste und effektivste Methode,
Informationen an und innerhalb eines
Entwicklungsteam zu übermitteln, ist im
Gespräch von Angesicht zu Angesicht.
Funktionierende Software ist
das wichtigste Fortschrittsmaß.
Agile Prozesse fördern nachhaltige
Entwicklung. Die Auftraggeber, Entwickler
und Benutzer sollten ein gleichmäßiges
Tempo auf unbegrenzte Zeit halten können.
Ständiges Augenmerk auf
technische Exzellenz und
gutes Design fördert Agilität.
Einfachheit -- die Kunst, die
Menge nicht getaner Arbeit
zu maximieren -- ist essenziell.
Die besten Architekturen,
Anforderungen und Entwürfe
entstehen durch
selbstorganisierte Teams.
In regelmäßigen Abständen reflektiert
das Team, wie es effektiver werden
kann und passt sein Verhalten
entsprechend an.

54. Fragen und Diskussion

55. Andreas.Becker@HOOD-Group.com
HOOD GmbH
Büro München
Keltenring 7
82041 Oberhaching
Germany
Tel: 0049 89 4512 53 0
www.Agile-by-HOOD.com Andreas Becker
Agile Coach