VPM3

• 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.