Software-Engineering Pattern und 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

1. Epic User-Stories

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

Verbesserungen:

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

2. Technical User-Stories

  • User-Stories kümmern sich nicht um das Was zu bauen ist und das Warum, sondern leider auch oder Großteiles um das Wie.
  • Der wirtschaftliche Mehrwert und der User werden ignoriert und haben wenig Bedeutung in der technischen User-Story

Verbesserungen:

  • Etablieren und einhalten der Definition of Ready,
  • Spezifizieren von Needs des Users
  • Betrachten der User-Stories aus Sicht des Users.
  • Verwenden von Personas in den User-Stories
  • Es können Story-Mapping Workshops durchgeführt werden, bei denen von der Vision Ziel und Stories abgeleitet werden und Personas in den Mittelpunkt gestellt werden.
  • Immer in Erinnerung rufen, dass die Software für den User und nicht für den PO erstellt wird.

3. UseCase Stories

  • User-Stories werden so lange vorbereitet und ausspezifiziert, dass das Team sie „nur mehr umsetzten“ braucht.
  • 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.

Verbesserungen:

  • 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

4. Priorisierung durch Stakeholder

  • 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.
  • Dies 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.
  • Ein guter PO muss „NEIN“ sagen können, und Priorisieren können.
  • Ein Produkt muss durchdacht werden und eine Priorisierung gewissenhaft gemacht werden.
  • Das Team muss trotz des vielen hin und her technische Schulden meiden.

5. Backlog-Wasserfallplanung

  • 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.
  • Meist weil der Scope bis zum Release fix ist und das Budget dementsprechend fixiert wird.

Verbesserungen:

  • Der Mehrwert von agilen iterativen inkrementellen Arbeiten scheint nicht im Team angekommen zu sein.
  • Hier scheint dem Team die agile Vorgehensweise nicht ganz klar zu sein. Der Scrum-Master sollte das Team und den Product-Owner coachen und erklären was der Unterschied zwischen Upfront-Planning und agilen explorativen inkrementellen produktentwickeln ist.

6. Upfront detailed Estimation

  • Das Scrum-Team beginnt den Sprint erst dann, wenn alle Backlog-Items im Backlog im Detail geschätzt wurden.
  • Es werden vor allem auch jene Backlog-Items geschätzt, die erst in den darauffolgenden Sprints umgesetzt werden können.
  • Diese Schätzungen benötigen viel an Vorausplanung, also Upfront-Aufwände die ggf. nicht benötigt werden, weil sich in der Zwischenzeit neuer Erkenntnisse ergeben oder Prioritäten ändern.

Verbesserungen:

  • Es sollten maximal 2 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.
  • Alle Arbeiten die Upfront gemacht werden verzögern die Auslieferung von Features und somit von Mehrwert, der beim User ankommt.

7. Big-Backlog

  • 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.
  • User-Stories werden definiert die vielleicht nie umgesetzt werden, so verschwendet der Product-Owner wichtige Zeit, die er mit dem Team verbringen könnte.

Verbesserungen:

  • Spezifikationen über 3 Sprints hinaus sind nicht sinnvoll. Es ist ratsam auf Qualität zu setzen als auf Quantität.
  • Es ist besser ein gutes kleines Produkt fertig zu haben als einen Plan zu haben für ein großes Produkt und es aber nur halb fertig gestellt zu haben.
  • Die Überschüssigen Backlog-Items müssen auch gewartet werden und diese Zeit fehlt dem Team dann auch noch zusätzlich.

8. Veraltete User-Stories

  • Oft sammeln sich im Laufe einer Produktentwicklung User-Stories im Backlog an die nicht mehr verwendet werden können. 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.

Verbesserungen:

  • Es ist ratsam, von Zeit zu Zeit durch das gesamte Backlog zu gehen und User-Stories mit der Vision und dem Produkt abzugleichen und veraltete oder nicht mehr passende Backlog-Items zu entfernen.

9. Komponenten-Backlog-Items

  • Das Team und der Product-Owner legen Backlog-Items Komponenten-Orientiert an, das heißt sie spalten die Aufgabe horizontal in einzelne Komponenten, Technologieschichten oder Module, statt vertikal also Feature-orientiert.
  • 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. Es müssen PBIs abgenommen werden die, aus Sicht des Users, noch keinen Mehrwert liefern.

Verbesserungen:

  • Product-Backlog-Items sollten 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.
  • Scrum-Teams müssen 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.

10. Estimation Inflation

  • 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

Verbesserungen:

  • laufend technische Schulden aufräumen und keine neuen machen.
  • auf Clean Code Principles achten.
  • zum Schätzen Referenz-Stories verwenden
  • verwenden Sie auch andere Schätzverfahren wie Magic-Estimations

11. Estimation in Workhous

  • 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 exzessiv diskutiert, warum diese Mehrstunden zustande kamen.
  • 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 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.

12. Fehlende Akzeptanzkriterien

  • User-Story, Szenarien und Spezifikationen sind oft das was Product-Backlog-Items intuitiv immer aufweisen. Akzeptanzkriterien werden aber oft vergessen.
  • 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 abgetestet werden
  • Nichtfunktionale Abnahmekriterien wie Ladezeiten etc. werden nicht betrachtet.

Verbesserungen:

  • Akzeptanzkriterien sind Bestandteil der Definition of Ready und erweitern die Definition of Done
  • Akzeptanzkriterien sollten bei allen 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 PO 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 und die Agilität verloren gehen.

13. Title-Only-Items

  • 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.
  • Refinements dauern sehr lange, weil PBIs erst richtig verstanden und ausspezifiziert werden müssen.
  • Der Product-Owner ist auch immer nur sehr kurz angebunden und nimmt sich keine oder nur wenig Zeit abseits der Refinements

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 eingehalten werden.
  • Das PBI muss so gut dokumentiert sein, dass es, wenn es im nächsten oder übernächsten Sprint eingeplant werden soll, leicht wieder verständlich ist und es zu keinen Missverständnissen kommen kann.

14. Copy-Paste-Backlog-Items

  • Copy-Paste-Backlog-Items entstehen, wenn der PO 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.
  • Die Backlog-Items werden vom Team nicht verstanden und liefern meist zu wenig Kontext im Bezug zum Produkt

Warum ist das Schlecht?

  • Werden die PBIs nur durch Copy-Paste Aktionen den POs erstellt, wird Arbeit vom PO in das Refinement und zum Team verlagert.
  • 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 meist ein höheres Produktrisiko

Verbesserungen:

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

15. Fehlende Backlog-Struktur

  • 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 heute nicht weiß was als nächstes im nächsten Sprint zu tun ist.

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

16. Keine-Spike-Kultur

  • 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, Sprint-Ziele 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.

17. Ideenspeicher für den Product-Owner

  • Das Backlog wird dazu genutzt alle möglichen Ideen, die der PO zum Produkt hat in Form von Backlog-Items festzuhalten.
  • Das Backlog ist dementsprechend riesig und leider oft auch 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 oder eventuell sogar auch niemand hat einen Überblick über das gesamte Backlog.

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.

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: