Scrum - Einführung - Wo in Basel? - Management - Scrum - Empirische Verbesserung

Product Owner

Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts zuständig. Er gestaltet das Produkt mit dem Ziel, den wirtschaftlichen Nutzen für das eigene Unternehmen zu optimieren.

Er erstellt, priorisiert und erläutert die zu entwickelnden Produkteigenschaften, und er urteilt darüber, welche Eigenschaften am Ende eines Sprints fertiggestellt wurden. Er ist eine Person, kein Komitee.

Ihm allein obliegt die Entscheidung über das Produkt, seine Eigenschaften und die Reihenfolge der Implementierung. So balanciert er Eigenschaften, Auslieferungszeitpunkte und Kosten.

Zur Festlegung der Produkteigenschaften verwendet der Product Owner das Product Backlog. Darin trägt er in Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern die Anforderungen an das Produkt ein.

Der Product Owner ordnet, detailliert und aktualisiert das Product Backlog regelmäßig im Product Backlog Refinement.

Als Produktverantwortlicher hält der Product Owner regelmäßig Rücksprache mit den Stakeholdern, um deren Bedürfnisse und Wünsche zu verstehen. Dabei muss er die Interessen und Anforderungen unterschiedlicher Stakeholder verstehen und abwägen.

Entwicklungsteam

Das Entwicklungsteam ist für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Zudem trägt es die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards.

Das Entwicklungsteam organisiert sich selbst. Es lässt sich von niemandem, auch nicht vom Scrum Master, vorschreiben, wie es Backlogeinträge umzusetzen hat.

Ein Entwicklungsteam sollte in der Lage sein, das Ziel eines jeweiligen Sprints ohne größere äußere Abhängigkeiten umzusetzen. Deshalb ist eine interdisziplinäre Besetzung des Entwicklungsteams wichtig, z. B. mit Architekt, Entwickler, Tester, Dokumentationsexperte und Datenbankexperte.

Gute und schlechte Ergebnisse werden nie auf einzelne Teammitglieder, sondern immer auf das Entwicklungsteam als Einheit zurückgeführt. Das ideale Teammitglied ist sowohl Spezialist als auch Generalist, damit es Teamkollegen beim Erreichen des gemeinsamen Ziels unterstützen kann.

Zu den weiteren Aufgaben eines Entwicklungsteams zählt die Schätzung des Umfangs der Einträge im Product Backlog (im Product Backlog Refinement).

Außerdem bricht das Entwicklungsteam in der Sprint Planung die für einen Sprint ausgewählten Einträge aus dem Product Backlog in Arbeitsschritte, sogenannte Tasks, herunter, deren Bearbeitung in der Regel nicht länger als einen Tag dauert. Das Ergebnis ist das Sprint Backlog.

Scrum Master

Dazu arbeitet er mit dem Entwicklungsteam zusammen, gehört aber selbst meist nicht dazu. Er führt die Scrum-Regeln ein, überprüft deren Einhaltung und kümmert sich um die Behebung von Störungen und Hindernissen.

Dazu gehören mangelnde Kommunikation und Zusammenarbeit sowie persönliche Konflikte im Entwicklungsteam, Störungen in der Zusammenarbeit zwischen Product Owner und Entwicklungsteam sowie Störungen von außen, beispielsweise Aufforderungen der Fachabteilung zur Bearbeitung zusätzlicher Aufgaben während eines Sprints.

Er gibt einzelnen Team-Mitgliedern keine Arbeitsanweisungen. Weder beurteilt er sie, noch belangt er sie disziplinarisch.

Der Scrum Master ist als Coach für den Prozess und die Beseitigung von Hindernissen verantwortlich. Unterschiedliche Teams und Situationen erfordern vom Scrum Master ein situatives Führen.

Zu Beginn einer Scrum-Implementierung ist der Scrum Master eine Vollzeitstelle, da die Umstellung der Abläufe, das Zusammenwachsen des Teams und das Einlernen der Rollen meist aufwändig sind. Er bildet das Team in Scrum aus. Ist Scrum erst einmal etabliert, kann der Scrum Master seine Rolle als Change-Manager wahrnehmen. Er hat dann die Zeit und auch die nötige Erfahrung, um Scrum im Unternehmen bekannt zu machen und dessen Akzeptanz zu steigern.

Stakeholder

Stakeholder sind Rollen außerhalb von Scrum. Die folgenden Rollen können helfen, die unterschiedlichen Stakeholder und deren Aufgaben zu differenzieren.

Kunden

Dem oder den Kunden wird das Produkt nach Fertigstellung zur Verfügung gestellt. Kunden können je nach Situation sowohl interne Fachabteilungen als auch externe Personen oder Gruppen sein.

Es ist Aufgabe des Product Owners, seine Kunden durch Lieferung des Wunschproduktes zu begeistern.

Deshalb sollten Product Owner und Kunden für die Dauer des Projektes im engen Austausch stehen.

Vor Beginn der Entwicklung sollte der Product Owner ein möglichst genaues Verständnis von der Wunschvorstellung seiner Kunden gewinnen. Die Kunden sollten schon nach den ersten Sprints Gelegenheit haben, sich die neuen Funktionalitäten anzuschauen und hierzu Feedback zu geben.

Anwender

Anwender sind diejenigen Personen, die das Produkt benutzen.

Ein Anwender kann, muss aber nicht zugleich Kunde sein. Die Rolle des Anwenders ist für das Scrum Team von besonderer Bedeutung, denn nur der Anwender kann das Produkt aus der Perspektive des Nutzers beurteilen.

Anwender und Kunden sollten beim Sprint Review und beim Product Backlog Refinement hinzugezogen werden, um das Produkt zu erproben und Feedback zu geben.

Der Scrum-Prozess

Sprint Planning

Im Sprint Planning werden zwei Fragen beantwortet:

• Was kann im kommenden Sprint entwickelt werden?
• Wie wird die Arbeit im kommenden Sprint erledigt?

Die Sprint-Planung wird daher häufig in zwei Teile geteilt. Sie dauert in Summe maximal 2 Stunden je Sprint-Woche, beispielsweise maximal acht Stunden für einen 4-Wochen-Sprint.

Der Product Owner stellt dem Entwicklungsteam die im Product Backlog festgehaltenen Produkteigenschaften in der zuvor priorisierten Reihenfolge vor.

Das Product Backlog sollte im Sprint zuvor im Product Backlog Refinement so weit vorbereitet worden sein, dass es geordnet, gefüllt und die Einträge für den nächsten Sprint geschätzt sind.

Das gesamte Scrum Team arbeitet im ersten Teil der Planung daran, ein gemeinsames Verständnis für die im Sprint zu erledigende Arbeit zu entwickeln.

Dabei werden die Eigenschaften und die Akzeptanzkriterien besprochen, beispielsweise die Gebrauchstauglichkeit. Außerdem einigt sich der Product Owner mit dem Entwicklungsteam auf die Kriterien, die am Ende des Sprints darüber entscheiden, ob die neue Funktionalität fertig ist oder nicht - siehe Definition of Done.

Ziel ist die Fertigstellung eines auslieferbaren Produkts: ein Produktinkrement, das hinreichend getestet und integriert ist, um für den Benutzer freigegeben werden zu können.

Anschließend prognostiziert das Entwicklungsteam die Anzahl der Product-Backlog-Einträge, die es im nächsten Sprint liefern kann.

Die Entscheidung, wie viele Einträge im nächsten Sprint umgesetzt werden, liegt alleine beim Team, während die Entscheidung über die Reihenfolge alleine beim Product Owner liegt.

Deshalb müssen beide konstruktiv zusammenarbeiten. Aus den ausgewählten Product-Backlog-Einträgen formuliert das Scrum Team gemeinsam ein Sprintziel.

Im zweiten Teil der Sprint Planung plant das Entwicklungsteam im Detail, welche Aufgaben (Tasks) zum Erreichen des Sprintziels und zur Lieferung der prognostizierten Product-Backlog-Einträge notwendig sind.

Diese Planung macht das Entwicklungsteam, wobei der Product Owner für Fragen in Reichweite sein sollte.

Oftmals bilden sich zur Beantwortung der Wie-Frage Kleingruppen, in denen verschiedene Aspekte wie z. B. Architektur, Datenelemente und Schnittstellen geklärt werden.

Ergebnis ist das Sprint Backlog: der detaillierte Plan für den nächsten Sprint. Er enthält die für den Sprint geplanten Product-Backlog-Einträge und die Aufgaben zu deren Umsetzung. Häufig wird dafür ein Taskboard als Technik verwendet.

Daily Scrum

Zu Beginn eines jeden Arbeitstages trifft sich das Entwicklerteam zu einem max. 15-minütigen Daily Scrum, bei dem Scrum Master und Product Owner häufig anwesend, jedoch nicht aktiv beteiligt sind, falls sie nicht selbst Backlogelemente bearbeiten.

Zweck des Daily Scrum ist der Informationsaustausch.

Im Daily Scrum werden keine Probleme gelöst – vielmehr geht es darum, sich einen Überblick über den aktuellen Stand der Arbeit zu verschaffen. Dazu hat sich bewährt, dass jedes Teammitglied mit Hilfe des Taskboards sagt, was es seit dem letzten Daily Scrum erreicht hat, was es bis zum nächsten Daily Scrum erreichen möchte, und was dabei im Weg steht.

Beim Daily Scrum kann offensichtlich werden, dass die Erledigung einer Aufgabe länger als geplant dauert. Dann ist es sinnvoll, den Task in kleinere Aufgaben aufzuteilen, die dann auch von anderen Mitgliedern des Entwicklungsteams übernommen werden können.

Treten beim Daily Scrum Fragen auf, die sich nicht innerhalb der strikten 15-Minuten-Vorgabe beantworten lassen, so werden sie entweder notiert und dem Scrum Master übergeben, oder ihre Beantwortung wird auf ein späteres Meeting, häufig direkt im Anschluss, verlegt.

Sprint Review

Das Sprint Review steht am Ende des Sprints.

Hier überprüft das Scrum Team das Inkrement, um das Product Backlog bei Bedarf anzupassen.

Das Scrum Team und die Stakeholder besprechen die Ergebnisse und was als Nächstes zu tun ist.

Im Sprint Review ist die Beteiligung von Kunden und Anwendern wichtig, da diese die fertige Funktionalität des Inkrements benutzen und validieren können.

Hieraus ergibt sich wichtiges Feedback für die weitere Produktgestaltung. Es kann sogar passieren, dass die Funktionalität alle Abnahmekriterien erfüllt und dennoch aus der Perspektive des Benutzers unbrauchbar ist, beispielsweise wenn ein Button an einer schwer auffindbaren Stelle platziert wurde. Häufig entsteht während des Reviews ein lebhafter Dialog, in dem den Anwesenden neue Funktionalitäten einfallen.

Das Ergebnis des Sprint Review ist das vom Product Owner notierte Feedback der Stakeholder. Dies ist eine notwendige Information bei der weiteren Gestaltung des Product Backlogs im nächsten Product Backlog Refinement.

Anhand der im Sprint Planning 1 festgelegten Bedingungen entscheidet er, ob sie abgenommen werden können oder nicht.

Dabei soll er keine Kompromisse eingehen: Ein Team hat auch dann sein Ziel verfehlt, wenn es eine „fast fertige“, aber noch nicht getestete Funktionalität liefert. In diesem Fall kehren die nicht fertiggestellten User Stories in das Product Backlog zurück und werden vom Product Owner neu priorisiert.

Die Abnahme ist aber nicht primärer Gegenstand vom Sprint Review, bei dem es vorrangig um das Feedback der Stakeholder geht.

Die Abnahme der Funktionalitäten des Produktinkrements wird daher häufig im Rahmen des Sprints umgesetzt.

Sprint Retrospektive

Die Sprint Retrospektive steht am Ende eines Sprints.

Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen.

Der Scrum Master unterstützt das Scrum Team darin, gute Praktiken und Verbesserungen zu finden, die im nächsten Sprint umgesetzt werden. Die Retrospektive ist eine gemeinsame Aktivität des Scrum Teams.

Das Team soll seine Arbeitsweise offen und ehrlich überprüfen können. Dazu müssen Kritik und unangenehme Wahrheiten offen geäußert werden können. Das schließt auch Gefühle und Empfindungen ein.

Die Retrospektive soll daher in einem geschützten Raum ablaufen. Stakeholder dürfen nur auf Einladung dazukommen. Als Struktur für die Sprint-Retrospektive haben sich fünf Phasen bewährt.

Die Verbesserungsmaßnahmen werden dokumentiert und geplant. Hierfür gibt es unterschiedliche Techniken. Einige Teams nutzen eine eigene Liste mit Hindernissen und Verbesserungsmaßnahmen (das Impediment Backlog), andere Teams nehmen Hindernisse und die entsprechenden Aktivitäten in das Sprint Backlog auf.

Die Sprint-Retrospektive dauert maximal 45 min je Sprint-Woche, also max. drei Stunden für einen 4-Wochen-Sprint.

Product Backlog Refinement

Das Product Backlog Refinement (auch Backlog Grooming genannt) ist ein fortlaufender Prozess, bei dem der Product Owner und das Entwicklungsteam gemeinsam das Product Backlog weiterentwickeln. Hierzu gehören:

• Ordnen der Einträge
• Löschen von Einträgen, die nicht mehr wichtig sind
• Hinzufügen von neuen Einträgen
• Detaillieren von Einträgen
• Zusammenfassen von Einträgen
• Schätzen von Einträgen
• Planung von Releases

Für die Gestaltung des Produkts und des Product Backlogs können Stakeholder wertvolle Informationen liefern, indem sie dem Scrum Team erklären, wie sie sich eine Funktionalität im alltäglichen Gebrauch wünschen. Daher gibt es meistens auch Product-Backlog-Refinement-Treffen zusammen mit ausgewählten Stakeholdern.

User Story

In Scrum werden User Stories zur Formulierung der Product Backlog-Einträge verwendet. Eine User Story beschreibt, welche Produkteigenschaft der Benutzer will und warum.

User Stories folgen im Allgemeinen diesem Muster: Als NUTZER will ich FUNKTION oder EIGENSCHAFT, damit NUTZEN.

Bei einem Projekt zur Entwicklung eines städtetauglichen Elektrofahrrads könnte eine User Story demnach folgendermaßen lauten:
Als 30-jährige Geschäftsfrau möchte ich auf dem Weg zur Arbeit nur wenig in die Pedale treten müssen, damit ich nicht verschwitzt in der Firma ankomme.

Es ist Aufgabe des Product Owners und des Teams, im Product Backlog Refinement zu klären, was genau damit gemeint ist, und welches die Akzeptanzkriterien sein sollen.

So könnte zum Beispiel vereinbart werden, dass bis zu einer Steigung von maximal 20 % der elektrische Antrieb so stark sein muss, dass die Fahrerin nicht mehr als 50 Watt durch eigenes Treten beisteuern muss.

Zudem muss das Entwicklungsteam mit dem Product Owner klären, ob sich diese User Story überhaupt in einem Sprint erledigen lässt oder ob sie in kleinere Storys heruntergebrochen werden muss.

Sobald eine User Story umgeschrieben oder um weitere Information ergänzt wird, werden auch diese Änderungen im Product Backlog festgehalten.

Fragen nach dem Wie, also nach der technischen Umsetzung einer User Story, gehören ins Sprint Planning und werden nicht im Product Backlog, sondern im Taskboard mit Hilfe der einzelnen Tasks festgehalten.

Taskboard

Das Taskboard ist eine Technik zur Visualisierung des Sprint Backlogs. Darauf lässt sich jederzeit erkennen, welche Product Backlog Einträge für den Sprint ausgewählt wurden, welche Aufgaben dazu zu bearbeiten sind, und in welchem Bearbeitungszustand diese Aufgaben sind.

Typischerweise besteht das Taskboard aus vier Spalten.

In der ersten Spalte Anforderungen werden die Product Backlog Einträge eingetragen, die das Entwicklungsteam für diesen Sprint ausgewählt hat – in der vom Product Owner priorisierten Reihenfolge.

Die drei weiteren Spalten enthalten die Aufgaben oder Tasks, die zur Umsetzung der jeweiligen Anforderung notwendig sind, in ihrem jeweiligen Bearbeitungszustand.

Die zweite Spalte enthält alle noch zu erledigenden Aufgaben, die dritte Spalte diejenigen in Bearbeitung und die vierte Spalte alle erledigten.

Im Daily Scrum erklärt jedes Mitglied des Entwicklungsteams anhand des Taskboards, an welcher Aufgabe es am Vortag gearbeitet hat, und ob diese erledigt wurde.

Tasks, die an einem Tag nicht beendet werden konnten oder bei denen Hindernisse den Fortschritt aufhalten, werden markiert. In diesem Fall sollten die Aufgaben zur Beseitigung des Hindernisses in das Taskboard aufgenommen werden. So können Hindernisse schnell identifiziert und die Beseitigungsmaßnahmen transparent gemacht werden.

Planungspoker

Scrum schreibt keine spezifische Methode vor, Aufwände abzuschätzen. Bei einer guten Schätzmethode sollten die Beteiligten zunächst unbeeinflusst von den anderen Teilnehmern schätzen.

Andererseits sollte die Methode in annehmbarer Zeit zu einem akzeptierten und validen Ergebnis führen. Seit ca. 2005 ist Planungspoker eine gängige Methode in Scrum und generell in agilen Projekten.
Übrigens: Die englische Bezeichnung "Planning Poker" ist eine geschützte Warenbezeichnung der Firma Mountain Goat Software.

Jeder Teilnehmer erhält einen Satz Spielkarten. Diese sind mit Schwierigkeitsgraden oder Story Points bedruckt, beispielsweise in der Systematik:
trivial – leicht – mittel – schwer – sehr schwer – überschwer
1, 2, 3, 5, 8, 13, 21, ... Diese Fibonacci-Zahlenfolge wird häufig gewählt, um der zunehmenden Unsicherheit in der Schätzung schwererer Aufgaben gerecht zu werden.

Das Planungsspiel läuft folgendermaßen:

1. Der Product Owner stellt die User Story vor, die es zu schätzen gilt.
2. Das Team klärt in der Diskussion mit dem Product Owner seine Fragen zu der Story.
3. Jedes Teammitglied wählt für sich eine Karte, die seiner Ansicht nach der Schwierigkeit der Story entspricht.
4. Alle gewählten Karten werden gleichzeitig aufgedeckt.
5. Die Teilnehmer mit der niedrigsten und der höchsten Schätzung erklären ihre Beweggründe.
6. Der Prozess wird wiederholt, bis ein Konsens gefunden ist.
7. Das Spiel wird wiederholt, bis alle User Stories geschätzt sind.

Bei einer größeren Zahl von User Stories ist es zweckmäßig, eine Zeitvorgabe pro Story zu vereinbaren, und diese jeweils mit einer Sanduhr oder Stoppuhr zu überwachen.

Ist die Zeit abgelaufen, ohne dass die Story geschätzt werden konnte, so ist das ein Indiz dafür, dass die Beschreibung nicht gut verständlich ist und neu verfasst werden sollte.

Impediment Backlog

Das Impediment Backlog ist eine Technik, mit welcher der Scrum Master öffentlich alle Arbeitsbehinderungen sammelt. Es handelt sich um eine Liste von Hindernissen, Aufgaben zu ihrer Lösung und ihrem aktuellen Status.

Eine andere Technik ist es, Behinderungen und die Beseitigungsmaßnahmen auf dem Taskboard mit zu pflegen.

Burn-Down-Chart

Das Burn-Down-Chart dient der Visualisierung bereits geleisteter und noch verbleibender Arbeit. Das Burn-Down-Chart gibt es in zwei Varianten:

• Als Sprint Burndown wird es zur Verfolgung vom Sprintfortschritt verwendet.
• Als Release Burndown wird es zur Verfolgung vom Produktfortschritt über mehrere Sprints hinweg verwendet.

Beim Sprint Burndown wird auf der x-Achse der Zeitverlauf in Tagen und auf der y-Achse die Anzahl der noch zu erledigenden Tasks aufgetragen.

So ergibt sich eine Linie von offenen Aufgaben, die im Idealfall am Sprintende die Nulllinie trifft. Über das Sprint Burndown ist es möglich, die Erreichung des Sprint-Ziels besser abzuschätzen.

Das Entwicklungsteam aktualisiert im Daily Scrum das Sprint Burndown.

Alternativ können beim Sprint Burndown statt der Anzahl der Tasks auch die Summe der geschätzten Aufwände für jeden einzelnen Task eingetragen werden. Dies erfordert jedoch eine Schätzung der Restaufwände für alle Tasks, so dass diese Variante mehr Aufwand erfordert.

Da die Genauigkeit bei Tasks mit einem Aufwand von maximal einem Tag nur geringfügig besser wird, hat sich das Zählen der Tasks bei vielen Teams durchgesetzt.

Beim Release Burndown wird auf der x-Achse der Zeitverlauf in Sprints und auf der y-Achse die Anzahl der noch zu erledigenden Product-Backlog-Einträge aufgetragen, beispielsweise in Story Points. Ändert sich der Umfang des Product Backlog, so wird dies unterhalb der x-Achse eingetragen.

Bei jedem Sprint aktualisiert der Product Owner das Release Burndown.

Mit Hilfe des Release Burndown kann der Product Owner Umfang und Liefertermin des aktuellen Releases bestimmen.

Keine Erfolgsgarantie

Scrum kann genau so wenig wie andere Prozesse und Vorgehensmodelle eine Erfolgsgarantie bieten.

Verwertung gewonnener Erkenntnisse

Bei der Verwendung von Scrum muss man sich darauf einstellen, dass die ursprünglichen Einschätzungen permanent über- oder untertroffen werden.

Scrum zeigt vom ersten Tag an Abweichungen vom Soll-Zustand an. Ob Scrum dazu führt, dass Produkte schnell, gut, günstig oder qualitativ hochwertig entwickelt werden, hängt davon ab, was das Scrum-Team mit den gewonnenen Erkenntnissen macht.

Rollenkonflikte

Die Selbstorganisation im Entwicklungsteam impliziert, dass Hierarchien in Frage gestellt werden.

Mitglieder, die nicht bereit sind, ihre bisherige Position innerhalb des Entwicklungsteams aufzugeben, können daher Konflikte erzeugen.

Scrum fordert, dass alle Teammitglieder vielfältige Aufgaben eines Sprints bearbeiten können. Jemand, der sich exklusiv als Tester, Programmierer oder Architekt sieht, passt nicht optimal in ein Entwicklungsteam nach Scrum.

Ein gutes Team kann das berücksichtigen und die Nachteile kompensieren; für ein weniger erfahrenes Team können solche Mitarbeiter schwierig sein.

Juristische Erwägungen

Im Rahmen von Werkverträgen und vor dem Hintergrund des Produkthaftungsgesetzes kann die Anwendung von Scrum begrenzt sein. Es besteht eine stärkere Unschärfe über die zu erbringende Leistung und deren Abnahmekriterien als bei traditionellen Vorgehensweisen. Bei Streitigkeiten kann dies dazu führen, dass keine eindeutige Aussage zur Vertragserfüllung getroffen werden kann.

In der Fachliteratur werden Vorschläge angeboten, wie Werkverträge für Scrum-Projekte zu gestalten sind.