Eine der besten Methoden, agile Produktentwicklung zu sabotieren, ist, das Backlog zu vermurksen. In unserer interaktiven Präsentation am PO&RE Days gaben Stephan Adler und ich ein paar Tipps, wie man trotz dieser Sabotageversuche ein marodes Backlog vermeiden kann.

1. @SwissQ
Stephan Adler, Chris Wolf
How to f*** up your Backlog
European PO & RE Day

2. Beliebte Situationen …
Ablehnen der Implementierung beim Review
mit nachvollziehbaren Argumenten.
A
Sprint-Review schlecht besucht wegen zu
technischer Storys.
Hoch detaillierte User Storys
Skalierte Priorisierung ist inkonsistent
Storys werden nicht fertig aufgrund
Verfügbarkeit & Abhängigkeiten
B
C
D
E
Just-in-Time: Produktbacklog = Sprintbacklog
F
Initiales Backlog = Alle User Storys aus dem
Produktkonzept
Die Summe aller Storys ist das Epic (Story
Points)
Storys mit vielen Abhängigkeiten zu externen
Personen
G
H
I

3. Ablehnen der Implementierung beim Review
mit nachvollziehbaren Argumenten.
Situation
Beim Review werden
Implementierungen von Storys oft
abgelehnt.
Die Argumente von Business oder
dem Product Owner sind
nachvollziehbar.
Das Team muss die
Implementierung ändern.
Was tun?
(1) Kein Problem, dazu machen wir ja
Iterationen.
(2) Definition-of-Ready besser
durchsetzen.
(3) Akzeptanzkriterien schärfen und
mit dem Owner verifizieren.
(4) Prototypen (z.B. GUI) erstellen
und vor dem Sprint oder am
Sprintanfang abstimmen.
A
European PO & RE Day - Juni 2021
Auflösung
Business hat wahrscheinlich keine
richtige Vorstellung, was sie möchten.
Wiederholte Implementierung ist
Verschwendung.
DoR durchsetzen ist oft schwierig.
Detaillierung der AKs zwingt
Business, sich genauer
festzulegen.
Prototyen erleichtern, sich
vorzustellen, was man will

?



4. Sprint-Review schlecht besucht wegen zu
technischer Storys.
Situation
Das Team liefert in 2 Wochen
Sprints und die User Storys sind so
geschnitten, dass sie innerhalb des
Prints fertig werden. Einige der
Storys betreffen dann eher
technische Aspekte, da es trotz
kleiner Storys zu lange dauert E2E
zu entwickeln.
Die Kunden und Stakeholder
kommen nicht zur Sprint Review,
weil sie aufgrund zu technischer
Storys den Wert der Demo nicht
sehen.
Was tun?
(1) Sprint-Länge vergrössern
(2) Prozess-Fluss optimieren
(3) Storys besser schneiden
(4) Kanban einführen
(5) Teams besser aufstellen
(6) Team im Präsentieren von
Resultaten coachen
B
European PO & RE Day - Juni 2021
Auflösung
Kurze Sprints nur zu machen weil es
"agiler" ist, ist Blödsinn. Nur wenn ich
in der Review gutes, relevantes
Feedback erhalte, macht sie Sinn..
Kurzfristig die Sprints verlängern
Prozess optimieren, automatisieren
oder entschlacken, falls möglich
Storys konsequent schneiden
(kleiner, nicht kürzer)
Kanban und bessere
Teamaufstellung fixen in diesem
Fall nicht das Feedbackproblem

?
?




5.    
   
   

Storys werden nicht fertig aufgrund
Verfügbarkeit & Abhängigkeiten.
Situation
Am Ende vom Sprint sind viele
Storys des Sprintbacklogs noch
nicht beendet.
Es stellt sich heraus, dass
Teammitglieder während des
Sprints kurzfristig andere
Aufgaben erledigen mussten.
Weiterhin blockieren
Abhängigkeiten zu anderen Teams,
die zwar bekannt waren aber trotz
Zusagen nicht eingehalten wurden,
den Fortschritt.
Andere Teams sind aber nicht von
uns abhängig.
Was tun?
(1) Verfügbarkeit und damit
Sprintbacklog verkleinern.
(2) So lange sich niemand beschwert,
kann man das ignorieren.
(3) Von den anderen Teams
verlangen, dass sie bei
Abhängigkeiten ihre Zusagen
einhalten.
(4) Von Scrum auf Kanban umstellen.
C
Auflösung
Hier ist es wichtig, die Ursache der
Probleme detaillierter anzuschauen..
Realistische Einschätzung der
Verfügbarkeit ist wichtig. Den
Sprint mit niedrigerer
Verfügbarkeit planen und Stretch-
Goals hinzufügen.
Agile basiert auf Vertrauen,
Transparenz und Commitment.
Das sollten auch die anderen Team
beachten.
Wenn die Aufgaben innerhalb des
Teams und nach aussen keine
Synchronisation benötigen, kann
Kanban die bessere Methodik sein.
?

?
?
European PO & RE Day - Juni 2021

6. Hoch detaillierte User Storys.
Situation
Hoch detaillierte User Storys, eine
für die Anzeige eines Feldes, eine
für die Eingabe, eine für das
Löschen.
Die Akzeptanzkriterien beschreiben
die genaue Grösse (sichtbare
Zeichen) des Feldes und die exakte
Feldvalidierung. Die Entwicklungs-
firma will es so.
Was tun?
(1) Teamzusammensetzung stärken
(2) Definition of Done verbessern
(3) Aufhören, mit User Storys zu
arbeiten
(4) Mitarbeiter schulen
(5) Noch detaillierter aufschreiben
und Entwicklung nach Indien
outsourcen
D
European PO & RE Day - Juni 2021
Auflösung
Ist eine User Story eine umbenannte
"Requirements Spezifikation", dann
habe ich den Gedanken von
kompetenten, selbst organisierten,
E2E Teams aufgegeben.
Teams so zusammensetzen, dass
ich die notwendigen Kompetenzen
im Team habe
DoD schärfen, so dass es für
gängige Ansätze eine Konvention
gibt
Alternativ, sollten Verträge und
Umstände es nicht anders
zulassen: klassische mit
Spezifikationen arbeiten und nicht
Agilität vortäuschen


?
?
?
Als Nutzer hätte ich gerne ein Eingabefeld für
den Vornamen, …
AK:
• Das Feld muss 30x150px gross sein.
• …

7. Skalierte Priorisierung ist inkonsistent.
Situation
Eine Analyse der Backlogs zeigt,
dass die Priorisierung im Team-/
Train-Backlog nicht zu der im
Portfolio passt
Es wird nicht an den hoch
priorisierten Portfolio Epics
gearbeitet.
Was tun?
(1) SAFe einführen und die Rolle des
Business Owners sauber
ausfüllen.
(2) Klare Verantwortlichkeit und
Rahmenbedingungen für die
Priorisierung schaffen.
(3) Hohe Transparenz und
Feedbackprozesse sicherstellen.
(4) Team Input auf Portfolio Level
stärker einbringen.
(5) Team Backlogs durch das Portfolio
priorisieren und abnehmen
lassen.
E
European PO & RE Day - Juni 2021
Auflösung
Was offensichtlich fehlt ist ein
gegenseitiger Austausch und
Transparenz, so dass die
gegenseitigen Einschätzungen
frühzeitig geklärt werden.
Transparenz stärken, alle Backlogs
und die Verlinkung ist sichtbar
Sicherstellen, das der Input der
Teams auf Portfolio Level mit
einfliesst und vice versa
SAFe: Das ist der Job der Business
Owner: coacht sie zum Big Room
Planning zu kommen
Sicher nicht: Team-
Micromanagement durch die
Geschäftsleitung.
?
?

?


8. Just-in-Time: Produktbacklog = Sprintbacklog
Situation
Am Sprintende ist immer praktisch
auch Produkt-Backlog-Ende.
Was tun?
(1) Nichts tun, Just-in-Time ist die
Kür
(2) Anderen PO finden
(3) PO sollte andere Aufgaben
abgeben
(4) Proxy-PO einführen als
Unterstützung
(5) Team unterstützt stärker bei der
Erarbeitung der Storys
(6) Kanban einführen
A
European PO & RE Day - Juni 2021
Auflösung
Habe ich lieber einen guten PO mit
wenig Zeit, oder einen Proxy PO mit
viel Zeit? Kurzfristig kann und sollte
ein gutes Team einen PO stark
entlasten
Kanban verringert den Druck alles
zur Sprint-Planung bereit zu
haben.
Längerfristig: PO organisatorisch
entlasten oder ersetzen, aber nicht
durch einen Proxy

?
?




9. Initiales Backlog = Alle User Storys aus
dem Produktkonzept
Situation
Es wurde ein vollständiges
Produktkonzept erarbeitet.
Das Konzept wurde 1:1 in Features
und User Storys geschnitten
Alles wurde in Jira wurden die
Backlog-Items dokumentiert.
Wir enden mit rund 400 User
Storys und einem komplett
unübersichtlichen Backlog, das
gemanagt werden sollte.
Was tun?
(1) Kein Produktkonzept mehr
erstellen
(2) Epics aus dem Konzept ableiten,
priorisieren, Refinement
(3) Eine Storymap schafft Übersicht
(4) Das ist OK, aber konsequentes
Nachführen der User Storys ist
wichtig
A
European PO & RE Day - Juni 2021
Auflösung
Nehmen wir mal an, es braucht das
Konzept (Budget, Regulator) - danach
sollte trotzdem ein sauberes Backlog
geführt werden - DEEP (Detailed
appropriately, Estimated, Emergent,
Prioritized)
Nur die Top Level Themen/Epics
aus dem Konzept ins Backlog
aufnehmen, priorisieren und dann
Refinement auf der hohen Priorität
Storymaps unterstützen die
Übersichtlichkeit stark
Alle Storys auf einmal zu erstellen
und bei allen Änderungen
nachzuführen ist die Kombination
der Worst Practises aus agilem
und traditionellem RE


?


10. Storys mit vielen Abhängigkeiten zu externen
Personen
Situation
Ein Scrum Team ist häufig auf externe
Personen oder Prioritäten
angewiesen, die auch nicht unbedingt
in einem agilen Team organisiert sind.
Operative Ressourcen
Stark gefragte Spezialisten (der da
für das SAP Modul X zuständig ist)
Zuarbeit von einem Vendor /
Fachabteilung
Was tun?
(1) Eine Story mit Abhängigkeit
gehört nicht in den Sprint
(2) Klare Zusagen einholen, sonst
repriorisieren
(3) Abhängigkeiten/Kompetenzen
temporär ins Team holen
(4) Auflösung der Abhängigkeit als
eigener Backlog-Eintrag
(5) Alle Storys mit Abhängigkeiten
sind Stretch-Goals
(6) Als Blocker markieren und
eskalieren
(7) Kanban einführen, Spalte für
"blockierte" Storys anlegen
A
European PO & RE Day - Juni 2021
Auflösung
Ein Commitment für ein Sprint
Backlog, macht nur Sinn, wenn das
Team ausreichend Kontrolle über die
Erreichbarkeit hat.
Abhängigkeiten müssen geklärt
sein, sonst gehören sie nicht ins
Commitment für den Sprint.
Teamkompetenz stärken,
Ressourcen dazu holen
Notfalls die Storys mit
Abhängigkeiten erst angehen,
wenn die Abhängigkeiten erledigt
sind (als separater Tasks ohne
Commitment)
?


?
?


Blocked
Blocked
Blocked

11. Die Summe aller Storys ist das Epic (Story
Points)
Situation
Ein Epic wird geschätzt.
Später wird die Epic in Storys
geschnitten, die Storys werden
geschätzt.
Das Management fordert, dass wir
keine "Inflation in der Schätzung"
haben und dass die Summe der
Story-Schätzungen die Schätzung
des Epics nicht überschreiten darf.
Schätzung Vorgabe
31 SP 31 SP
Was tun?
(1) Das ist eine angemessene
Forderung des Managements
(2) Management austauschen, da
diese Forderung Blödsinn ist
(3) Management weiterbilden
(4) Puffer in die Epic-Schätzung
einbauen
(5) Regelmässige "Clean-up Sprints"
einführen, zum Fertigstellen der
Storys aus vorherigen Sprints
Anm.: Integrations/Innovations
Sprints, vor allem im skalierten
Umfeld sind etwas anderes.
A
European PO & RE Day - Juni 2021
Auflösung
Schätzung sind primär in
Verantwortung der Teams. Das
Management/Business sollte sich auf
den gelieferten Wert konzentrieren
Schätzungen, Velocity und Sprint
Commitments sind keine
Management Tool
Wir lernen kontinuierlich dazu,
Schätzungen müssen sich ändern
(dürfen)
Ein falscher Fokus des
Management erodiert Vertrauen
und Transparenz, genauso wie
Puffer und Clean-up Sprints (wir
nehmen unsere Schätzungen und
DoD nicht ernst)

?




12. https://swissq.it/downloads/product-engineering-poster/
Stephan Adler
Chris Wolf
Vielen Dank!

13. Kontakt
Zürich
SwissQ Consulting AG
Fraumünsterstrasse 16
CH-8001 Zürich
Tel. +41 43 288 88 40
Kontakt
Bern
SwissQ Consulting AG
Spitalgasse 37
CH-3011 Bern
Tel. +41 31 972 73 53