App Kostenrechner

Das Burndown Chart veranschaulicht den Fortschritt eines Sprints. Ein Burndown Chart stellt die noch zu bearbeitenden Items, z.B. als Story Points, im Verhältnis zur Zeit grafisch dar. Die Story Points sind dabei normalerweise auf der Y-Achse und die Zeit auf der X-Achse aufgetragen (siehe auch Burn-up Chart). Mit Hilfe des Burndown Charts lassen sich Abweichungen im Verlauf eines Sprints frühzeitig erkennen und angemessene Lösungsmaßnahmen können rechtzeitig begonnen werden.

Im Sprint Backlog befinden sich die im aktuellen oder kommenden Sprint zu bearbeitenden User Stories und Aufgaben. Die Lieferung der im Sprint Backlog befindlichen User Stories im Sprint wurde vom Team prognostiziert. Ziel eines Sprints ist die Fertigstellung eines nutzbaren und releasefähigen Inkrements.

Das Improvement Backlog ist eine nach Priorität geordnete Liste mit Maßnahmen zur Verbesserung der Zusammenarbeit. Die Improvements sind Ergebnisse der Sprint Retrospektiven und werden im Improvement Backlog als Stories abgebildet und zusammengefasst. Für die Pflege des Improvement Backlog ist nicht der PO sondern das Team verantwortlich.

Je nachdem wie häufig ein Backlog Refinement stattfindet, kann eine Sprint Planung für einen zweiwöchigen Sprint zwei bis sechs Stunden als angemessen betrachtet werden.

Sprints (Kurze Entwicklungszyklen von zwei bis vier Wochen) bilden die Grundlage für schnelles Feedback und Anpassungen am Produkt. Während des Sprints fokussiert sich das Entwicklungsteam auf die Erstellung fertiger Software Inkremente. So wie alle regelmäßigen Aktivitäten verändern Sprints ihre Dauer optimalerweise nicht.

Das Produktinkrement besteht aus allen bisher fertig gestellt Backlog-Einträgen (frühere und aktueller Sprint), die der Definition of Done entsprechen.

Die Definition of Done ist eine Auflistung von Vorbedingungen welche erfüllt sein müssen, damit ein Backlog Item als fertig bezeichnet werden darf. Mit wachsender Erfahrung des Teams verändert sie sich im Laufe der Zeit. Die Definition of Done enthält unter anderen:

• funktionale Anforderungen (“Die bereitgestellten Funktionen arbeiten wie gewünscht”)
• nicht funktionale Anforderungen (“Die Antwortzeit muss unter einer Sekunde liegen”)
• Prozessuale Bestandteile (“Freigabe durch den Product Owner ist erfolgt”)
• Qualitätskriterien (“Code Review wurde durchgeführt”, “Test wurde erfolgreich durchgeführt” etc.)

Planning Poker ist eine Technik zur “Größenabschätzung” von Backlog Items (Stories, Tasks etc.), welche vor allem im Refinement und im Planning I Anwendung findet.

Der Grundgedanke hinter der Methode ist die relative Schätzung der Backlog Items. Planning Poker führt zu realistischen Einschätzungen des Teams und fördert durch die Diskussion der Schätzung und deren Hintergründe das gemeinsame Verständnis der Story im Team.

Bereits nach ca. 4-5 Sprints kann man erkennen wie viele Story Points ein Team im Sprint abarbeiten kann. Auf Basis dieser Erkenntnis ist es dann möglich, eine Releaseplanung durchzuführen.

In der Definition of Ready (DoR) werden all die Kriterien gesammelt, die erfüllt sein müssen damit eine Story in den Sprint aufgenommen werden kann. In der DoR werden zum Beispiel folgende Punkte geprüft:

• Die Story ist klar und verständlich geschrieben
• Alle Teilaspekte der Story wurden mit dem Team besprochen und von diesem verstanden
• Der Product Owner hat eine Priorisierung der Story vorgenommen
• Das Team hat eine Schätzung abgegeben
• Es wurden Akzeptanzkriterien (z.B. mindestens drei) genannt
• Externe Abhängigkeiten wurden diskutiert

Im Sprint Review, am Ende eines jeden Sprints, präsentiert das Entwicklungsteam das fertiggestellte Produkt Inkrement.

Das Ziel des Sprint Reviews ist die Synchronisation aller Beteiligten über den aktuellen Stand der Arbeiten (keine Folien). Somit wird eine Entscheidungsgrundlage über die folgenden Produkterweiterungen für das Planning I gelegt.

Der Sprint Review kann für einen zweiwöchigen Sprint innerhalb von 30-60 Minuten durchgeführt werden. Eine detaillierte Vorbereitung und Abstimmung im Entwicklungsteam von maximal einer Stunde ist dabei angeraten.

Im Planning 2 werden die User Stories vom Entwicklungsteam in Tasks zur Entwicklung und zur Erfüllung der Definition of Done zerlegt.

Durch das Daily wird der kontinuierliche Informationsaustausch zwischen den Teammitgliedern gefördert. Ziel des Dailys ist es, vorrangig einen Überblick darüber zu erhalten was die Teammitglieder am vorigen Tag getan haben, woran sie heute arbeiten werden und was sie in ihrer Arbeit behindert. So sorgt das Daily für Transparenz und die Möglichkeit für die Teammitglieder sich optimal zu unterstützen und Abhängigkeiten zu erkennen. Das Daily ist insbesondere kein Statusmeeting für den Product Owner oder gar den Scrum Master. Es ist streng darauf zu achten, dass Dailys die vereinbarte Zeit, optimalerweise 15 Minuten, nicht überschreiten.