Software-Engineering – agile Pattern und agile Antipattern: Backlog-Antipattern

Inhalt

  1. Epic User-Stories
  2. Technical User-Stories
  3. UseCase Stories
  4. Priorisierung durch Stakeholder
  5. Backlog-Wasserfallplanung
  6. Upfront detailed Estimation
  7. Big-Backlog
  8. Veraltete User-Stories
  9. Komponenten-Backlog-Items
  10. Estimation Inflation
  11. Estimation in Workhous
  12. Fehlende Akzeptanzkriterien
  13. Title-Only-Items
  14. Copy-Paste-Backlog-Items
  15. Fehlende Backlog-Struktur
  16. Keine-Spike-Kultur
  17. Ideenspeicher für den Product-Owner

Backlog-Antipattern

Beschreibung des Antipatterns:

  • Die vom PO erfassten User Stories sind zu groß, sie gleichen eher Epics als feinen PBIs.
  • Diese Elpic User-Stories umfassen eher ganze Themenblöcke statt einzelne User-Stories mit nur einem einzigen Feature.

Warum ist das schlecht?

  • Sind die User-Stories zu groß können sie einerseits nicht gut geschätzt werden, andererseits sind sie dann zu groß, um in einem Sprint verplant zu werden.
  • Umso größer eine Story ist, umso größer ist auch der Schätzfehler. Dadurch werden Sprintziele schlechter planbar und schlechter erreicht, was wiederum dazu führt dass Stakeholder die Fähigkeiten des Teams hinterfragen.

Verbesserungen:

  • Erstellen oder einhalten der festgeschriebenen Definition of Ready wie eine User-Story aussehen soll,
  • Das Einhalten der der INVEST Regel
  • Refinements nutzen, um User Stories auf die richtige Portionsgröße hinunter zu bekommen.

Beschreibung des Antipatterns:

  • User-Stories kümmern sich nicht um das Was zu bauen ist und das Warum, sondern fokussieren sich leider großteils auf das Wie.
  • Die Bedürfnisse des Users und der wirtschaftliche Mehrwert werden in den User-Stories ignoriert. Sie kommen in den technischen User-Stories gar nicht vor.

Warum ist das schlecht?

  • Durch dieses Antipattern wird dem Team viel Handlungsspielraum genommen, denn die Tickets genau beschreiben wie etwas gemacht werden soll.
  • Außerdem kann ein Product-Owner die Tickets auf so einer Detailebene gar nicht alleine planen, denn dazu fehlt ihm der Einblick in die Architektur und die Umsetzung. Daher muss das Ticket gemeinsam mit dem Team spezifiziert werden, was wiederum viel Zeit benötigt. Zeit und Arbeit, die upfront in die Spezifizierung gesteckt werden muss. Dadurch verliert das Team wertvolle Time to Market, die Zykluszeit einzelner Features dehnt sich aus. Und im schlimmsten Fall werden Tickets spezifiziert, die nie umgesetzt werden, und dadurch geht die investierte Arbeitszeit verloren.

Verbesserungen:

  • Hier muss der PO vor allem etwas an seinem Mindset ändern und sich mehr auf den Markt, die User-Bedürfnisse und den wirtschaftlichen Nutzen der Software besinnen.
  • Ist keine Definition of Ready etabliert, so muss diese gemeinsam beschlossen und einhalten werden.
  • PBIs und User-Stories sollen immer die Needs des Users spezifizieren.
  • Eine User-Stroy sollte bei jedem PBI die Sicht des Users darstellen und beschreiben warum der User was braucht.
  • Um dies leichter zu ermöglichen, sollte das Team Personas verwenden und diese Personas ebenfalls im PBI festhalten.
  • Der Product-Owner muss sich immer in Erinnerung rufen, dass die Software für den User und nicht ihn selbst erstellt wird.
  • Zur Unterstützung können Story-Mapping Workshops durchgeführt werden, bei denen von der Vision, Ziele und Stories abgeleitet werden und Personas in den Mittelpunkt gestellt werden.

Beschreibung des Antipatterns:

  • User-Stories werden auf einer funktionalen Ebene vorbereitet und ausspezifiziert, das Team muss diese dann „nur mehr umsetzten“.
  • User-Stories kümmern sich hauptsächlich um das Wie und lassen das Was und Warum außen vor.
  • Das Design der Umsetzung ist bereits in der UseCase-Story enthalten.
  • Im Gegensatz zum vorherigen Antipattern „technische User-Stories“ setzt der Product-Owner hier aber auf Minimalismus und lässt die technische Komponente aus. Er leitet die Use-Cases von einer UML Architektur ab und lässt diese planmäßig umsetzen.
  • Beispiel: Implementieren der Funktion „User kann sich einloggen“.

Warum ist das schlecht?

  • Das Team wird in diesem Fall nicht vom Product-Owner abgeholt, was die eigentlichen Needs der User sind. Es ist nicht nachzuvollziehen, ob der Product-Owner hier Markt und User-Bedürfnisse berücksichtigt oder ob er plangetrieben vorgeht. Meist wird beim Auftreten dieses Antipatterns jedoch plangetrieben vorgegangen.
  • Diese Vorgehensweise führt dazu, dass zu Beginn, wo noch sehr wenige Informationen über den Markt und die User-Bedürfnisse vorliegen, viele Annahmen getroffen werden. Die Verifizierung dieser Annahmen kann aber nicht durchgeführt werden, weil Annahmen und Hypothesen nicht in den PBIs dokumentiert sind. Somit können sie erst nach der Umsetzung ganzer Feature-Blöcke evaluiert werden.
  • Dem Team wird die Möglichkeit genommen, dem Product-Owner zu unterstützen und wird nur zur reinen Umsetzung eingesetzt.
  • Oft bestehen diese PBIs dann nur aus einer Überschrift und den dazugehörigen Akzeptranzkriterien.

Verbesserungen:

  • Der Scrum-Master und das Team sollten in diesem Fall sehr darauf achten dass nicht plangetrieben sondern agil vorgegangen wird.
  • In den User-Stories versteckte Hypothesen und Annahmen müssen demaskiert und aufgedeckt werden.
  • Das Warum muss in jeder User-Story Priorität haben und klar herauskommen.
  • User-Stories dienen zum Austausch zwischen Product-Owner und Team.
  • Sie sind Diskussionsgrundlage und kein Umsetzungsplan.
  • Das Team sollte zunächst mit dem PO über die User-Story den Sinn und Zweck diskutieren bevor Akzeptanzkriterien gemeinsam durchgegangen werden.
  • Akzeptanzkriterien können gemeinsam im Refinement erstellt werden.

Beschreibung des Antipatterns:

  • Backlog-Items und User-Stories werden nicht von einem „starken“ PO priorisiert, sondern von Stakeholdern, die entweder direkt im Product-Backlog mitmischen und die Prioritäten ändern, oder den Proxy-PO (siehe Role-Antipattern) anweisen, dies zu tun.

Warum ist das schlecht?

  • Dieses Antipattern führt dazu, dass sich die Entwicklung des Produkts nur schwer steuern lässt, es keine einheitliche rote Linie gibt, die sich durch das Produkt zieht und oft auch technische Schulden gemacht werden, weil sich Prioritäten ändern und Strukturen schnell nachziehen müssen.

Verbesserungen:

  • Stakeholder müssen vom PO koordiniert werden, nicht umgekehrt.
  • Ein guter PO muss „NEIN“ sagen und priorisieren können.
  • Ein Produkt muss durchdacht werden und eine Priorisierung gewissenhaft gemacht werden. Erkenntnisse aus dem Markt und User-Bedürfnisse müssen in die Produktentwicklung mit einfließen.
  • Das Team muss trotz des vielen Hin und Her technische Schulden meiden.

Beschreibung des Antipatterns:

  • Der Product-Owner und das restliche Scrum-Team planen das Produkt voraus und erstellen für das gesamte Produkt ein Backlog.
  • Dieses Backlog umfasst das gesamte Projekt.
  • Oft tritt dieses Antipattern auf, weil der Scope bis zum Release fix ist und das Budget eine dementsprechende Obergrenze hat.

Warum ist das schlecht?

  • Bei diesem Antipattern wird sehr viel Zeit und Arbeit in einen Plan gesteckt. Dieser Plan manifestiert sich im Product-Backlog.
  • Jedoch basiert der Plan auf sehr vielen Annahmen und Bedingungen, die als fix gesetzt sind. Dadurch entsteht ein hohes Produkt-Risiko.
  • Es besteht somit die Gefahr, dass aufgrund von falsch getroffenen Annahmen das Produkt so entwickelt wird, dass es keinen Product-Market-Fit findet und es keine Kunden kaufen wollen.
  • Es kann auch sein, dass das Produkt zwar angenommen wird, einige Features aber nicht verwendet werden. Dies bedeutet, dass viel Energie und Zeit verloren geht und unnötige Kosten entstehen.

Verbesserungen:

  • Ein derartiges Verhalten kann zwei Ursprünge haben:
  • Entweder hat das Team das Bedürfnis, das gesamte Produkt in das Product-Backlog zu fassen, oder Rahmenbedingungen, die von außen vorgegeben werden, zwingen das Team so zu handeln.
  • Im ersten Fall scheint der Mehrwert von agilen, iterativen inkrementellen Arbeiten nicht im Team angekommen zu sein.
  • Hier scheint dem Team die agile Vorgehensweise also nicht ganz klar zu sein. Der Scrum-Master sollte daher das Team und den Product-Owner coachen und erklären, was der Unterschied zwischen Upfront-Planning und agilen, explorativen inkrementellen produktentwickeln ist.
  • Im zweiten Fall werden dem Team Rahmenbedingung vom Management gemacht, die es in eine plangetriebene Arbeitsweise treibt. Es werden Umfang und Budget fixiert, was dazu führt, dass das Team mehr vorausplanen muss und ein großes Backlog anlegt. Sind Scope und Budget fix, leidet automatisch auch die Qualität des Produkts.

Beschreibung des Antipatterns:

  • Das Scrum-Team beginnt den Sprint erst dann, wenn alle Backlog-Items im Backlog im Detail geplant und geschätzt wurden.
  • Es werden vor allem auch jene Backlog-Items geschätzt, die erst in den darauffolgenden Sprints umgesetzt werden können.

Warum ist das schlecht?

  • Diese Schätzungen benötigen viel an Vorausplanung, also entstehen Upfront-Aufwände die ggf. nicht benötigt werden, weil sich in der Zwischenzeit neuer Erkenntnisse ergeben oder Prioritäten ändern.
  • Alle Arbeiten, die Upfront gemacht werden, verzögern die Auslieferung von Features und somit die Auslieferung von Mehrwert, der beim User erst verspätet ankommt.

Verbesserungen:

  • Es sollten maximal 2-3 Sprints in voraus geschätzt werden und eine grobe Schätzung auf Story-Point-Basis reicht aus.
  • Es muss nicht im Detail geplant werden, die Detailplanung kann im Sprint Planning oder der Umsetzung gemacht werden.

Beschreibung des Antipatterns:

  • Das Backlog ist so groß, dass es nicht in 1-3 Sprints abgearbeitet werden kann.
  • Es werden Features spezifiziert, die erst irgendwann umgesetzt werden können.

Warum ist das schlecht?

  • Das Hauptproblem dieses Antipatterns ist, dass User-Stories definiert werden, die vielleicht nie umgesetzt werden. So verschwendet der Product-Owner wichtige Zeit, die er mit dem Team verbringen könnte.
  • Ein weiterer wichtiger Grund, das Backlog klein zu halten ist, dass es sehr aufwendig ist, ein Backlog zu pflegen und am aktuellen Stand zu halten. Diese Wartung kostet sehr viel Zeit. Zeit die wirtschaftlicher und sinnvoller eingesetzt werden kann. So soll ein Product-Owner nicht nur das Backlog warten, sondern vor allem Informationen vom Markt zusammentragen und Feedback zum Produkt einsammeln.

Verbesserungen:

  • Spezifikationen über 3 Sprints hinaus sind nicht sinnvoll. Es ist ratsam, auf Qualität zu setzen als auf Quantität.
  • Daher ist es besser, ein gutes kleines Produkt fertigzumachen, als einen Plan für ein großes Produkt zu entwickeln und es aber nur halb fertig stellen zu können.
  • Denn die überschüssigen Backlog-Items müssen auch gewartet werden. Diese Wartung benötigt viel Zeit. Zeit, die dem Team dann noch zusätzlich zur Umsetzung des Plans fehlt.

Beschreibung des Antipatterns:

  • Oft sammeln sich im Laufe einer Produktentwicklung User-Stories im Backlog an, die in naher Zukunft nicht umgesetzt werden oder nicht mehr verwendet werden können.
  • Sie liegen als Zombie-User-Stories im Backlog und vegetieren vor sich hin.

Warum ist das schlecht?

  • Diese veralteten Backlog-Items haben schon bei der Erstellung Zeit und somit Budget gekostet, kosten aber allein durch ihre Existenz dem Team regelmäßig Zeit und können zu Verwirrungen und Fehlern führen.
  • Das Backlog dient dem Product-Owner bei der täglichen Ausrichtung der Produktentwicklung an der Produktvision. Der Product-Owner arbeitet daher täglich mit dem Backlog und muss die User-Stories somit ständig lesen und einen Überblick behalten. Dies wird jedoch bei steigender Anzahl der PBIs im Backlog bedeutend schwieriger.
  • Weiters steigt die Komplexität des Backlogs durch das Wachstum laufend an.
  • Zudem muss auch das Team das Backlog bei der Sprint-Planung und den Refinements gemeinsam mit dem Product-Owner überarbeiten und sich ständig danach orientieren. Ist es zu groß, kostet dies unnötig Zeit und ist eine zusätzliche Fehlerquelle.

Verbesserungen:

  • Die beste Strategie ist es diese User-Stories erst gar nicht im Backlog anzulegen.
  • Da dies jedoch oft nicht möglich ist, ist es ratsam von Zeit zu Zeit durch das gesamte Backlog zu gehen und User-Stories mit der Vision und dem Produktstand abzugleichen und veraltete oder nicht mehr passende Backlog-Items zu entfernen.
  • Denn oft ändern sich im laufe des Projekts die Prioritäten oder die Vision des Produkts und somit werden zu weit im Voraus geplante PBIs obsolet.

Beschreibung des Antipatterns:

  • Das Team und der Product-Owner legen Backlog-Items komponentenorientiert an. Das heißt, sie spalten die Aufgabe horizontal in einzelne Komponenten, Technologieschichten oder Module, statt vertikal, also featureorientiert zu arbeiten.

Warum ist das schlecht?

  • Diese komponentenorientierte Aufteilung führt dazu, dass plangetrieben vorgegangen werden muss und sich im Team Spezialisierungen herausbilden oder festigen, anstatt gemeinsam eine Shared-Code-Ownership zu entwickeln.
  • Die Testbarkeit leidet, es wird viel Aufwand in Mocking gesteckt und viel Schnittstellen-Code geschrieben, um parallel entwickeln zu können.
  • Der Mehrwert wird in der Regel bei Umsetzungen erst dann erzeugt, wenn ein Feature beim User ankommt. Durch Komponenten-Backlog-Items wird dies verhindert und nach hinten hinausgeschoben.
  • Features sind für den User somit erst dann sichtbar, wenn das Team die Oberfläche dazu fertiggestellt hat und alle Komponenten miteinander interagieren.
  • Es müssen PBIs durch den Product-Owner und die Stakeholder „abgenommen“ werden, die aus Sicht des Users noch keinen Mehrwert liefern.

Verbesserungen:

  • Product-Backlog-Items müssen featureorientiert geschrieben werden.
  • Das Team sollte durch den Scrum-Master ermutigt werden, interdisziplinär zusammen zu arbeiten.
  • Der Teamgeist muss gestärkt werden und dem Team aufgezeigt werden, dass Software nur dann einen Mehrwert hat, wenn der Wert auch beim User ankommt.
  • Oft entstehen solche Product-Backlog-Items, weil der Product-Owner sehr technisch denkt oder das Team oder die Software-Engineering-Organisation den PO dazu drängen, die Product-Backlog-Items so zu schreiben.
  • Des Weiteren müssen Scrum-Teams interdisziplinär aufgestellt sein. Sie müssen alle Aufgaben aus sich heraus lösen können, ohne Abhängigkeiten zu anderen Teams oder organisatorischen Einheiten zu haben. Sollte dies nicht der Fall sein, muss der Scrum-Master intervenieren.

Beschreibung des Antipatterns:

  • Das Team schätzt aus dem Bauch heraus nimmt sich mehr und mehr Sicherheitspuffer.
  • Die umgesetzten Story-Points pro Sprint werden mehr und mehr, die Wertsteigerung für den Enduser bleibt aber spürbar gleich oder wird schlechter.
  • Oft werden die Aufgaben aufgrund der steigenden Komplexität auch immer schwieriger. Ein Faktor, der die Komplexität ansteigen lässt, sind technische Schulden die angehäuft werden und nicht beseitigt werden.

Warum ist das schlecht?

  • Story-Points können sich im Laufe der Zeit verändern, nehmen sie jedoch ständig und schleichend zu, so führt dies dazu, dass Kennzahlen, Schätzungen und Planungen nicht mehr akkurat funktionieren und nach geschätzt werden müssen.
  • Ein Zusatzaufwand entsteht, der vermeidbar wäre.
  • Oft rührt dieses Antipattern daher, dass das Team neben der eigentlichen Entwicklung des Features auch noch zahlreiche zusätzliche Tätigkeiten und Implementierungen machen muss.
  • Oftmals liegt diese Inflation auch an angehäuften technischen Schulden, die dem Team nun zum Verhängnis werden und Zeit kosten.

Verbesserungen:

  • Das Team sollte laufend, Sprint für Sprint, technische Schulden aufräumen und keine neuen machen.
  • Es sollte auf Clean Code Principles achten und vor allem auf Testautomatisierung und saubere Architektur setzen.
  • Unit-Tests und Integrationstests nehmen dem Team viel Zeitaufwand fürs Testen und für die Fehlersuche ab und zwingen das Team dazu, sauber zu programmieren.
  • Das Team sollte auf jeden Fall zum Schätzen eine Referenz-Story verwenden. Diese Referenz-Story muss immer die gleiche bleiben und darf nicht gewechselt werden.
  • Zur besseren Einordnung größerer PBIs sollte das Team auch andere Schätzverfahren wie Magic-Estimations verwenden.

Beschreibung des Antipatterns:

  • Das Team will zwar agil arbeiten und Scrum verwenden, schätzt aber alle User-Stories in Stunden, weil es der Product-Owner oder ein Manager so braucht.
  • Dabei berücksichtigt das Team hohe Sicherheitspuffer, damit es bei den einzelnen Product Backlog Items unterhalb der Schätzung liegt.
  • Denn meist werden die geschätzten Stunden mit den tatsächlich geleisteten Stunden verglichen und sofern es Überschreitungen gibt, wird exzessiv darüber diskutiert, warum diese Mehrstunden zustande kamen.

Warum ist das schlecht?

  • Dieses Antipattern ist schlecht, weil eine direkte Verknüpfung zwischen den geschätzten Stunden und den Arbeitsstunden der Teammitglieder gemacht werden kann.
  • Doch eine Schätzung ist und bleibt immer eine Schätzung und es macht einen Unterschied, wer ein Ticket umsetzt. Denn ein Team ist meist divers und jedes Teammitglied hat seine Stärken und Schwächen. Daher ist die Umsetzungsgeschwindigkeit von Teammitglied zu Teammitglied sehr unterschiedlich.
  • Um diese Unterschiede auszugleichen, werden die Schätzungen mit hohen Sicherheitspuffern gemacht. Dies ist jedoch nicht zielführend, weil dadurch viel Pufferzeit in den Sprint mit eingeplant wird.
  • Das parkinsonsche Gesetz kann auf diese Pufferzeiten wirken. Dieser psychologische Effekt führt dazu, dass für die Arbeiten auch genauso viel Zeit benötigt wird, wie geschätzt wurde. Die Effizienz des Teams leidet also durch die Pufferzeiten.
  • Werden die geleisteten Stunden mit den geschätzten verglichen, so führt dies unausweichlich zu Konflikten zwischen Team und Management und dazu, dass noch mehr Pufferzeiten berücksichtigt werden müssen.
  • Daraus folgt eine Verlangsamung der Durchlaufzeit einer User-Story, weil gute Schätzungen ausgiebige Beschreibungen, Designs und Lösungskonzepte benötigen, die vor der Schätzung gemacht werden müssen. Dies führt wiederum zu gestiegenen Budgetbedarf.

Verbesserungen

  • Schätzungen über Stunden geben nur eine Scheinsicherheit. In Wirklichkeit wird dadurch nur der Prozess langsamer und das Team benötigt mehr Zeit und mehr Budget.
  • Das Thema sollte mit dem Product-Owner oder Manager diskutiert werden, mit dem Ziel, in Story-Points zu schätzen und vertrauen in das Team und den Scrum-Prozess zu stecken.
  • Um Vertrauen zu erzeugen, sollte der Product-Owner oder Manager am Scrum-Prozess teilhaben und beispielsweise Reviews nutzen, um den Fortschritt des Projektes selbst zu erfahren.
  • Eine Umrechnung in geplante Zeit kann mittels bereits vorhandener Velocity und geschätzter Story-Points hergeleitet werden.

Beschreibung des Antipatterns:

  • User-Story, Szenarien und Spezifikationen sind oft das, was Product-Backlog-Items intuitiv immer aufweisen. Akzeptanzkriterien werden aber oft vergessen.
  • Bei diesem Antipattern werden Akzeptanzkriterien in einem überwiegenden Teil der PBIs des Backlogs nicht verwendet.
  • Meist sind die Akzeptanzkriterien auch nicht Teil der DoR des Teams oder das Team achtet zumindest nicht darauf.

Warum ist das schlecht?

  • Fehlende Akzeptanzkriterien führen dazu, dass für die Umsetzung keine klaren Abnahmekriterien definiert werden können.
  • Es können auch keine klaren Testfälle erstellt werden und auch keine Extremfälle systematisch abgetestet werden.
  • Nichtfunktionale Abnahmekriterien wie Ladezeiten etc. werden ebenfalls nicht oder nur zufällig berücksichtigt.
  • Die Qualität des Produkts kann dadurch stark leiden und dies kann zu Mehrkosten führen.
  • Durch fehlende automatisierte Tests wird außerdem mehr und mehr technische Schuld aufgetragen und die Entwicklungsgeschwindigkeit geht Zunehmens zurück.

Verbesserungen:

  • Akzeptanzkriterien sind Bestandteil der Definition of Ready und erweitern die Definition of Done
  • Akzeptanzkriterien müssen in der Beschreibung jedes PBIs vorkommen.
  • Gute Akzeptanzkriterien werden aus Sicht des Users geschrieben und sind Bedingungen, die das Feature aufweisen muss, um die Bedürfnisse des Users voll und ganz zu befriedigen.
  • Gute Akzeptanzkriterien sind außerdem ein klarer Indikator, wann ein Feature „fertig“ ist, sie führen zu einem besseren Verständnis für die User-Story und beseitigen Unklarheiten.
  • Aufgrund guter Akzeptanzkriterien können Testfälle definiert oder sogar automatisierte Tests geschrieben werden.
  • Es werden vor allem auch Extremfälle und Spezialfälle in Akzeptanzkriterien berücksichtigt.
  • Der Product-Owner sollte immer gemeinsam mit dem Team im Refinement die Akzeptanzkriterien finalisieren oder sogar erstellen.
  • Gute Akzeptanzkriterien sichern sowohl Product-Owner als auch das Team ab, dass die User-Story richtig verstanden wird und das Feature richtig umgesetzt wird.
  • Wichtig dabei ist aber auch, dass nicht zu viel Arbeit upfront in Akzeptanzkriterien gesteckt wird, da sonst die positiven Effekte der Agilität verloren gehen.

Beschreibung des Antipatterns:

  • Product-Backlog-Items werden mit minimalem Aufwand erzeugt.
  • Meist bestehen sie nur aus einem Titel, ab und zu befindet sich auch ein kurzer Satz in der PBI-Beschreibung.

Warum ist das schlecht?

  • Durch die fehlenden Informationen dauern Refinements sehr lange, weil PBIs erst richtig verstanden und ausspezifiziert werden müssen.
  • Oft geht dieses Antipattern auch damit einher, dass sich der Product-Owner nur kurz angebunden ist und sich ansonsten abseits der Refinements keine Zeit nimmt.

Verbesserungen:

  • Dem Product-Owner muss klar gemacht werden, dass agil zwar heißt „Kommunikation und Zusammenarbeit über Dokumentation“, aber dass das nicht heißt, dass es keinerlei schriftliche Doku oder Spezifikationen gibt.
  • Eine Definition of Read muss erstellt werden, oder falls es sie bereits gibt, muss diese eingehalten werden.
  • Das PBI muss so gut dokumentiert sein, dass es, wenn es im nächsten oder übernächsten Sprint eingeplant werden soll, wieder leicht verständlich ist und es zu keinen Missverständnissen kommen kann.

Beschreibung des Antipatterns:

  • Copy-Paste-Backlog-Items entstehen, wenn der Product-Owner Spezifikationen oder Anforderungsdokumente eins zu eins ins Backlog überführt.
  • Es entstehen PBIs die meist nicht die DoR erfüllen und auch nicht der Produktlinie folgen.

Warum ist das schlecht?

  • Werden die PBIs nur durch Copy-Paste Aktionen des Product-Owners erstellt, wird viel Arbeit vom Product-Owner in das Refinement zum Team verlagert.
  • Die Backlog-Items werden vom Team dann oft nicht verstanden denn sie liefern meist zu wenig Kontext im Bezug zum Produkt.
  • Werden Teilaspekte im Refinement-Meeting übersehen, so muss das Team entweder Rücksprache zum PO halten was Zeit kostet und zu Multitasking führt, oder es muss selbst Produktentscheidungen treffen.
  • Copy-Paste-PBIs sind meist schlecht zu schätzen und beinhalten ein höheres Produktrisiko.

Verbesserungen:

  • Der Product-Owner muss sich der Tatsache bewusst sein, dass ein reines Copy-Paste-PBI nicht ausreicht, um ein erfolgreiches Produkt zu erstellen.
  • Der Scrum-Master daher muss dem Product-Owner ggf. auf sein Fehlverhalten aufmerksam machen.
  • Der Product-Owner sollte die PBIs bereits bevor diese ins Refinement-Meeting kommen soweit ausspezifiziert haben, dass die Anforderungen zur Produktstrategie/Produktlinie passen und das Warum und Was klären.

Beschreibung des Antipatterns:

  • Das Team und der Product-Owner strukturieren das Backlog nicht.
  • PBIs sind nicht nach Priorität sortiert.
  • Es werden keine Granularitätsstufen verwendet (Epics, Features, PBI)
  • Dies hat die Konsequenz, dass das Team keinen „Fahrplan“ erkennt und oft nicht weiß was als nächstes im nächsten Sprint zu tun ist.

Warum ist das schlecht?

  • Dieses Antipattern kann bedeuten dass es entweder gar keine Produktstrategie gibt, oder dass es der Product-Owner nicht schafft, diese Strategie im Backlog abzubilden. Das hat sehr negative Konsequenzen, denn dadurch wird das Produkt ohne diese Strategie entwickelt. Es werden gegebenenfalls Features umgesetzt die vom User nicht benötigt werden. Somit entstehen erhebliche Kosten die keinen Mehrwert und somit kein Return on Investment bringen.
  • Durch die fehlende Struktur sind Planung, Orientierung und Umsetzung von Sprints schwieriger und Zeitaufwändiger.
  • Es kommt öfter zu Unterbrechungen der Sprints oder zu kurzfristigen Umplanungen während des Sprints.
  • Dies Umplanungen stellen ein eigenes Antipattern dar.

Verbesserungen:

  • Es ist ratsam, das Product-Backlog immer nach Priorität zu sortieren und diese Sortierung regelmäßig zu machen.
  • Das Team muss immer wissen, was die Vision ist und welche grob zusammengefassten Themenblöcke als Nächstes gemacht werden können.
  • Agilität heißt nicht planlos zu implementieren, sondern anpassungsfähig zu sein und Pläne ändern zu können.
  • In Refinement-Meetings können größere Blöcke in kleinere handlichere PBIs zerlegt werden.
  • Ein User-Story-Mapping Workshop kann dabei helfen, die Vision zu erarbeiten und den Backlog in grobe und feine Items aufzuteilen.

Beschreibung des Antipatterns:

  • Das Team verwendet keine Spikes, um technische Unsicherheiten zu minimieren und fehlendes Wissen aufzubauen.
  • Das Backlog beinhaltet keine expliziten Spike Tickets.
  • Recherche und Experimente müssen in Implementierungstickets geschätzt werden.

Warum ist das schlecht?

  • Backlogs, die keine oder wenig Spikes aufweisen zeigen meist Probleme in der Kommunikation und Transparenz von Scrum-Projekten auf.
  • Spikes sind dafür gedacht, dass das Team technische Dinge ausprobieren, erforschen, und nachrecherchieren kann.
  • Ein Beispiel: Selbst relativ „normale“ Features wie Reports benötigen oft Spikes, damit das Team herausfinden kann, ob die gegebene Charting-Library die Anforderungen des Produkts erfüllt und die gewünschten Features umsetzen kann.
  • Hat ein Team keine expliziten Spikes, geht es mit dem Thema „fehlendes Wissen“ nicht offen um.
  • Es werden dann Zeiten zum Recherchieren und Ausprobieren in Feature-Entwicklungstickets eingeschätzt, Unsicherheiten nicht kommuniziert, Sprintziele gefährdet und keine Fehlerkultur und Kommunikationskultur gelebt.
  • Somit leidet auch die Transparenz, weil oft nicht klar ist, warum ein gewisser Task länger dauert als eigentlich geschätzt/geplant.

Verbesserungen:

  • Der Scrum-Master muss sich hier einsetzen und über die Fehler und Forschungskultur reden.
  • Es müssen Spikes explizit kommuniziert und eingeplant werden.
  • Im Team muss die Gewissheit vorherrschen, dass Recherchen und das Forschen und Entwickeln von Lösungskonzepten ebenfalls Teil der Lösung und des Projekts sind.
  • In der Retrospektive können solche Dinge explizit angesprochen werden und gemeinsam mit dem Team und dem PO kann der Scrum-Master versuchen, hier einen Weg zu definieren der für das gesamte Team gangbar ist.

Beschreibung des Antipatterns:

  • Das Backlog wird dazu genutzt, alle möglichen Ideen, die der PO zum Produkt hat, in Form von Backlog-Items festzuhalten.
  • Jede neue Idee des Product-Owners wird als PBI einfach ins Backlog gelegt und stichwortartig beschrieben.

Warum ist das schlecht?

  • Das Backlog ist dementsprechend riesig, chaotisch und schlecht priorisiert.
  • Die Backlog-Items sind auch in sehr unterschiedlichen Größen vorhanden und weisen unterschiedliche Qualitäten in den Anforderungen und der Dokumentation auf.
  • Das Team und der Product-Owner haben keinen Überblick über das gesamte Backlog.
  • Dadurch entstehen Fehler und die Arbeiten am Backlog erschweren sich.

Verbesserungen:

  • Der Scrum-Master sollte den Product-Owner auffordern seine Ideen in einem anderen Tool zu verwalten und nicht das Backlog zu verwenden.
  • Das bereits aufgeblasene Backlog muss gemeinsam im Team durchgearbeitet werden.
  • Es können verschiedene Backlog-Bereiche oder Strukturierungsmaßnahmen wie Epics, Features verwendet werden, um vorhandene PBIs zu strukturieren.
  • Das Ziel muss ein schlankes, agiles Backlog sein, welches überschaubar bleibt und maximal 2-3 Sprints in voraus geplant ist.

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: