Der Agile Coach ist kein aktiver Bestandteil des Development Teams. Er ist eine Unterstützung, Sparringspartner und gibt neue Impulse für die agile Vorgehensweise. Auszüge aus den Aufgaben eines Agilen Coaches:

• Unterstützung und Implementierung agiler Methoden
• Herstellung von teamübergreifender Transparenz
• Unterstützung beim Product Backlog und Anforderungsmanagement
• Identifikation von Verbesserungspotenzialen
• Moderation und Steuerung von Meetings
• Workshopbegleitung und Moderation

Das Burn-Down-Chart verkörpert tägliches Risikomanagement. Es wird genutzt, um die Produktivität, also den Fortschritt des Development Teams, messbar und transparent zu machen.

Das Burn-Down-Chart wird in der Regel im Anschluss an oder im Daily Scrum aktualisiert. Es werden alle verbleibenden Tasks oder User Stories aktualisiert. So entsteht eine Übersicht der verbleibenden Restaufwände für die verbleibende Sprintdauer, sowie der bereits abgeschlossenen Aufgaben. Wir empfehlen bei neu formierten Teams, welche wenig Erfahrung mit agilen Prozessen vorweisen, das Burn-Down-Chart auf Task-Ebene zu führen. Sobald das Team eingespielt ist, sollte das Chart auf Ebene von User Stories geführt werden.

Das Daily Scrum ist eine kurze Besprechung des Development Teams. Es findet täglich zu einem festen Termin und in einer festen Timebox von 15 Minuten statt. Es gliedert sich in drei grundlegende Fragen, welche jedes Teammitglied beantwortet und den Kollegen vorstellt:

• Was habe ich seit dem letzten Daily Scrum erreicht?
• Was werde ich bis zum nächsten Daily Scrum erreichen?
• Was steht mir bei der Arbeit im Weg (Impediments)?

Das Daily Scrum ist kein Statusmeeting, es wird viel mehr über die zukünftigen Aktivitäten gesprochen – im Sinne einer Einsatzplanung. Synergieeffekte werden identifiziert, Transparenz geschaffen und die Effektivität gesteigert.

Das Development Team besteht aus Profis, die am Ende eines jeden Sprints ein fertiges Inkrement übergeben, welches potentiell auslieferbar ist. Es erstellen nur Mitglieder des Development Teams ein „potential shippable increment“.
Das Development Team arbeitet selbstorganisiert. Es hat alle Fähigkeiten um ein „potential shippable increment“ zu entwickeln und arbeitet auf Augenhöhe – es gibt keine Hierarchien innerhalb des Teams.

Eine Definition of Ready ist eine Definition, welche abgrenzt, in welchem Zustand eine User Story „ready for sprint“ ist. Es ist eine Liste von Kriterien, die an die Product Backlog Items gestellt werden, um sie in den nächsten Sprint aufzunehmen. Die Verantwortung zur Einhaltung der Definition of Ready obliegt dem Product Owner.

Eine Definition of Done ist eine Einigung, welche vom Development Team getroffen wird. Sie definiert in welchem Zustand eine User Story abgeschlossen und bereit für die Abnahme ist. Es ist eine Liste von Kriterien, die an alle Product Backlog Items gestellt werden. Die Verantwortung zur Einhaltung der Definition of Done obliegt dem Development Team.

Epics verwendet der Product Owner, um dem Development Team eine (neue) Produktanforderung darzustellen, die größer als eine User Story ist und i.d.R. aus mehreren User Stories besteht. Die Epics benötigen daher keine – mit User Stories vergleichbare – Detaillierung und bleiben auf grober Ebene. Um die Epics in Sprints umzusetzen, müssen aus einem Epic User Stories definiert werden, in denen der Detaillierungsgrad deutlich zunimmt.

Das Impediment Backlog wird vom Scrum Master geführt und bearbeitet. Es beinhaltet alle Hindernisse oder Störungen (Impediments), die bei der Arbeit auftreten und das Development Team bei der effektiven Aufgabenerledigung behindern. Zu unterscheiden ist zwischen internen (vom Team selbst lösbaren) und externen (vom Team nicht mehr lösbaren) Impediments.

Planning Poker ist eine der beliebtesten Methoden um neue Anforderungen zu schätzen. Es kann mit einer Abwandlung der Fibonacci-Folge (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) praktiziert werden. Das erleichtert die Schätzungen, denn es handelt sich dabei um eine Abwandlung, die ganz bewusst nach oben hin immer größere Sprünge macht, sodass die geringe Greifbarkeit sehr komplexer Anforderungen deutlich zum Ausdruck kommt.

Wie funktioniert Planning Poker?

• Der Product Owner stellt die zu schätzenden User Stories vor.
• Jedes Teammitglied schätzt selbstständig, wie komplex (in Story Points ausgedrückt) die jeweilige Anforderung zu sein scheint.
• Im Anschluss werden die Karten gleichzeitig und sichtbar aufgedeckt.
• Bei Abweichungen findet eine Diskussion statt, um die Gründe zu erläutern und ein gemeinsames Verständnis der User Story zu schaffen.
• Sobald das Development Team gemeinsam zu einer Entscheidung kommt werden die Story Points auf die User Story übertragen.

Das Product Backlog ist eine priorisierte Liste aller Anforderungen für ein Development Team. Es wird vom Product Owner angelegt, entwickelt und geführt und ist somit eine Ansammlung aktueller und zukünftiger Projektthemen. Im Zentrum des Product Backlogs stehen die Anforderungen aus Kundensicht. Im Product Backlog befinden sich sowohl User Stories als auch Epics. Die am höchsten priorisierten User Stories befinden sich absteigend im Product Backlog.

Der Product Owner ist für das Development Team das Sprachrohr zum Business.
Er ist der Visionär, stellt die Schnittstelle zum Kunden dar und gibt vor, was entwickelt wird.
Der Product Owner ist verantwortlich für den Return on Investment. Er definiert Epics, Akzeptanzkriterien, User Stories und priorisiert diese. Zusätzlich ist er ist für die Backlog-Pflege verantwortlich.

Die Produktvision ist der inspirierende und emotionalisierende Ausgangspunkt für ein neues Produkt. Die Produktvision legt die Richtung der Produktentwicklung fest und dient dem Scrum Team als Orientierung. Die Produktvision sollte kurz, präzise und prägnant formuliert sein.

In den Review-Meetings präsentiert das Development Team den Stakeholdern die Arbeit des letzten Sprints. Ebenfalls erklärt der Product Owner die umgesetzten User Stories und gibt einen Ausblick auf die kommenden Sprintaktivitäten. Es werden nur „potential shippable increments“ präsentiert – also nur abgeschlossene Arbeitsergebnisse des Development Teams.
Das Review-Meeting dient nicht der Abnahme der User Stories. Dies geschieht im Idealfall im Vorfeld durch den Product Owner. Die Stakeholder können die zukünftige Entwicklung mit ihrem Feedback zu den Produktinkrementen beeinflussen.

„Nach dem Sprint ist vor dem Sprint“. Nach jedem Sprint findet eine Retrospektive statt. Diese fördert die ständige Steigerung der Performance des Development Teams, sorgt für Mitarbeiterzufriedenheit und findet demnach nur teamintern inklusive Scrum Master und optional Product Owner statt. Insbesondere auch ohne Führungskräfte oder sonstige Stakeholder.

Der Scrum Master ist der Prozesshüter. Er ist dafür verantwortlich, dass das Development Team ungestört arbeiten kann und dass die Prozesse eingehalten werden. Er ist Mediator und Moderator und hat immer die passende Lösung. Er treibt das Development Team, ohne disziplinarische Verantwortung, zu Höchstleistungen an.

Das Sprint Backlog ist eine priorisierte Liste aller User Stories, die in dem aktuellen Sprint durch das Development Team umzusetzen sind. Es entsteht durch das Commitment des Development Teams – die committeten Stories bilden das Sprint Backlog. Die User Stories werden in Tasks heruntergebrochen, sodass eine User Story Unteraufgaben hat. Das Sprint Backlog wird eigenverantwortlich vom Development Team geführt. Die am höchsten priorisierten User Stories befinden sich i.d.R. absteigend im Sprint Backlog.

Im Sprint Planning I wird das „WAS“ des kommenden Sprints geplant. Der Product Owner stellt die am höchsten priorisierten User Stories dem Development Team vor. Im Sprint Planning I werden nur User Stories bearbeitet, die eine Schätzung in Story Points aufweisen. Das Development Team gibt an, wie viel sie im kommenden Sprint abarbeiten können.

Im Sprint Planning II wird das „WIE“ des kommenden Sprints geplant. Der Product Owner wird in diesem Termin nicht benötigt. Das Development Team erstellt zu jeder committeten User Story Tasks, die im kommenden Sprint bearbeitet werden müssen.

In der agilen Entwicklung wird in Story Points geschätzt. Doch was sind Story Points?
Story Points stellen eine Art Einheit für die Beschreibung der Komplexität einer Anforderung dar. Story Points sind immer relativ zu betrachten und beschleunigen den Schätzprozess von neuen Anforderungen.

Tasks sind alle Aufgaben, die zur Erfüllung einer User Story anfallen. Eine User Story
besteht aus mehreren Tasks.

Das Taskboard ist eine Auflistung der noch offenen, gerade bearbeiteten und abgeschlossen Aufgaben eines Sprints.

Wir empfehlen mit einem analogen Taskboard zu starten: ein Board auf einem Brownpaper oder einem großen Whiteboard. So ist das Board für das Team immer transparent und im Raum sichtbar. Post-its können berührt und verschoben werden und bieten ein haptisches Erlebnis. Dadurch fördert das Taskboard die Identifikation des gesamten agilen Teams mit dem aktuellen Sprint Scope und führt zu einer insgesamt höheren Transparenz.

Welche Informationen sollte ein Taskboard abbilden?

• User Stories
• Open Tasks
• In Work Tasks
• In Review Tasks
• Done Taks
• Impediments

Die Anordnung der User Stories und auch die der einzelnen Tasks sollten nach Priorität absteigend stattfinden.

User Stories sind Kundenanforderungen, die in einer Geschichte transportiert werden. Sie stellen einen ersten Schritt zur Festlegung des Funktionsumfangs dar. Sie sollten kurz und prägnant sein und jede User Story muss einen Nutzen aufweisen. Warum sollte sie sonst entwickelt werden?

Ich als Anwendertyp, möchte folgende Funktion, um dieses Ziel/diesen Nutzen zu erreichen. Eine User Story ist „ready for sprint“, wenn die Definition of Ready eingehalten wurde, sowie Story Points, Akzeptanzkriterien, Beschreibungen und Abhängigkeiten definiert sind.

Ein Anhaltspunkt um gute User Stories zu verfassen, stellen die INVEST-Kriterien dar:

• Independent – User Stories sollten nicht von anderen Stories abhängig sein
• Negotiable – User Stories sollten immer Raum für Änderungen geben
• Valuable – User Stories sollten einen Nutzen aufweisen
• Estimable – User Stories sollten vom Development Team schätzbar sein
• Small – User Stories sollten kurz gehalten werden
• Testable – User Stories sollten testbar sein