VPM3

• Product Backlog – digitales Treibhaus der Kundenwünsche
• Sprint Backlog – teaminterne Aufgabenliste
• Burn-Down Chart – den Fortschritt kontrollieren

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint-Retrospektive

• Agiles Schätzen schätzt die relative Grösse einer Story und nicht die Entwicklungsdauer
• Agile Schätzen erfolgt in Story-Points
• Personentage != Arbeitstage

• Die Anzahl der Story Points einer User Story drückt ausschließlich ihre Größe im Vergleich zu anderen User Stories aus.
• Daraus kann abgeleitet werden, dass die relative Schätzung genauer ist, als die Schätzung von fixen Einheiten wie Dauer. 

Schätzen hat immer etwas mit Wahrscheinlichkeiten und Unsicherheiten zu tun. Ein Team wird zwar mit zunehmender Schätzerfahrung besser. Was jedoch immer bleibt, ist die Tatsache, dass eine Schätzung immer unsicherer wird, je größer und weniger konkret die zu schätzende User Story ist. Und genau diese Unsicherheit versucht die vorgeschlagene Fibonacci-Folge zu berücksichtigen und in den Schätzungen zum Ausdruck zu bringen. Die zunehmend größer werdenden Lücken in der Sequenz vermeiden, dass eine nicht vorhandene Schätzgenauigkeit suggeriert wird. Je größer die Story ist, desto unsicherer werde ich mir mit der Schätzung, und das drücke ich aus, indem ich einen Wert oberhalb der 13-Punkte-Marke wähle.

• Ziel des Pokerns ist die effiziente Ermittlung zuverlässiger Schätzwerte unter Einbeziehung des gesamten Teams.
• Zu grosse Differenzen: Die Personen mit der höchesten und niedrigsten Punktzahl erklären ihre Einschätzung. Danach wird erneut geschätzt. 
• Effiziente Pokerrunden erfordern striktes Timeboxing: maximal 15 Minuten pro User Story

• Die Entwicklungsgeschwindigkeit des Teams wird als Velocity bezeichnet und ist die Anzahl an Story Points, die ein Team während eines Sprint umsetzen kann.
• Sprint 1 startet ohne Velocity. 
• Je länger ein Projekt dauert, desto mehr Daten sind vorhanden und desto genauer wird die Velocity als Mass für die Planung von Sprints/User Stories/Releases. 

Agile Planung ist eine Velocity-basierte Planung, in der das Team auf Basis der angenommenen Velocity seinen Sprint-Plan und der Product Owner auf Basis dieser Velocity den Releaseplan erstellt.

Velocity korrigiert Schätzfehler:
Der Lerneffekt besteht in der Erkenntnis, dass man weniger geschafft hat, als ursprünglich geplant, und diesen Lerneffekt nutzt man, indem man bei der nächsten Planung eine geringere Velocity zugrunde legt.

Neubewertung von User Stories: 
stellt sich heraus, dass zu wenig/zu viel Story Points geschätzt wurden, wird dies nicht mehr angepasst!

Urlaub, Krankheit und ähnliche Ereignisse: 
Dass die Realität nicht nur aus Arbeitstagen, sondern auch aus Urlaubs-, Feier- oder Krankheitstagen besteht, ist bereits implizit in der Velocity enthal- ten.

Karte (=Form), Konversation (=Versprechen, sich über Details zu unterhlaten) und Akzeptanzkriterien („Definition of Done“)

Möchte man etwas entwickeln, was der Kunde wirklich will, dann sollte man es nicht aufschreiben. User Stories verlagern den Schwerpunkt des Anforderungsmanagements vom Schreiben aufs Sprechen.

User Stories:

• fördern den Dialog zwischen Entwickler und Kunden
• sind frei von technischem Jargon und
• werden vom Kunden und Entwickler gleichermaßen verstanden

• Die Sprache des Kunden
• Benutzerrollen: Sicht des Anwenders einnehmen
• User Story Muster: Als <Benutzerrolle> will ich <das Ziel>[, so dass <Grund für das Ziel>].

INVEST

Das Product Backlog ist eine Liste aller im Projekt bekannten User Stories. Jedes Scrum- Projekt hat genau ein Product Backlog. Es ist die einzige und zentrale Instanz, die sämtliche funktionalen Anforderungen des Systems enthält.

• Das Product Backlog ist unvollständig und dynamisch. Beim Erstellen des Backlog ist es keinesfalls Ziel, sämtliche potenziellen Anforderungen des Systems zu erfassen.
• Das Product Backlog muss gut sichtbar und für jeden Beteiligten zugänglich sein. 
• Das Product Backlog sollte nur User Stories enthalten, keine anderen Tätigkeiten wie Bugfixes etc. 

Ganz allgemein formuliert wird die Wichtigkeit einer Story durch ihren Geschäftswert be- stimmt. 

Finanzieller Wert: Der finanzielle Wert einer Story lässt sich daran messen, inwieweit die Story dazu beiträgt, Geld einzunehmen oder Kosten zu reduzieren. 

Kosten: Die Kostenbestimmung erfolgt auf der Basis von Story Points. Es wird ausgerechnet, was ein Team pro Sprint kostet und wie viele Story Points das Team durchschnittlich umsetzt.

Kundenzufriedenheit: Basis-Stories, Begeisterungs-Stories.

Risiko: Je höher das von ei- ner Story adressierte Risiko, desto höher sollte die Story priorisiert werden. Hingegen birgt eine risikoreiche Story das Risiko in sich selber, und es ist fraglich, ob die Story überhaupt machbar ist.

Abhängigkeiten: A muss vor B erledigt werden? => A muss höher priorisiert werden. 

Vertikales Schneiden
Schneiden nach Daten
Schneiden nach Aufwand
Schneiden nach Forschungsanteilen
Schneiden nach Qualität
Schneiden nach Benutzerrolle
Schneiden nach Akzeptanzkriterien
Schneiden nach technischer Voraussetzung

z.B. Performance, Skalierbarkeit,  Ausfallsicherheit, Fehler, Refactorings, das Aufsetzen von Test- und Stagingservern oder auch die Installation eines Bugtracking-Systems.

• Anforderungen umformulieren: die allgemein oder technisch erscheinende Anforderung als User Story zu formulieren.
• Constraints: Constraints werden auf andersfarbigen Karteikarten notiert und gut sichtbar an die Wand gehängt. Betrifft eine Constraint eine bestimmte User Story, dann kann die Constraint-Karte neben die Story-Karte gehängt werden. 
• Fehler: Eine Story mit Fehlern ist nicht fertig und wird vom Product Owner nicht abgenommen. Unterschied Planbar und Sofort zu lösen. 
• Technisches Backlog. Eigner des technischen Backlog ist das Dev Team

1. User Tasks erstellen: konkrete Einzelschritte, die ein Benutzer durchläuft, wenn er eine bestimmte Aufgabe mit der Anwendung durchführen will. Ein User Task ist eine konkrete, klar zu anderen Tasks abgrenzbare Einzelaufgabe oder Aktion. User Tasks haben aktiven Charakter, das heißt ihre Beschreibung enthält üblicherweise ein Verb, das die entsprechende Aktion ausdrückt.

2. Zusammengehörigr Tasks gruppieren zu User Activities. Die Activity repräsentiert das den Tasks übergeordnete Ziel.

3. Im dritten Schritt werden die User Activities von links nach rechts horizontal in der Reihenfolge angeordnet

4. Schritt 4: User Tasks durchlaufen = Geschichten erzählen

5. Schritt 5: User Stories schreiben

• Methode zur Entwicklung „breiter“ Product Backlogs. Verglichen mit einem Product Backlog liefert eine Story Map eine wesentlich kohärentere Sicht auf das Produkt.
• Ausgehend von einer Produktvision werden User Tasks gebrainstormed, zusammengefasst und geordnet, so dass nach und nach ein immer kompletteres Bild der Anwendung entsteht. Die so entstehende Story Map bildet den Startpunkt für die Befüllung des Product Backlog. 

Im Sprint Planning 1 geht es um das „Was“: Welche Stories werden im kommenden Sprint umgesetzt. Im Sprint Planning 2 geht es um das „Wie“: Wie werden die ausgewählten Stories umgesetzt.

Product Owner, ScrumMaster und das komplette Entwicklungsteam sind Pflichtteilneh- mer des Sprint Planning Meetings. Darüber hinaus werden alle Personen benötigt, die In- formationen besitzen beziehungsweise Entscheidungen treffen können, die für das Com- mitment des Teams erforderlich sind.

• Vorbereitung durch den Product Owner in Zusammenarbeit mit dem ScrumMaster. 
• Der Product Owner ist dafür zuständig, eine ausreichende Menge an User Stories präsentationsgerecht aufzubereiten.
• Der ScrumMaster bestimmt die angenommene Velocity des anstehenden Sprint auf Basis der tatsächlichen Velocity der Vorgänger-Sprints.

• Sprint-Ziel – Warum führen wir den Sprint durch?
• Vorstellung der US, Analyse und Commitment

• Das Sprint Planning 2 findet am Nachmittag des Sprint Planning Meetings statt und ist auf vier Stunden begrenzt. 
• Das Team beginnt mit der ersten Story des Selected Backlog und arbeitet gemeinsam am Design der Story.
• Der Product Owner sollte in der Nähe bleiben, damit fachliche Fragen unmittelbar geklärt werden können.
• Ist das Design ausreichend weit besprochen, nimmt sich das Team 5–10 Minuten Zeit und zerbricht die Story in Einzeltasks. Hierbei geht es darum, die ganz konkreten Aufgaben zu ermitteln, die für die Umsetzung der Story abgearbeitet werden müssen. Sind die Tasks der Story ausreichend genau bestimmt, setzt das Team seine Arbeit mit der nächsten Story fort.

• Zeit, Kosten und Qualität werden am Anfang des Sprint festgelegt und sind danach nicht mehr verhandelbar.
• Die einzig variable Größe eines Sprint ist die Funktionalität. Konkret bedeutet dies, dass die Menge der abgelieferten User Stories beziehungsweise der Funktionsumfang einzelner User Stories während des Sprint variieren kann.
   
• Idealerweise arbeitet das gesamte Team an einer einzigen Story, schließt sie vollständig ab und geht anschließend zur nächsten Story über.
• Jedes Team muss seine eigene „Definition of Done“ erstellen.

• Das Sprint-Review ist das offizielle Abschlussmeeting des Sprint, in dem das Team seine Arbeitsergebnisse präsentiert. Das Meeting wird vom ScrumMaster vorbereitet und mode- riert und dauert nicht länger als eine Stunde.

• Jeder aktive Teilnehmer investiert maximal eine Stunde Vorbereitungszeit.

• Der Product Owner überlegt sich spätestens jetzt das Ziel und die zugehörigen User Stories des Folge-Sprints.

• Das neue Ziel des Meetings besteht darin, Feedback von der Außenwelt, insbe- sondere vom Kunden und den Anwendern zu bekommen.

• Source Code Management und Story-Branches
• Kontinuierliches Integrieren
• Automatisierung
• Verständlicher Quellcode
• Elektronische Sprint Backlogs und Burndown-Charts

Ein Akzeptanztest prüft, ob die fertiggestellte User Story die Erwartungen des Kunden hinsichtlich der zugrundeliegenden Geschäftsregeln erfüllt. Damit der Product Owner die- se Erwartungen testen kann, muss er sie zuvor formulieren und mit dem Kunden abstimmen.

Akzeptanzkriterien: Sie beschreiben einen Satz von Bedingungen, die erfüllt sein müssen, damit der Product Owner die User Story abnimmt. Akzeptanzkriterien sind die stabilen Eckpfeiler einer User Story und werden als fester Bestandteil auf die Rückseite ihrer Story-Karte geschrieben

Akzeptanztesten vereint die beiden Begriffe Akzeptanzkriterium und Akzeptanztest zu ei- nem ganzheitlichen Entwicklungs- und Abnahmeprozess von User Stories. Ziel dieses Prozesses ist es, User Stories nicht erst nach Fertigstellung Akzeptanz zu testen, sondern die Stories entlang ihrer Akzeptanzkriterien zu entwickeln und kontinuierlich abzunehmen.

• Spezifisch. Für verschiedene Leser dieselbe Bedeutung. 
• Messbar.
• Fokussiert.
• Kein User Interface. User Interfaces beschreiben, „wie“ der Benutzer etwas tut. Akzeptanzkriterien sollten stattdessen beschreiben, „was“ der Be- nutzer mit der neuen Funktion tun kann.
• Warum. 
• Realistisch.
• Sprache der Anwendungsdomäne.

• Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality.
• Three amigos, representing the three perspectives of customer (what problem are we trying to solve?), development (how might we solve this problem?), and testing (what about...).

• Die Retrospektive wird vom ScrumMaster geleitet und dauert nicht länger als drei Stunden. 
• Eine Retrospektive hat nur dann einen wirklichen Wert, wenn am Ende konkrete Aktionen für die Umsetzung der erkannten Entwicklungsmöglichkeiten beschlossen werden.

• Der Plan hat die Funktion, uns heute zu leiten und uns Entscheidungen basierend auf dem heutigen Wissensstand zu ermöglichen. Anstatt jedoch stur an dem einmal erstell- ten Plan festzuhalten, akzeptiert die agile Releaseplanung Veränderungen als Teil des Plans und kommuniziert sie frühzeitig und ehrlich.

• Durchführung von Test-Sprints
• Historische Daten
• Das Team bestimmen lassen