VPM3

• 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

1, 2, 3, 5, 8, 13, 20, 40, 100

Estimating the relative size of a Story. 

• Das Sprint-Ziel beeinflusst die Auswahl der Stories im Sprint Planning
• Scrum-Team hat sich committet, das Sprint-Ziel zu erreichen

1. User Stories zu einer Story zusammenfassen oder umschreiben, damit diese keine Abhängigkeit mehr aufweisen.
2. Storie werden zu gross oder unschätzbar in Story-Points

Koordinieren von externen Dingen wie Bereichte, Steuerungsgruppen, Anfragen von Aussen, Eskaltionen. 

Ein Dev-Team sollte in der Lage sein, das Ziel eines jeweiligen Sprints ohne grössere äussere Abhängigkeiten zu erreichen. Deshalb sollte jede Rolle im Team vertreten sein (Architekt, Entwickler, Tester, Dokumentationsexperte, Datenexperte etc.)

(a) velocity

(b) story points

(c) initial velocity

(d) median velocity 

• Break down the user stories in smaller stories
• Use MuSCoW (Must-Have, Should-Have, Could-Have, Won't have this time)

1. Always vertically
2. When breaking down horizontally, normally dependencies occur which are complex and not implementable withing one sprint. 

Managementtheorien bzw. Führungsphilosophien

Theorie X: nimmt an, dass der Mensch von Natur aus faul ist und versucht, der Arbeit so gut es geht aus dem Weg zu gehen. Theorie Y davon aus, dass der Mensch durchaus ehrgeizig ist und sich zur Erreichung sinnvoller Zielsetzungen bereitwillig strenge Selbstdisziplin und Selbstkontrolle auferlegt. Er sieht Arbeit als Quelle der Zufriedenheit und hat Freude an seiner Leistung. Auch Verantwortungsbewusstsein und Kreativität prägen dieses Menschenbild.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• (Inspiring presentation over formally correct content)

Transparency: This means presenting the facts as is. All people involved are transparent in their day-to-day dealings with others. (Product packlog; story board)

Inspection: Inspection by everyone on the Scrum Team. For example, the team openly and transparently shows the product at the end of each Sprint to the customer in order to gather valuable feedback. (daily scrum)

Adaptation: Adaptation in this context is about continuous improvement, the ability to adapt based on the results of the inspection. (sprint-retrospective)

Unsere höchste Priorität ist es,
den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.

Heisse 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 Entwicklungsteams 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.

• 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