Software-Engineering Pattern und Antipattern: Sprint Planning – Antipattern

Inhalt

1. Kapazitäts-Overload
2. Arbeitspaktzuteilung im Planning
3. Technische-Schuld-Ignoranz
4. Keine Pufferzeiten
5. Zu detailliertes Planning
6. Zu wenig Planung
7. Kämpfen? Wofür?
8. Fehlendes Sprintziel
9. PBI-Übertragung
10. Last-Minute-PBIs
11. Quantitätsfokus und Leistungsdruck
12. Das unvorbereitete Sprint-Planning

Sprint Planning – Antipattern

1. Kapazitäts-Overload

  • 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:

  • Kapazität gewissenhaft planen
  • Eintritte ins Team, Urlaube, Feiertage, Krankenstände, Kündigungen und Teamwechsel berücksichtigen
  • Sicherheitspuffer einplanen
  • Zeiten für organisatorische Tätigkeiten und Meetings im Unternehmen berücksichtigen und einplanen
  • Zeiten fürs Onboarden neuer Kollegen einplanen
  • Scrum-Events einplanen in Kapazität
  • Keine Kompromisse hinsichtlich der Qualität machen
  • Aus den Kapazitäten und wirklich umgesetzten Story-Points der letzten Sprints lernen

2. Arbeitspaktzuteilung im Planning

  • Im Sprint-Planning werden gewisse Tickets nach Frontend/Backend aufgeteilt und den Team-Kollegen entsprechend ihrer Präferenzen 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
  • Dadurch werden Spezialwissen aufgebaut und Abhängigkeiten geschaffen und eine Grundregel der agilen Arbeitswelt verletzt. Shared Ownership der Source-Code gehört alle und das gesamte Team committet sich auf das Sprintziel.
  • Bei Problemen wird auf einzelne „Experten“ verwiesen.

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 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

  • Technische Schulden werden vom Team ignoriert.
  • Es geht eher darum jetzt 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.
  • 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 technische 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 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 fertig gestellt 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 los zu werden und ab zu bauen.
  • 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.

4. Keine Pufferzeiten

  • Das Umsetzungsteam und der Product-Owner planen die Sprints immer vollständig mit der Umsetzung Features aus, vergessen aber dabei aber Unsicherheiten mit einzuplanen und Pufferzeiten freizulassen.
  • Wenn das Team seine volle Kapazität aus plant mit der Umsetzung neuer Features, 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.
  • 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.
  • Es wird auch die Flexibilität des Teams 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.

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 eingreifen.
  • Neben dem Einplanen von Pufferzeiten, muss das Team diese Puffer auch gut nutzen können, dazu muss es entweder selbst oder mit Hilfe 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

  • 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 das Design und die Architektur der umzusetzenden Änderungen hinein.
  • Es wird versucht für jedes PBI auch noch zusätzlich jeden einzelnen Umsetzungstask und jeden einzelnen Arbeitsschritt zu erfassen.
  • 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 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 PO 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

  • 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-Point 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 eine Umsetzungsplan zu liefern der für alle verständlich und transparent ist.
  • Es werden oft auch 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 ü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 PO 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 hinunterbrennt.

7. Kämpfen? Wofür?

  • 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 das Produkt, mit dem PO, mit.
  • Es bildet sich kein Teamzusammenhalt mit dem PO und somit kein 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, also sich auf den Outcome zu konzentrieren und erst danach das Sprintbacklog mit PBIs aus dem Produkt-Backlog, nach den Vorgaben des Sprintziels, zu befüllen.
  • Ein gutes Sprintziel sollte die Frage beantworten „wofür wir in diesem Spint kämpfen“.
  • Das Sprintbacklog ist eine Verhandlung zwischen Umsetzungsteam und Product-Owner. Es ist aber gleichzeitig abgeleitet vom Sprintziel.
  • Jedes Sprintziel muss von der Vision und von Geschäftszielen abgeleitet sein und somit zur Unternehmensstrategie/Digitalisierungsstrategie passen.
  • Der Scrum-Master sollte diesen Missstand erkennen und dementsprechend Gegenmaßnahmen einleiten.

8. Fehlendes Sprintziel

  • 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.
  • 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 einen 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.

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 versteht.
  • Dieses Verhalten kann auch ein 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

  • Bei diesem Antipattern übernimmt das Scrum-Team die nicht fertigen PBIs aus dem Vorsprint in den aktuellen Sprint, ohne großartig darüber zu reden. Weder in der Retrospektive noch im Planning wird das Thema adressiert.
  • Dieses Antipattern geht dann auch gleich Hand-in-Hand mit dem fehlenden Sprintziel. Einige Teammitglieder, sondern sich am Anfang des Sprints ab und arbeiten an neuen Themen von potenziell neuen Sprintzielen während andere vom vergangenen Sprint ihre PBIs abschließen.
  • Meist ist es ein sehr schlechtes Zeichen, wenn dies passiert, weil Sprintziele dementsprechend nicht definiert und diskutiert werden und es eher mehr um den Output als den Outcome geht.
  • 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 einher mit einer fehlenden Spike-Kultur des Teams (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, die PBI-Übertragung einfach so zu machen 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

  • Bei Last-Minute-PBIs versucht der PO in den Laufenden Sprint noch PBIs einzumelden und das Team dazu zu bringen, dass dieses dies mit Priorität umsetzt. Meist passiert die 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 PO sehen wollen.

Warum ist das schlecht?

  • Wenn der PO in den laufenden 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 muss der Scrum-Master und das Team dies unterbinden und das Thema in der Retrospektive ansprechen.
  • Es kann auch sein, dass der PO seine Rolle nicht ganz verstanden hat oder Stakeholder ihm overrulen. In diesem Fall muss der Scrum-Master eingreifen und entweder mit dem PO oder mit dem Stakeholder reden und die Wogen glätten.

11. Quantitätsfokus und Leistungsdruck

  • 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. Oftmals refernziert er auch auf andere Teams.

Mögliche Gründe:

  • Dieses Verhalten des Product-Owners im Planning kann mehrere Gründe haben die wichtigsten 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 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 Risiko 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 oft dann an Transparenz und Verständnis des Stakeholders gegenüber der Produktentwicklung.

12. Das unvorbereitete Sprint-Planning

  • Das Sprint-Planning sollbeginnen 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.

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 gut so in der agilen Produktentwicklung, 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.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: