1. adressierte Probleme
1.1. Komunikationsprobleme bei Erstellung der Softwareanforderungen
1.2. Kommunikation zwischen Stakeholder/Benutzer und Ersteller/Entwickler
2. Warum
2.1. Focus auf Kommunikation legen, anstatt auf Dokumente
2.2. Fokus Dokument
2.2.1. Der Anwender bekommt nicht was er will, sondern das was geschrieben wurde
2.2.1.1. Interpredation im Auge des Betrachters
2.2.1.2. Ohne Kommunikation wird evtl. was anderes implementiert
2.2.1.3. Anforderungen können ungenau sein
2.2.1.4. Beispiel Wieges No Words kann, sollte, müsste
2.3. Stories sind verständlicher
2.4. iterative Entwicklung möglich
2.5. Kann mit Epics starten
3. Was kann falsch gehen
3.1. keine ausgewogene Balance
3.1.1. zuviel von
3.1.1.1. Business
3.1.1.1.1. Funktionaltiät und Daten stehen im Vordergund
3.1.1.1.2. Wenig Bezug auf Machbarkeit und ob Entwickler die Anforderungen verstanden haben
3.1.1.2. Entwickler
3.1.1.2.1. Sprache zu technisch
3.1.1.2.2. Verlust des Bezugs, was das Business will/braucht
3.1.2. Patterns und Antipatterns
3.2. Ressourcen
3.2.1. Effiziente Zuordung/Aufgabenteilung
3.3. Verantwortlichkeiten
3.3.1. Wenn Entwickler verantwortlich für
3.3.1.1. Features
3.3.1.2. Qualität
3.3.1.3. Entscheidungen die das Business beeinflussen
3.3.2. Business
3.3.2.1. Wenn Prioritäten fehlen und Entscheidungen nahe der Deadlines getroffen werden müssen
3.4. Schlechte Planung
3.4.1. Entwickler schätzen häufig zu wenig
3.4.2. Neue Ideen durch User, wenn sie die Software sehen
3.4.3. Es kann so nicht genau definiert werden, was geliefert werden soll
3.5. One Size fits All
3.5.1. http://vimeo.com/53159408
3.5.1.1. Tom Gilb
4. Wie gegensteuern
4.1. Entscheidungen aufgrund der bestehenden Informationen machen
4.2. Anstatt einmal eine grosse Entscheidung zu fällen, lieber kleine über das Ganze Projekt
4.3. Ein Ansatz sind User Stories
5. Stories
5.1. Three C´s
5.1.1. Cards
5.1.1.1. Story mit Notizen und Schätzungen
5.1.2. Conversation
5.1.2.1. Details hinter der Story
5.1.2.2. Product Owner (Projektleiter)
5.1.3. Confirmation
5.1.3.1. Kriterium, wann die Story korrekt realisiert ist
5.1.3.2. mit Test
5.2. erfüllen INVEST
5.2.1. Independent
5.2.2. Negotiable
5.2.3. Valuable
5.2.4. Small
5.2.5. Testable
5.3. Der Story-Text ist weniger wichtig, als die Diskussion die dabei entsteht
5.4. Terms
5.4.1. Epic
5.4.1.1. Eine sehr grosse User Story
5.4.1.1.1. Aufteilen
5.4.1.1.2. Alles >= 18 Story Points
5.4.2. Theme
5.4.2.1. Collection von kleinen zusammenhängenden Stories
5.4.3. Spike
5.4.3.1. Machbarkeit
5.4.3.2. Prüfen, ob technische und funktionale Aspekte realisiert werden können
5.4.3.3. Ergebniss sind reine Informationen
5.4.3.4. losgelöst von einer Iteration
5.5. Pointer to the Requirement (Platzhalter)
5.5.1. Diagramme
5.5.2. Skizzen
5.5.3. Mockups
5.5.4. Aber auch Dokumente
5.6. Aufbau Story
5.6.1. As a <user role>
5.6.2. I <want, need, can> <goal>
5.6.3. so that <benefit> <reason>
5.7. Details
5.7.1. Conditons of satisfaction
5.7.1.1. Testfälle
5.7.1.1.1. Akzeptanztest
5.7.1.1.2. bsp. Prüfen ob Partner benachrichtigt wurde
5.7.1.1.3. Als Demo für den Benutzer
5.7.1.1.4. Scenarios (Gherkin)
5.7.1.2. Details von Product owner
5.7.2. added in smaller sub-stories
5.7.3. Kombination möglich
5.8. Kleine Stories mit Details werden mit Priorität behandelt
5.8.1. bessere Kontrolle
5.8.2. schneller zu implementieren
5.9. Splitten
5.9.1. Horizontal
5.9.1.1. Getrennt nach Komponenten
5.9.1.1.1. UI
5.9.1.1.2. Business Logik
5.9.1.1.3. Datenbanklayer
5.9.1.2. erschwert die Sprint-Planung
5.9.1.2.1. unbedingt vermeiden
5.9.2. Vertikal
5.9.2.1. Pattern
5.9.2.1.1. Workflow Steps
5.9.2.1.2. Business Rule Variations
5.9.2.1.3. Major Effort
5.9.2.1.4. Simple/Complex
5.9.2.1.5. Variations in Data
5.9.2.1.6. Data Entry Methods
5.9.2.1.7. Defer Performance
5.9.2.1.8. Operations (CRUD)
5.9.2.1.9. Break out a Spike
5.9.2.2. Top-Down-Andatz
6. Story-writing Workshops
6.1. mit dem ganzen Team ggf. auch Stakeholder
6.2. Brainstorming um User Stories zu erstellen
6.3. User Story Mapping
6.3.1. Quick Referenz
6.4. Agile Planing
6.5. Ziel
6.5.1. Viele Stories schreiben
6.5.1.1. auch Epics
6.5.1.1.1. aufteilen in kleine Stories
6.5.1.2. und solche die fertig sind zur Implementierung
6.5.2. Keine Priorisierung
6.5.3. fördert Kreativität
6.5.4. Story-Hierarchien bilden
6.5.5. regelmässig
6.5.5.1. Bsp. alle 3 Monate