Software-Engineering – agile Pattern und agile Antipattern: Sprint Planning – Antipattern (Teil 1)

Inhalt

Kapazitäts-Overload
Arbeitspaketzuteilung im Planning
Technische-Schuld-Ignoranz
Keine Pufferzeiten
Zu detailliertes Planning
Zu wenig Planung
Kämpfen? Wofür?
Fehlendes Sprintziel
PBI-Übertragung
Last-Minute-PBIs
Quantitätsfokus und Leistungsdruck
Das unvorbereitete Sprint-Planning

Sprint Planning – Antipattern

1. Kapazitäts-Overload

Beschreibung des Antipatterns:

Die wirkliche Kapazität des Teams ist geringer als diejenige, die zur Planung des Sprints herangezogen wird.
Das Umsetzungsteam übernimmt sich in den Sprint-Plannings ständig und geht von einer höheren Kapazität aus, als es in Wirklichkeit leisten kann.
Sprints werden daher zu voll geplant.
Am Ende des Sprints bleiben daher viele PBIs und Stories offen.
Teilweise wurden PBIs nicht angefangen, teilweise sind sie nur halb fertig und noch in Umsetzung.
Sprintziele werden daher oft nicht erreicht.

Mögliche Gründe:

Es werden kapazitätsmindernde Umstände nicht in die Kapazitätsberechnung mit einbezogen.
Das Team steht am Anfang vom Projekt, hat noch keine Erfahrungswerte, welche Kapazität es tatsächlich hat, bzw. wie viele Story-Points es in einem Sprint umsetzen kann.

Warum ist das schlecht?

Ohne Wissen um die ungefähre Kapazität kann der Sprint nicht geplant werden.
Wird zu viel Kapazität angenommen, bleiben PBIs liegen
Bei zu vielen Aufgaben im Sprint besteht das Risiko, dass zu Gunsten der Quantität die Qualität leidet, z.B. technische Schulden aufgenommen werden oder Testen vernachlässigt wird.

Verbesserungen:

Das Team muss die Kapazität gewissenhaft planen, Verfügbarkeiten, Abwesenheiten berücksichtigen.
Insbesondere ist auf mögliche neue Eintritte ins Team, Urlaube, Feiertage, Krankenstände, Kündigungen und Teamwechsel zu achten.
Es muss genügend Sicherheitspuffer eingeplant werden.
Auch Zeiten für organisatorische Tätigkeiten und Meetings im Unternehmen müssen berücksichtigt und eingeplant werden.
Bei neu zum Team hinzustoßenden Kollegen müssen Zeiten fürs Onboarden dieser neuen Kollegen eingeplant werden.
Auch Scrum-Events benötigen ihre Zeit und müssen vom Team berücksichtigt werden.
Es dürfen keine Kompromisse hinsichtlich der Qualität gemacht werden. Können aufgrund von Fehlplanungen oder Verzögerungen in der Umsetzung nicht alle geplanten PBIs umgesetzt werden, muss priorisiert werden. Ein gleichzeitiges halbherziges Umsetzen aller PBIs führt zu nichts.
Wichtig ist, dass das Team aus den vergangenen Planungen und wirklich umgesetzten Story-Points der letzten Sprints lernt und dadurch ständig besser wird.

2. Arbeitspaketzuteilung im Planning

Beschreibung des Antipatterns:

Im Sprint-Planning werden gewisse Tickets den Kollegen nach ihrer Präferenz zugeteilt.
Gewisse User-Stories die in spezielle Bereiche des Systems fallen, werden im Planning, ohne darüber nachzudenken den bereits dort etablierten und eingearbeiteten Team-Kollegen zugeordnet.
Oder es wird das Spezialwissen der einzelnen Entwickler berücksichtigt und die Tickets werden nach diesen Wissensgebieten zerlegt. (z.B. nach Frontend/Backend aufgeteilte PBIs)
Bei Problemen wird auf einzelne „Experten“ verwiesen.

Warum ist das schlecht?

Durch dieses Verhalten werden die Entwickler in Schubladen gesteckt.
Sie können sich selbst nicht in anderen Gebieten weiterentwickeln.
Dadurch wird dieses Spezialwissen noch mehr aufgebaut und das Problem noch verstärkt.
Es wird eine wichtige Grundregel der agilen Arbeitswelt verletzt – die Shared-Code-Ownership. Dies führt dann automatisch zu gewissen Bottlenecks in der Umsetzung.
Das Team und der Product-Owner machen sich auch noch abhängiger von einzelnen Experten.
Zusätzlich werden unnötige Abhängigkeiten zwischen den Tickets geschaffen. Dies kann wiederum dazu führen, dass Features nicht fertig werden, da beispielsweise Teile im Frontend oder Backend noch nicht umgesetzt sind.
Die Planung des Sprints verkompliziert sich außerdem, weil plötzlich auf diese Bottlenecks geachtet werden muss.
Im schlimmsten Fall können auch Konflikte im Team entstehen, wenn einige Teammitglieder auf andere warten müsse und daher unter Druck geraten.
Im Fehlerfall werden dann schnell Schuldzuweisungen gemacht und Verantwortlichkeiten hin- und hergeschoben.

Verbesserungen:

Das Team muss anerkennen, dass alle Arbeitspakete alle was angehen und dass es keine Experten für gewisse Bereiche geben soll.
Bei Problemen muss das ganze Team sich dafür verantwortlich fühlen, diese zu lösen.
Im Idealfall werden alle Teammitglieder auf allen Systemteilen eingesetzt und es wird aktiv daran gearbeitet, Expertenwissen weiterzugeben und keine Spezialgebiete entstehen zu lassen.
Im Sprint-Planning sollen dementsprechend keine PBIs oder User-Stories nach Frontend/Backend aufgeteilt werden, sondern es soll vielmehr gemeinsam als Team an der Lösung gearbeitet werden.

3. Technische-Schuld-Ignoranz

Beschreibung des Antipatterns:

Technische Schulden werden vom Team ignoriert.
Es geht eher darum, schnell Features umzusetzen und sich erst später um technische Schulden zu kümmern.
Oft ist dieser selbst auferlegte Druck, schnell Features umzusetzen kombiniert mit der Angst, dem Product-Owner sagen zu müssen, dass der selbst erstellte Code refactored werden muss, oder technische Schulden beseitigt werden müssen.
Aus dieser Angst heraus traut sich das Team auch nicht Pufferzeiten in den Sprint einzuplanen.

Warum ist das schlecht?

Der Berg an technischen Schulden wächst über das Projekt an, dies führt dazu, dass die Umsetzung neuer Features immer schwieriger und langsamer wird, weil die Komplexität des Codes stark ansteigt. Eine Abwärtsspirale beginnt sich zu drehen.
Meist leidet die Qualität der Software sehr stark, wenn einige Sprints lang nicht auf Code-Qualität, Clean-Code und technische Schulden geachtet wird. Dies schlägt sich letzten Endes auch in der User-Experience nieder.

Verbesserungen:

Das Team muss mit dem Product-Owner sprechen und die Beseitigung der technischen Schulden im Sprint einplanen.
Der Product-Owner muss ein Verständnis dafür entwickeln, dass technische Schulden natürlich in jedem Software-Engineering-Projekt entstehen können und das Team täglich Zeit investieren muss, um diese abzubauen bzw. zu verhindern.
Das Umsetzungsteam muss ein Clean-Code-Mindset entwickeln und darf nicht tolerieren, dass PBIs fertiggestellt werden, obwohl sie mit hohen technischen Schulden verwirklicht wurden.
Gleichzeitig muss sich das Umsetzungsteam Tag für Tag dafür einsetzen, bereits aufgestaute technische Schulden loszuwerden und abzubauen.
Im Regelfall geht man davon aus, dass pro Sprint ca. 20% Pufferzeiten für außertourliche Tätigkeiten wie bspw. die Beseitigung technischer Schulden eingeplant werden muss.
Sollte das Team die Notwendigkeit der Bekämpfung technischer Schulden nicht sehen, so muss der Scrum-Master das Team coachen und versuchen, Verständnis für das Thema zu schaffen. Sollte es an einer Wissenslücke des Teams liegen, müssen ggf. auch externe Hilfe oder Schulungen für das Team angeboten werden.
Ein konstantes Abfallen der Velocity und ein Steigen der Komplexität sind meist erste Warnsignale für das Anhäufen technischer Schulden im Projekt. Der Scrum-Master sollte genau auf solche Warnsignale achten.
Auch die Betrachtung des Code-Churns ist hier relevant schlägt dieser sehr stark aus ist dies ein Zeichen für große Refactoring-Aktivitäten.

4. Keine Pufferzeiten

Beschreibung des Antipatterns:

Das Umsetzungsteam und der Product-Owner planen die Sprints immer vollständig mit Implementierungstätigkeiten für die Features aus, vergessen dabei aber, Unsicherheiten mit einzuplanen und Pufferzeiten freizulassen.

Warum ist das schlecht?

Wenn das Team seine volle Kapazität mit der Umsetzung neuer Features verplant, kommt es dazu, dass Themen wie Qualität, der Abbau technischer Schulden, das Testen oder das Bugfixing vernachlässigt werden.
Durch den hohen Umsetzungsdruck wird dem Team auch die Möglichkeit genommen, sich gegenseitig zu helfen und zu organisieren. Jeder Software-Engineer arbeitet dann bevorzugt an seinen eigenen Themen, damit diese bis zum Sprintende fertig werden. Dies widerspricht agilen Grundregeln wie der Shared Ownership und dem Commitment des gesamten Teams auf das Sprintziel.
Da keine Pufferzeiten eingeplant sind, verfehlt das Team aber oft die Sprintziele. Es wird zu viel versprochen und wenn nur bei einem einzigen PBI etwas Unvorhergesehenes eintritt, fällt das Kartenhaus zusammen.
Des Weiteren kommt es dazu, dass einzelne Teammitglieder zu Bottlenecks werden, was zu Problemen in der Selbstorganisation des Teams und zu verfehlten Sprintzielen führt.
Dem Team wird auch die Flexibilität genommen, auf dringende Bugs und Anfragen des Product-Owners zu reagieren.
Die Vollauslastung des Teams führt auch dazu, dass weniger Zeit für Code-Reviews bleibt. Es bilden sich verstärkt Spezialgebiete und ein gemeinsames Verständnis für die gesamte Code-Basis und eine Shared-Ownership des Codes wird verhindert.
Werden Sprintziele dann oft nicht erreicht, schwindet schnell das Vertrauen des Product-Owners und der Stakeholder in die Umsetzungskompetenzen des Teams. Im schlimmsten Fall wird dann das Team ausgetauscht oder das Projekt frühzeitig abgebrochen.

Verbesserungen:

Der Scrum-Master sollte das Team coachen, sich gegenseitig zu helfen und dafür Pufferzeiten einzuplanen.
Sollte der Product-Owner kein Verständnis für die Notwendigkeit von Pufferzeiten haben, so muss der Scrum-Master hier gezielt Gespräche suchen.
Neben dem Einplanen von Pufferzeiten muss das Team diese Puffer auch gut nutzen können, dazu muss es entweder selbst oder mithilfe des Scrum-Masters eine Qualitätskultur und eine Hilfskultur aufbauen. Jeder muss im Team für den gesamten Code verantwortlich sein. Es soll keine Inselbegabungen und Spezialgebiete geben.
Letzten Endes sollte das Team sich auf den Outcome konzentrieren, nicht auf den Output.

5. Zu detailliertes Planning

Beschreibung des Antipatterns:

Das Team plant den Sprint, als wäre es ein kleines Wasserfall Projekt.
Es nutzt das Sprint-Planning um nicht nur das Sprintziel und das Sprintbacklog zu planen, sondern geht auch sehr stark in die Planung des Designs und der Architektur der umzusetzenden Änderungen.
Es wird versucht, für jedes PBI auch noch zusätzlich alle einzelnen Umsetzungstask und alle einzelnen Arbeitsschritt zu planen.

Warum ist das schlecht?

Dieser Upfront-Aufwand und diese Granularität führen zu erheblichen Vorleistungen, die jedoch ggf. nicht immer gebraucht werden. Es entsteht möglicherweise Ausschuss und somit vergeudetes Budget.
Zu detaillierte Arbeitsplanung führt meist dazu, dass das Team Tasks einzelnen Kollegen zuteilt und sich somit Expertenwissen und Spezialgebiete bei einzelnen Teammitglieder bildet.
Die Kooperation leidet, weil jedes Teammitglied nur auf seine Tasks schaut.

Verbesserungen:

Das Sprint-Planning soll vor allem einen Weg für die Umsetzung skizzieren. Es soll dem Team ermöglichen, den Outcome zu maximieren und ein möglichst gutes Produkt, möglichst gut abgestimmt, gemeinsam zu erreichen.
Das Planning sollte daher nicht zu granular sein. Es soll dem Product-Owner und den Stakeholdern schon ein gutes Gefühl verschaffen, wie das Team plant, das Sprintziel zu erreichen. Es muss und soll aber nicht zu ausgiebig durchgeführt werden.

6. Zu wenig Planung

Beschreibung des Antipatterns:

Genauso schlecht wie zu detaillierter Planung ist auch zu wenig Planung. Immer wieder lässt sich in der Praxis beobachten, dass Teams ganz auf das Planning verzichten. Sie ziehen wahllos PBIs in das Sprint-Backlog hinein, berücksichtigen dabei gerade noch etwas die Velocity und die Story-Points bzw. die Kapazität des Teams, vernachlässigen aber die Detailplanung und den eigentlichen Sinn hinter dem Planning – den Outcome zu maximieren und dem PO und den Stakeholdern einen Umsetzungsplan hinsichtlich eines konkreten Sprintziels zu liefern, der für alle verständlich und transparent ist.

Warum ist das schlecht?

Es werden oft unterschiedliche PBIs in den Sprint gezogen, die teilweise gar nicht zum Sprintziel passen.
Das Team fokussiert sich auf Output nicht Outcome.
Burndowncharts werden oft nicht sauber runtergebrannt.
Am Sprintende sind entweder zusätzlich PBIs in den Sprint gezogen worden oder noch zu viele PBIs offen und übrig.

Verbesserungen:

Im Sprint-Planning sollte vom Sprintziel abgeleitet PBIs im Sprint-Backlog geplant werden.
Das Team selektiert gemeinsam mit dem Product-Owner was im Sprint umzusetzen ist, um das Sprintziel zu erreichen.
Abgeleitet von dieser groben „Was-Planung“, plant das Team gemeinsam das Wie.
Es sollte hier die Chance nutzen und über technische Schulden, Architekturen und Lösungsideen diskutieren.
Auch sollte das Team das Sprint-Planning als erste Chance im Sprint sehen, sich zu koordinieren und auszumachen, wer wie mit wem zusammenarbeiten will, um im Nachgang die Koordination zu erleichtern.
Der Plan sollte nicht zu detailliert sein, aber auch nicht zu vage bleiben.
Oberstes Ziel ist neben der Planung und Koordination im Team auch, dass Product-Owner und Stakeholder einen guten Eindruck davon bekommen, wie das Team das Sprintziel erreichen will, ohne dabei in die tiefe oder auf die Technik einzugehen.
Nicht zuletzt sorgt das Sprint-Planning auch für Transparenz, da das Sprint-Burndownchart initialisiert wird und im weiteren Verlauf des Sprints hinunter brennt.

7. Kämpfen? Wofür?

Beschreibung des Antipatterns:

Das Team weiß nicht, was das Sprintziel ist und wie es mit der Vision des Produkts und dem Projektziel zusammenhängt.
Der Product-Owner würfelt die Product-Backlog-Items wild zusammen und priorisiert diese nicht nach Themengebiete.
Somit kann das Team diese Backlog-Items nur sehr schwer mit der Vision in Einklang bringen und Sprintziele definieren.
Das Team arbeitet folglich in dieser Situation meist ohne Sprintziel.

Warum ist das schlecht?

Ohne zu wissen, was das Sprintziel ist und eine damit einhergehende Planung und Fokussierung auf den Outcome, ist das Team sehr stark dazu verleitet, sich auf den Output zu konzentrieren.
Das heißt, das Team arbeitet nur PBI nach PBI ab und gestaltet somit nicht mit dem Product-Owner das Produkt mit.
Es bildet sich kein Teamzusammenhalt mit dem Product-Owner und somit ein nur schwer oder nicht funktionierendes Scrum-Team.

Verbesserungen:

Der Product-Owner und das Team müssen klare Sprintziele formulieren und diese in den Sprints verfolgen.
Es kann eine gute Übung sein, zunächst das Sprintziel gemeinsam mit dem Team zu definieren, sich also auf den Outcome zu konzentrieren und erst danach das Sprintbacklog, mit PBIs aus dem Product-Backlog, nach den Vorgaben des Sprintziels, zu befüllen.
Ein gutes Sprintziel sollte die Frage beantworten „wofür wir in diesem Sprint kämpfen“.
Das Sprintbacklog ist eine Verhandlung zwischen Umsetzungsteam und Product-Owner. Es wird aber aus dem Product-Backlog aufgebaut und nimmt Bezug auf das Sprintziel.
Jedes Sprintziel muss von der Vision und von Geschäftszielen abgeleitet sein und somit zur Unternehmensstrategie/Digitalisierungsstrategie passen.
Jeder Sprint muss mit deinem Sprintziel geplant werden. Sollte dies nicht der Fall sein, muss der Scrum-Master diesen Missstand erkennen und dementsprechend Gegenmaßnahmen einleiten.

8. Fehlendes Sprintziel

Beschreibung des Antipatterns:

Dieses Antipattern ist ähnlich zu dem „Kämpfen? Wofür?“-Antipattern, nur dass es sich in diesem Fall darum handelt, dass der PO gar kein Sprint-Ziel etablieren will, oder dass der PO dies nicht am Radar hat.
Der PO definiert jeden Sprint einfach nur, welche PBIs als Nächstes implementiert und umgesetzt werden sollen, ohne dieses in einen Kontext mit der Vision und der Produktstrategie zu geben. Dies führt dazu, dass das Team rein outputgetrieben ist und nicht gemeinsam mit dem PO auf den Outcome achtet.

Warum ist das schlecht?

Da sich der Fokus auf den Output verschiebt, zählen Dinge wie Schätzgenauigkeit, Umsetzungsgeschwindigkeit und Fehlerfreiheit viel mehr und bekommen besondere Aufmerksamkeit.
Die Aufmerksamkeit auf Usability und User-Experience hingegen und auf die Gesamtvision bzw. Unternehmensstrategie hingegen wird abgeschwächt oder ganz vernachlässigt.
Die gesamte Vorgehensmethode ähnelt hier mehr Kanban mit zweiwöchentlichen Abstimmungsmeetings. Mit Scrum und interdisziplinärer Produktentwicklung hat dies nicht mehr viel zu tun, weil alle Anforderungen sehr detailliert vom PO vorgegeben werden müssen, um auch gut schätzbar und umsetzbar zu sein.
Dieses Antipattern schränkt also das Team ein und schöpft nicht das volle Potenzial der Teammitglieder aus. Daher ist es nicht so effizient. Das Produkt-Risiko steigt außerdem, weil nur der Product-Owner auf die Produktvision und den Outcome achten kann.

Verbesserungen:

Sprintziele müssen von der Unternehmensvision abgeleitet werden.
Der Product-Owner muss seine Rolle als Produktverantwortlicher erkennen, aber auch das Team integrieren und Plannings als Gelegenheit nutzen, die Produktvision gemeinsam mit dem Umsetzungsteam zu entwickeln.
Sollte der Product-Owner seine Rolle falsch verstehen, so muss der Scrum-Master dafür Sorge tragen, dass dieser seine Rolle und das Sprint-Planning richtig erkennt und umsetzt.
Dieses Verhalten kann auch ein dafür Zeichen sein, dass der PO von Stakeholdern zu sehr unter Druck gesetzt wird und somit viele Themen gleichzeitig adressiert werden müssen.

9. PBI-Übertragung

Beschreibung des Antipatterns:

Bei diesem Antipattern übernimmt das Scrum-Team die nicht fertigen PBIs aus dem Vorsprint in den neuen Sprint, ohne großartig darüber zu reden. Weder in der Retrospektive noch im Planning wird das Thema adressiert.
Gleichzeitig fehlt dann oft auch ein Sprintziel für den neuen Sprint.
Zu Beginn des Sprints, sondern sich dann einige Teammitglieder vom Rest des Teams ab und setzten neue Teile des Sprints um, während andere Teammitglieder die alten weitergeschobenen PBIs fertigmachen.

Warum ist das schlecht?

Meist ist dieses Antipattern ein sehr schlechtes Zeichen, weil Sprintziele dementsprechend nicht definiert und diskutiert werden und es eher mehr um den Output als den Outcome geht.
Diese Fokussierung auf den Output führt dazu, dass Kundennutzen und der Mehrwert in den Hintergrund rückt und erhöht das Produktrisiko.
Ein weiterer Nachteil ist, dass sich das Team aufteilt und einige an lustigen neuen Tickets arbeiten können, während andere noch Dinge fertigmachen müssen. Dies kann zu Konflikten im Team führen und schadet dem Teamzusammenhalt und widerspricht der Shared-Code-Ownership.
Der größte Nachteil bei diesem Antipattern entsteht jedoch daher, dass nicht über die Ursachen dieser PBI-Übertragungen gesprochen wird. Dadurch lernt das Team nicht dazu und kann somit diesen Effekt zukünftig nicht verhindern.
Es kann durchaus sein, dass der ein oder andere Sprint mal nicht jedes geplante PBI abschließt, wenn dies jedoch regelmäßig oder hauptsächlich passiert ist Vorsicht geboten.

Verbesserungen:

Die PBI-Übertragung kann mehrere Gründe haben. Es könnte beispielsweise sein, dass die Kapazität stark geschwankt hat, weil Team-Mitglieder ausgefallen sind. Oder das Team hat die Kapazität völlig falsch eingeschätzt, was gerade am Anfang einer Produktentwicklung mit Scrum sehr wahrscheinlich ist, weil das Team noch keine entsprechenden Erfahrungswerte hat.
Es könnte aber auch sein, dass das Team im Schätzen der Story-Points sich grob verschätzt hat und gewisse Unsicherheiten nicht berücksichtigt hat. Meist geht dies mit einer fehlenden Spike-Kultur des Teams einher (Siehe Antipattern Keine-Spike-Kultur).
Auch alle anderen Antipattern in diesem Abschnitt haben direkten Einfluss darauf, ob das Team mit seinen geschätzten und geplanten PBIs im Sprint fertig wird oder nicht. Fakt ist, PBIs einfach so von einem in den nächsten Sprint zu übertragen, ohne die Hintergründe zu eruieren ist ein sehr schlechtes Antipattern, welches tunlichst vermieden werden sollte.
Oft hat der Scrum-Master den neutraleren Blick auf das Team und somit sollte er dieses Thema erkennen, in der Retrospektive ansprechen und die Gründe eruieren, warum es wiederholt zu Übertragungen kommt und mit dem Team gemeinsam Gegenmaßnahmen einleiten.

10. Last-Minute-PBIs

Beschreibung des Antipatterns:

Bei Last-Minute-PBIs versucht der Product-Owner in frisch geplanten Sprint noch PBIs einzumelden und das Team dazu zu bringen, diese umzusetzen. Meist passiert dies auch noch unter Aushebelung des gesamten Scrum-Prozesses und dessen Sicherungsmaßnahmen wie DoR, Refinement-Meetings, etc.
Der Grund für solche Situationen findet sich meist bei den Stakeholdern, die kurzerhand etwas vom Product-Owner sehen wollen.

Warum ist das schlecht?

Wenn der PO in den frisch geplanten Sprint eingreift und versucht PBIs unter Priorität umgesetzt zu bekommen, bringt das die gesamte Sprintplanung und Sprintorganisation aus dem Konzept.
Meist führt dies dazu, dass das Sprintziel nicht eingehalten werden kann und Teammitglieder ihre gerade Offenen und in Bearbeitung befindenden PBIs zurücklegen, um die neuen PBIs umzusetzen. Dies führt zu Multitasking und zu Fehlern.
Oft ist es auch ein Zeichen für einen starken Stakeholder und einen schwachen Product-Owner der nicht „Nein“ sagen kann.
Passiert dies zu oft, wird Scrum ausgehebelt und das Team demotiviert. Wenn die spontane Änderung nicht gut eingeplant wird, passieren in diesen Fällen meist auch mehr Fehler und die technische Schuld steigt.

Verbesserungen:

Hier sollte das Team abwiegen. Ausnahmen bestätigen meist die Regel und in wirklich dringenden Fällen kann es für ein Produkt und ein Projekt entscheidend sein, solche Spezialaufträge zu erfüllen. Dennoch sollten nicht die Planung und die Organisation unter dieser Situation leiden. Im Notfall, wenn sich das neue PBI nicht gut in den Sprint integrieren lässt, ist es am besten, den Sprint abzubrechen und neu zu planen.
Passiert dies jedoch zu oft, müssen der Scrum-Master und das Team dies unterbinden und das Thema in der Retrospektive ansprechen.
Es kann auch sein, dass der Product-Owner seine Rolle nicht ganz verstanden hat oder Stakeholder ihm overrulen. In diesem Fall muss der Scrum-Master eingreifen und entweder mit dem Product-Owner oder mit dem Stakeholder reden und die Wogen glätten.

11. Quantitätsfokus und Leistungsdruck

Beschreibung des Antipatterns:

Der Product-Owner hinterfragt bei der Planung des Sprints die Schlagzahl des Umsetzungsteams.
Er erhöht den Druck auf das Team und möchte, dass dieses mehr PBIs im Sprint umsetzt als ursprünglich geplant.
Oft referenziert der PO dabei auf vergangene Sprints und Kennzahlen.
Oder er referenziert auf andere Teams und deren Kennzahlen.

Mögliche Gründe:

Dieses Verhalten des Product-Owners im Planning kann mehrere Gründe haben, die wichtigsten beiden seien hier aber erwähnt:
Es kann sein, dass der PO seine Rolle nicht richtig verstanden hat, also, dass sich der PO als Projektmanager sieht und denkt, er müsse dafür sorgen, dem Team stramme vorgaben zu machen.
Es kann auch sein, dass der PO Druck von anderen Stakeholdern verspürt und diesen Druck ungefiltert weiter gibt.

Warum ist das schlecht?

Dieses Verhalten führt zu einer Disharmonie im Team. Der PO kümmert sich durch den ausgeübten Druck nicht mehr rein um das „Was“, sondern übt Einfluss auf das „Wie“ aus.
Das Team kann sich dadurch sehr schnell falsch verstanden fühlen und so kann ein Konflikt entstehen.
Lässt sich das Team auf dieses Spiel ein und gibt dem Druck nach, verwandelt es sich mehr und mehr in ein Output-getriebenes-Team welches Feature für Feature schnell abarbeitet.
Durch den erhöhten Aufwand in der begrenzten Zeit, die ein Sprint bietet, lässt das Team dann auch meist qualitätssichernde Maßnahmen weg oder spart an anderen Stellen wie der Kommunikation oder der Transparenz ein. Dies führt insgesamt zu Verschlechterungen im Produkt und im Prozess und lässt die Fehlerwahrscheinlichkeit und das Produktrisiko steigen.

Verbesserungen:

Dem Product-Owner muss klar sein, dass die Umsetzungsgeschwindigkeit und die Anzahl der PBIs die im Sprint erledigt werden können, nicht zu seinem Verantwortungsbereich gehören.
Gegebenenfalls, falls es sich um ein Missmatch im Rollenverständnis des Product-Owners handelt, muss der Scrum-Master eingreifen und dem PO seine Rolle näherbringen.
Sollte es um einen Druck eines Stakeholders handeln, der vom Product-Owner nur weitergegeben ist, muss der Scrum-Master sowohl dem PO stärken und verhindern, dass dieser den Druck weitergibt, als auch den Stakeholder in Boot holen und somit den Druck vom Team nehmen. Hier fehlt es dem Stakeholder dann oft an Transparenz, oder der Stakeholder hat zu wenig Verständnis gegenüber der Produktentwicklung.

12. Das unvorbereitete Sprint-Planning

Beschreibung des Antipatterns:

Das Sprint-Planning soll beginnen, doch der Product-Owner hat, so wie in unzählige vorherige Sprint-Plannings, wieder nichts vorbereitet.
Das Backlog ist nicht gefüllt, oder die Product-Backlog-Items sind nicht priorisiert.
Es gibt kein Sprint-Ziel und generell wissen das Team und er PO nicht, wo die Reise hingehen soll.

Warum ist das schlecht?

Sprintziele müssen immer von der Produktstrategie abgeleitet werden. Ist der Product-Owner nicht vorbereitet und hat keine Strategie so kann auch kein Sprintziel abgeleitet werden.
Normalerweise wird aufgrund des Sprintziels das Sprintbacklog geplant. Ist dies nicht möglich, zieht das Team wahllos PBIs in das Sprintbacklog ohne diese an einem Sprintziel zu orientieren. Dies führt wiederum dazu, dass das Team eher auf den Output fokussiert als auf den Outcome.
Das heißt, im schlimmsten Fall werden Features entwickelt die keinen Mehrwert für den User darstellen. Es entstehen massive Kosten und kaum Gegenwert.
Aufgrund der schlechten Vorbereitung durch den Product-Owner entstehen auch schnell Spannungen zwischen Product-Owner und Team. Diese Spannungen und Konflikte belasten die Arbeit und verursachen ebenfalls Kosten.

Verbesserungen:

Das Ziel sollte es sein ein Backlog so aufzubauen, dass ca. zwei bis drei Sprints geplant werden können.
Gerade im ersten Sprint wird dies ggf. nicht der Fall sein und das ist auch normal und in der agilen Produktentwicklung Best Practice, aber wenn das Team schon die ersten Sprints hinter sich gebracht hat, sollte sich langsam das Backlog und die Vision verfestigt haben und das Planning problemlos funktionieren.
Der Product-Owner sollte, falls ihm hier das Verständnis für seinen Job fehlt, vom Scrum-Master gecoached werden.
Gemeinsam mit dem Umsetzungsteam kann der PO in Refinement-Meetings PBIs vorbereiten, sodass das Produktbacklog gut gefüllt und immer einige PBIs refined sind.
Gerade am Anfang, wenn noch kein „reguläres“ Sprint-Planning gemacht werden kann, sollte das Team soweit improvisieren, dass z.B. Spikes gemeinsam angelegt und im ersten Sprint umsetzen.