AGIL VON A BIS Z

Als Agiler Coach sind wir kein aktiver Bestandteil des Development Teams. Wir sind eine Unterstützung, Sparrings-Partner und geben Ihnen neue Impulse für Ihre agile Vorgehensweise. Auszüge aus den Aufgaben von unseren 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 dafür 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 ajouriert. So entsteht eine Übersicht der verbleibenden Restaufwände für die verbleibende Sprintdauert sowie der bereits abgeschlossenen Aufgaben. Wir empfehlen Ihnen bei neu formierten Teams, welche wenig Erfahrung bzgl des agilen Prozesses 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 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 shipable increment.
Das Development Team arbeitet selbstorganisiert, es hat alle Fähigkeiten um ein potenial shipable increment zu entwickeln und arbeitet auf Augenhöhe – es gibt keine Hierarchien innerhalb des Teams.

Eine Definiton of Ready ist eine Definition, welche definiert 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 Defintion of Ready obliegt dem Product Owner.

Eine Definiton of Done ist eine Einigung, welche vom Development Team definiert wird, 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 Defintion of Done obliegt dem Development Team.

Epics verwendet der Product Owner um dem Development Team eine (neue) Produktanforderung, die größer als eine User Story ist und i.d.R. aus mehreren User Stories besteht, darzustellen. 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 weitere User Stories definiert werden in denen die Detaillierung deutlich zunimmt.

Das Impediment Backlog wird vom Scrum Master geführt und bearbeitet. Es beinhaltet alle Impediments welche das Development Team bei der Arbeit behindern, wenn Sie es nicht selbst lösen können. Man kann hier zwischen internen, vom Team selbst lösbaren, und externen, vom Team nicht mehrbehebbaren Impediments unterscheiden.

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, so dass 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 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. Er 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. .

Unseren Inhalt lesen Sie in kürze.

In den Review Meetings präsentiert das Development Team den Stakeholdern die entwickelte Arbeit des letzten Sprints. Des Weiteren erklärt der Product Owner die umgesetzten User Stories und gibt einen Ausblick auf die kommenden Sprintaktivitäten.
Es werden nur „potenial shipable increments“ präsentiert – also nur abgeschlossene Arbeitsergebnisse des Development Teams.
Das Review Meeting dient nicht der Abnahme der User Stories, dies geschieht optimaler Weise im Vorfeld durch den Product Owner – Die Stakeholder können die zukünftige Entwicklung mit Ihrem Feedback zu den Produkt Inkrementen 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 keine 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, dafür, 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, so dass eine User Story Unteraufgaben hat. Es 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öchten priorisierten User Stories dem Development Team vor. Es werden nur User Stories, welche eine Schätzung in Story Points aufweisen, in einem Sprint Planning I bearbeitet. 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 User Story, welche committed ist, Tasks, die im kommenden Sprint bearbeitet werden müssen.

In der agilen Entwicklung wird in Story Points geschätzt – doch was sind Story Points? Im Endeffekt stellen Story Point 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 nichts anderes als eine Auflistung der noch offenen, gerade
bearbeiteten und abgeschlossen Aufgaben eines Sprints.
Wir empfehlen Ihnen mit einem analogen Taskboard zu starten – ein Board auf einem Brownpaper oder großen Whiteboard. Es hat einen anderen Einfluss auf das Development Team, wenn das Board immer transparent und sichtbar im jeweiligen Raum zu sehen ist. Es ist ein haptisches Erlebnis, wenn Post-It´s berührt und verschoben werden, welches zur Förderung der Identifikation des gesamten agilen Teams mit dem aktuellen Sprintscope und zu einer insg. höheren Transparenz führt.
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 – denn warum sollte Sie sonst entwickelt werden?
Ich als (Anwedertyp), möchte ich (folgende Funktion), um (dieses Ziel/Nutzen zu erreichen).
Eine User Story ist „ready for sprint“, wenn die Definition of Ready eingehalten wurde, 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 müssen einen Nutzen aufweisen
• Estimable – User Stories müssen vom Development Team schätzbar sein
• Small – User Stories müssen kurzgehalten werden
• Testable – User Stories müssen testbar sein