Warum erreicht das Team das Sprintziel nicht?

Diese Frage stellte mir ein befreundeter Scrum Master vor kurzem. Das Problem war, dass sein Team Sprint für Sprint die vereinbarten Sprint-Ziele nicht erreichte. Eine Frage, die jedoch nicht so einfach zu beantworten ist, denn die Ursachen können zahlreich sein und um zu einer Aussage zu kommen, muss zunächst der gesamte Scrum-Prozess und Entwicklungsprozess analysiert werden.

Wie sollte nun vorgegangen werden?

Zunächst sollte der Scrum-Master oder noch besser ein externer Scrum-Master das Team einen Sprint lange begleiten, beobachten und folgende Fragen beantworten:

• Lebt das Team die Scrum-Werte?
• Herrscht Klarheit über die Anforderungen in den Backlog-Items?
• Wie werden die Anforderungen in den Backlog-Items geschätzt?
• Wie plant das Team im Detail?
• Wie plant das Team den Sprint?
• Wie kommuniziert das Team?
• Wie lernt das Team aus Fehlern?
• Auf welche Arbeiten legt das Team Wert?

Sind all diese Fragen beantwortet, so können die Antworten ausgewertet und beurteilt werden und im Schlechtfall Gegenmaßnahmen ergriffen werden. Die folgenden Abschnitte beschäftigen sich mit diesen Gegenmaßnahmen.

Lebt das Team die Scrum-Werte?

Es gibt 5 Scrum-Werte

1. Courage
2. Respekt
3. Fokus
4. Offenheit
5. Committment

Wenn das Team die Scrum-Werte nicht lebt und beispielsweise nicht das Committment mitbringt, welches es braucht, um seine Sprintziele zu erreichen so ist dies katastrophal. Scrum und agile Umsetzungsmethoden legen viel Vertrauen in das Team. Dieses Vertrauen wird bei agilen Methoden im Vorschuss gegeben, das Team muss sich diesen Vorschuss aber erhalten. Sollte ein Teammitglied die Situation ausnutzen und nicht hinter dem Sprintziel stehen, so ist es auch nicht verwunderlich, dass dieses auch nicht erreicht wird. Auch der respektvolle Umgang miteinander sollte ein no-Brainer sein. Gibt es Spannungen im Team führt dies unweigerlich zu Reibungsverlusten und es ist nicht verwunderlich, dass das Team seine Ziele nicht erreicht. Gerade Scrum setzt voraus, dass Leistungen im Team erbracht und gewertet werden. Es müssen alle an einem Strang ziehen. Fehlt es an Offenheit und Courage, so können eigentlich bekannte Probleme nicht adressiert werden und somit auch nicht gemeinsam verbessert werden. Eine nicht ideale Situation. Einer der am wenigsten offensichtlichen Verhinderer aber bei den Werten ist Fokus. Hier tappen immer wieder „junge“ Scrumteams in die Falle. Das Team setzt der Reihe nach Features um und schließt diese ab. Es bleibt jedoch aus, im Sprint-Review die Umgesetzte Funktionalität wirklich zu begutachten und Testen. Schnell schnell wird das nächste Feature angegangen. Mit der Folge, dass technische Schulden und ggf. Funktionalitäten nicht fertig werden und nach einigen Sprints das Team wieder einholt. Es ist essentiell, dass sich das ganze Scrum-Team auf einzelne Feature und Sprintziele fokussiert und diese solange bearbeitet bis diese fertig sind. Erst dann, wenn das Produktinkrement in diesem Bereich „fertig“ ist kann das nächste Thema begonnen werden.

Herrscht Klarheit über die Anforderungen in den Backlog-Items?

Kennen Sie diese Situation. Das Team beginnt mit der Umsetzung eines Backlog Items. Es ist sowieso alles gesagt und fünf oder sechs Stichworte wurden zum Backlog-Item erfasst. Bei der Umsetzung kommt das Team aber immer wieder nach ein paar Minuten oder Stunden drauf, dass doch Informationen fehlen.

Die Folge dieses Verhaltens sind verehrend. Sind die Anforderungen nicht lückenlos dokumentiert, und unmissverständlich so kann es leicht passieren, dass nicht das herauskommt was „e von Anfang an klar war“.

Um nicht in diese Probleme zu laufen werden in Scrum-Teams heutzutage eine Definition of Ready (DoR) und Refinement-Meetings eingesetzt. Die Definition of Ready ist ein Regelwerk, oder ein Vertrag zwischen dem Umsetzungsteam und dem Product-Owner. Es können nur Product-Backlog-Items in die Sprintplanung aufgenommen werden, welche die DoR erfüllen. Ein wichtiger Bestandteil den die DoR hier regelt ist, in welcher Form und welcher Qualität die Anforderungen erfasst werden müssen, damit jedes Team-Mitglied die Aufgabe verstehen kann, im Refinement und beim Planning-Poker mit Story-Points schätzen, und in der Sprintplanung einplanen und sich auf die Umsetzung committen kann. Oft hat der Product-Owner nicht die Kompetenzen oder das Knowhow die Anforderungen in der Art und Weise zu erfassen, dass das Team ein einheitliches Verständnis für die Aufgabe entwickeln kann. In diesem Fall ist es Ratsam einen Requirements Engineer dem Product-Owner zur Seite zu stellen, der ihm hilft die Anforderungen in entsprechender Form zu erfassen.

Wie werden die Anforderungen in den Backlog-Items geschätzt?

Die Planung und die Erwartungshaltung, die sich mit dieser Planung ergibt, basiert auf Schätzungen. Auch wenn wir uns bei agilen Projekten, die wir mit Scrum umsetzen die Möglichkeit offen halten nach jedem Sprint einen Richtungswechsel durchführen zu können, werden Sprints an sich geplant und Sprintziele formuliert. Damit diese Planung auch durchgeführt werden kann, werden haltbare Schätzungen benötigt. Bei Scrum hat sich dabei eine Schätzung mit Hilfe von Story-Points als am besten geeignet herausgestellt. Viele gerade unerfahrene Scrum-Teams machen hier aber oft den Fehler Schätzungen auf die leichte Schulter zu nehmen. Auch wenn wir mit Story-Points und nicht mit Stunden schätzen sollen Schätzungen möglichst gut, genau und allumfassend gemacht werden. Beim Schätzen mit Story-Points schätzen wir das WAS und nicht das WIE. Was ist zu tun? Was wünscht sich der Product-Owner. Dabei beschreiben Story-Points den Entwicklungsaufwand unter Berücksichtigung von verschiedenen Einflussfaktoren auf diesen Aufwand wie:

• Die Komplexität des gewünschten Features und seiner Umsetzung
• Die Menge der zu erledigenden Aufgaben die nötig sind um das Feature umzusetzen.
• Ungewissheiten und Unsicherheiten die bei der Umsetzung des Features auftreten können
• Das technische Risiko welches bei der Umsetzung des Features vorhanden ist durch z.B. Einsatz neuer unerprobter Technologien, oder Abhängigkeiten von Drittkomponenten

Dabei werden Story Points nicht in einer standardisierten Einheit wie Stunden geschätzt, sondern immer in Relation zu Referenz-Features/ Referenz-Product-Backlog-Items. Story-Points sind somit eine variable nicht allgemein standardisierte Einheit.

Aus der Ferne betrachtet ist es schwierig zu sagen wie viele Meter ein Baum hat. Man kann aber den Baum in Relation mit einem Menschen daneben betrachten und erkennen, dass der Baum 5-mal größer ist als der Mensch. Durch Abmessen des Menschen kann dann später die Schätzhöhe in Meter auch bestimmt werden, wenn dies nötig sein sollte. Zum Einordnen und damit sich der Betrachter ein Bild machen kann ist dies aber nicht nötig.

Genauso ist es mit Story-Points. Diese sind in erster Linie für den PO und das Team wichtig, um die Features einordnen zu können. Der PO kann aufgrund der Schätzung der PBIs in Story-Points und des Business-Values entscheiden ob der Kosten-Nutzenfaktor für dieses Feature gut genug ist und das Investment in die Umsetzung gerechtfertigt ist oder nicht. Das Team kann gemeinsam mit dem PO entscheiden ob es dieses PBI im Sprint-Planning in den Sprint zieht und ob sich die Umsetzung mit der bekannten Team-Velocity ausgeht oder nicht.

Damit diese Schätzung aber Solide ist müssen folgende Bedingungen gelten:

• Das Team berücksichtigt bei jeder Schätzung die Einflussfaktoren (Komplexität, Menge der Aufgaben, Ungewissheiten, Risiken)
• Das Team verwendet eines oder mehrere Referenz-PBIs mit denen es das zu schätzende PBI in Kontext setzt und abgleicht.
• Diese Referenz-PBIs ändern sich über im Laufe des Projekts NICHT.
• Das Team berücksichtigt Lernerfahrungen aus vergangen Sprints und lässt diese mit in die Schätzungen mit einfließen.
• Das Team hat selbst den Ehrgeiz möglichst gute Schätzungen abzugeben und sich ständig zu verbessern
• Das Team Arbeit gemeinsam an einer Schätzung und pflegt eine gute Kommunikationskultur während dieser Schätzungen.
• Alle Teammitglieder beteiligen sich an der Schätzung und bringen Ideen und Vorschläge ein

Als Schätzmethode kann beispielsweise Planning-Poker verwendet werden.

Wie plant das Team im Detail?

Wie oben bereits beim Abschnitt Schätzungen angeschnitten ist die Planung eines Sprints nur dann gt möglich, wenn die Schätzungen solide gemacht wurden und einige Parameter bekannt sind. Neben dem vorhandenen, priorisierten und geschätzten Product-Backlog, müssen noch die Teamvelocity und die Team Capacity bekannt sein. In modernen Scrum-Teams findet das Planning auf zwei Ebenen statt. Im Sprint-Planning I wird das Sprintziel vordefiniert. Anhand der vorliegenden priorisierten und mit Story-Points geschätzten Backlogitems und mit Hilfe der bekannten Team-Velocity können der Reihe nach PBIs in den Sprint und das Sprint-Backlog gezogen werden, bis die Anzahl der Story-Points annähernd der Team-Velocity entspricht. Diese Planung basiert auf der Schätzung des WAS (Was ist zu tun) und nicht auf der Schätzung des WIE (Wie wollen wir das Feature umsetzen). Somit wird nach dem Sprint-Planning I das Sprint-Planning II abgehalten. Ein Sprint ist ein Micro-Projekt. Dieses Micro-Projekt beinhaltet alle Phasen eines Projekts – von der Planung über das Design und die Implementierung bis hin zum Deployment Stabilisierung und Testen. Um diese Detailplanung als die Umsetzungsplanung machen zu können, legt nun das Team zu jedem Product-Backlog-Item auch Umsetzungs-Tasks an. Diese Tasks beschreiben einzelne Arbeitsschritte, die all diese Schritte des Micro-Projekts berücksichtigen. Für jedes PBI wird ein Hauptverantwortlicher bestimmt, der die Implementierung dieses Features vorantreibt. Diese Tasks werden auf einzelne Teamkollegen grob aufgeteilt und mit Aufwandsstunden geschätzt. In der Kapazitätsplanung werden dann die vorhandenen Arbeitsstunden im Sprint mit den geplanten Arbeitsstunden verglichen. Somit können Situationen identifiziert werden, bei denen das Team oder einzelne Teammitglieder zu viele oder zu wenige geplante Tasks im Sprint haben. Aufgrund der Erkenntnisse im Planning II können dann noch ggf. PBIs in den Sprint nachgezogen werden oder aus dem Sprint herausgenommen werden.

Um Agilität zu gewährleisten und dennoch flexibel zu bleiben sollen die Planung im Planning II aber nicht als in Stein gemeißelt verstanden werden. Es können natürlich noch Tasks hinzugefügt werden oder wegfallen. Es kann auch sein, dass gewisse Tasks von einer Person zur Anderen wandern. Wichtig ist hierbei, dass das Team generell dafür eintritt das Sprintziel zu erreichen und sich gegenseitig unterstützt.

In der Praxis wird die Sprintplanung oft viel zu lax durchgeführt und das Planning II oft gar nicht oder on Demand während des Sprints durchgeführt. Dies führt dazu, dass Schätzfehler aufgrund der reinen WAS Betrachtung nicht oder viel zu spät auffallen.

Wie plant das Team den Sprint?

Wie oben bereits erwähnt sollte der Sprint als Micro-Projekt gesehen werden. Dieses Projekt durchlauft alle Phasen eines Projekts und sollte dementsprechend auch Pufferzeiten und Realistische Ressourcen-Planungen beinhalten. Oft kann in der Praxis beobachtet werden, dass Sprints bis zum Ende mit Entwicklungstätigkeiten ausgeplant sind und die Kapazität der Teammitglieder voll verplant ist – eine unrealistische Herangehensweise denn keiner ist zu 100 % am Tag produktiv und jedes Projekt braucht Buffer und Zeiten zum Testen und Stabilisieren. Die Kapazität der Teammitglieder sollte also nur zu maximal 80% berücksichtigt werden und pro Sprint sollten die letzten 20% zum Stabilisieren und Testen freigehalten werden. Dann klappt es auch besser mit den Sprintzielen.

Wie kommuniziert das Team?

Software-Entwicklung besteht immer zu 50% aus Kommunikation. Ein Software-Engineer muss sich mit dem Product-Owner zu den Features abstimmen und mit seinen Fachkollegen zu den einzelnen Umsetzungsschritten und allfälligen Wechselwirkungen reden können. So ist ein häufiger Fehler bei unerfahrenen Scrum-Teams, dass Abstimmungsmeetings wie Refinement-Meetings mit dem Product-Owner und Stand-ups innerhalb des Teams nicht richtig wahrgenommen werden. Stand-ups sind kein Reporting an den Product-Owner oder den Scrum-Master sondern dienen dazu, dass sich das Team untereinander abstimmen kann und diese Wechselwirkungen identifizieren kann.

Ein klares Regelset welches eingehalten werden muss, um gewisse Status zu kommunizieren sollte definiert werden. Die zwei wichtigsten Regelsets sind dabei die Definition of Ready und die Definition of Done.

Die Defintion of Ready sagt aus, wann eine User-Story oder ein PBI soweit ausspezifiziert, verstanden und mit Informationen angereichert ist, dass es im Sprint eingeplant werden kann. Dieses Regelset sollte einmal zu Beginn des Projekts grundlegend angelegt werden. Es ist quasi ein Vertrag zwischen dem PO und dem Umsetzungsteam welcher definiert wann ein PBI in den Status Committed übergeführt werden kann. Während dem Laufe des Projekts kann dieses Regelset natürlich auf veränderte Bedingungen angepasst werden. Die Konkrete existenz der Defintion of Read führt aber dazu, dass es keine Missverständnisse in der Kommunikation mehr gibt was „planbar“ ist und was nicht.

Die Definition of Done ist so wie die Definition of Read ein Regelwerk. In diesem Fall definiert die Definition of Ready aber die Bedingungen die vorherreschen müssen, damit ein Teammitglied kommunizieren darf, dass ein Feature „abgeschlossen“ und „fertig“ ist. Dies verhindert vor allem Konflikte und Missverständnisse wann ein Sprint bzw. die einzelnen Product-Backlog-Items im Sprint „fertig“ sind.

Wie lernt das Team aus Fehlern?

Gerade die Retrospektive ist ein extrem wichtiges Meeting und Tool im Scrum-Prozess, welches aber leider viel zu oft vernachlässigt wird. Die Retrospektive sollte keinesfalls eine gegenseitige Beweihräucherung sein. Oft werden in der Retrospektive nur positive Dinge angesprochen und negative Dinge aus Bequemlichkeitsgründen und der „Harmonie“ willen nicht angesprochen. Um dies zu verhindern sollten strukturierte Methoden in der Retrospektive angewendet werden wie beispielsweise die DAKI Methode.

Die DAKI-Methode

DAKI steht für Drop Add Keep Improve. Der Moderator schreibt die 4 Begriffe in vier Quadranten und jedes Teammitglied kann in alle diese Quadranten Themen oder Ereignisse des letzten Sprints eintragen, bzw. Vorschläge für den nächsten Sprint liefern.

Drop

In den Drop Quadranten kommen Themen und Ereignisse der vergangenen Sprints die das Team gemacht hat, aber nie wieder passieren sollten.

Add

In den Add-Quadranten kommen Themen und Vorschläge die wir in den vergangenen Sprint(s) nicht gemacht haben aber mal ausprobieren sollten. Also Verbesserungsvorschläge.

Keep

In diesem Quadranten ist Platz für Anerkennung und Lob. Hier sollen alle Themen gesammelt werden die gut laufen und weiterhin so betrieben werden sollen.

Improve

In den Improve-Quadranten werden alle Themen geschrieben, die das Team zwar betreibt, aber auf irgend eine Art und Weise optimiert werden müssen oder hinderlich laufen.

Nachdem alle Teammitglieder zu den Quadranten Themen und Vorschläge gesammelt haben, wird nun vom Moderator Punkt für Punkt das Team zur Diskussion aufgefordert. Nachdem Klarheit über die Inhalte herrscht, darf dann jedes Teammitglied Punkte vergeben. Zum Beispiel kann der Moderator alle Teammitglieder auffordern maximal 10 Punkte zu vergeben. Je nach Wichtigkeit darf Ein Teammitglied zwischen 0 und 10 Punkte für ein Thema vergeben. Wichtig dabei ist, dass jedes Teammitglied wirklich nur 10 Punkte insgesamt vergeben darf. Nach der Auswertung werden dann jene Themen ausgewählt die am meisten Punkte haben und dem Team somit am wichtigsten sind. Für diese Themen überlegt sich das Team konkrete Maßnahmen welche es im nächsten Sprint verpflichtend umsetzt. So lernt das Team und optimiert sich und den Prozess immer mehr.

Auf welche Arbeiten legt das Team wert?

Gerade in der Software-Entwicklung können sehr schnell schöne und brauchbare Ergebnisse geliefert werden. Es ist dabei für den Softwareentwickler immer wieder eine Bestätigung neue Themen anzufangen und umzusetzen. Da Sprints aber Micro-Projekte sind, sollte das Team nicht den Fehler machen und ständig neue Themen angehen, sondern sich darauf konzentrieren Features „fertig“ zu machen. Testen und Stabilisieren sind dabei zwar oft nicht so „lustige“ Aufgaben aber umso wichtiger. Done und Qualität sind eines der wichtigsten Dinge in Scrum und sollten auf jeden Fall in der Sprintplanung und Umsetzung berücksichtigt werden.

Schlusswort

Dieser Artikel zeigt einige oft auftretende Fehler von Scrum-Teams auf, die verhindern, dass das Team das Sprintziel nicht erreichen kann. Dabei ist diese Aufzählung keinesfalls als vollständige Auflistung aller wichtiger Gründe zu sehen die diesen negativen Effekt verursachen. Viel mehr ist der Artikel als Praxisbericht zu verstehen und hat das Ziel den Leser diese Praxiserfahrungen weiterzugeben und somit Standardfehler möglichst zu verhindern. Scrum-Werte, klare Anforderungen, solide Planungen und offene Kommunikation und Kooperation zwischen PO und Umsetzungsteam sind essentiell, um erfolgreich gemeinsam Scrum zu betreiben und gemeinsam das Sprintziel zu erreichen. Ich hoffe dadurch einigen Teams maßgeblich mit ihren Problemen helfen zu können und den ein oder anderen Denkanstoß geliefert zu haben.

 

 

---

Praxisratgeber Digitalisierungsstrategie entwickeln und umsetzen [Link zu Amazon].

[Amazon 9,99€]

---

Weitere Blogs zur Digitalisierungsstrategie

Digitalisierungsstrategie schnell umsetzen		Inhalt einer Digitalisierungsstrategie

---

Weitere Buchempfehlungen

[Links zu Amazon]

[Amazon 34,00 €]	[Amazon 34,99 €]	[Amazon 24,95 €]
[Amazon 19,99 €]	[Amazon 25,99 €]	[Amazon 42,00 €]

---

Zum Autor:

David Theil aus Linz Oberösterreich ist Digitalisierungs-Coach, Software-Entwickler und als Head of Software-Development für über 30 Softwareentwickler verantwortlich. Beruflich beschäftigt er sich bereits jahrelang mit der Digitalisierung und hat bereits bei vielen Digitalisierungs-Projekten in der Wirtschaft federführend mitgewirkt. Er bewegt sich in Themen wie Digitalisierung, IoT, oder Industrie 4.0 sowohl beratend als auch praktisch mit echten Lösungen.

https://www.xing.com/profile/David_Theil

https://www.linkedin.com/in/david-theil-1a4190148/

https://www.linkedin.com/groups/8678887

https://medium.com/@david.theil

https://twitter.com/DavidTheil