SlideShare ist ein Scribd-Unternehmen logo
@SwissQ
Stephan Adler, Chris Wolf
How to f*** up your Backlog
European PO & RE Day
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
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

?
✓
✓
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
✓
?
?



   ✓
   ✓
   ✓

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
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.
• …
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.
?
?
✓
?

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

?
?

✓
✓
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

✓
?

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
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)

?
✓


https://swissq.it/downloads/product-engineering-poster/
Stephan Adler
Chris Wolf
Vielen Dank!
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

Weitere ähnliche Inhalte

Ähnlich wie How to f... up your backlog - PO &RE Day

eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo GmbH
 
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen ProjektenCreasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
Creasoft AG
 
Manage Agile Konferenz - Wie wir ein eigenes Framework entwickelten und warum...
Manage Agile Konferenz - Wie wir ein eigenes Framework entwickelten und warum...Manage Agile Konferenz - Wie wir ein eigenes Framework entwickelten und warum...
Manage Agile Konferenz - Wie wir ein eigenes Framework entwickelten und warum...
Joël Krapf
 
Rails und Scrum in großen Projekten
Rails und Scrum in großen ProjektenRails und Scrum in großen Projekten
Rails und Scrum in großen Projekten
Phillip Oertel
 
Agile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von ScrumAgile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von Scrum
Zeljko Kvesic
 
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo GmbH
 
WUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick WinsWUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick Wins
guest60c1a2
 
DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...
DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...
DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...
Frank Düsterbeck
 
Agile Softwareentwicklung / User Stories
Agile Softwareentwicklung / User StoriesAgile Softwareentwicklung / User Stories
Agile Softwareentwicklung / User Stories
Stefan von Niederhäusern
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
QAware GmbH
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
Mayflower GmbH
 
Scrum checklist 2013
Scrum checklist 2013Scrum checklist 2013
Scrum checklist 2013
Hanser Update
 
Agents of D.E.V.O.P.S
Agents of D.E.V.O.P.SAgents of D.E.V.O.P.S
Continuous Integration / Deployment mit Jenkins CI
Continuous Integration / Deployment mit Jenkins CI Continuous Integration / Deployment mit Jenkins CI
Continuous Integration / Deployment mit Jenkins CI
Florian Bosselmann
 
Agile Ways of Working @ Migros
Agile Ways of Working @ MigrosAgile Ways of Working @ Migros
Agile Ways of Working @ Migros
Joël Krapf
 
About Dogs and Cats - über DevOps in großen Konzernen
About Dogs and Cats - über DevOps in großen KonzernenAbout Dogs and Cats - über DevOps in großen Konzernen
About Dogs and Cats - über DevOps in großen Konzernen
Stefan Bauer
 
Scrum Cheat Sheet (Jan 2012)
Scrum Cheat Sheet (Jan 2012)Scrum Cheat Sheet (Jan 2012)
Scrum Cheat Sheet (Jan 2012)
Michael Hübl
 
Agiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HECAgiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HEC
Christian Seedig
 
Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Mast...
Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Mast...Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Mast...
Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Mast...
Joscha Jenni
 

Ähnlich wie How to f... up your backlog - PO &RE Day (20)

eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
 
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen ProjektenCreasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen Projekten
 
Manage Agile Konferenz - Wie wir ein eigenes Framework entwickelten und warum...
Manage Agile Konferenz - Wie wir ein eigenes Framework entwickelten und warum...Manage Agile Konferenz - Wie wir ein eigenes Framework entwickelten und warum...
Manage Agile Konferenz - Wie wir ein eigenes Framework entwickelten und warum...
 
Rails und Scrum in großen Projekten
Rails und Scrum in großen ProjektenRails und Scrum in großen Projekten
Rails und Scrum in großen Projekten
 
Agile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von ScrumAgile softwareentwicklung am Beispiel von Scrum
Agile softwareentwicklung am Beispiel von Scrum
 
Einführung in SCRUM
Einführung in SCRUMEinführung in SCRUM
Einführung in SCRUM
 
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
 
WUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick WinsWUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick Wins
 
DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...
DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...
DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...
 
Agile Softwareentwicklung / User Stories
Agile Softwareentwicklung / User StoriesAgile Softwareentwicklung / User Stories
Agile Softwareentwicklung / User Stories
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
 
Scrum checklist 2013
Scrum checklist 2013Scrum checklist 2013
Scrum checklist 2013
 
Agents of D.E.V.O.P.S
Agents of D.E.V.O.P.SAgents of D.E.V.O.P.S
Agents of D.E.V.O.P.S
 
Continuous Integration / Deployment mit Jenkins CI
Continuous Integration / Deployment mit Jenkins CI Continuous Integration / Deployment mit Jenkins CI
Continuous Integration / Deployment mit Jenkins CI
 
Agile Ways of Working @ Migros
Agile Ways of Working @ MigrosAgile Ways of Working @ Migros
Agile Ways of Working @ Migros
 
About Dogs and Cats - über DevOps in großen Konzernen
About Dogs and Cats - über DevOps in großen KonzernenAbout Dogs and Cats - über DevOps in großen Konzernen
About Dogs and Cats - über DevOps in großen Konzernen
 
Scrum Cheat Sheet (Jan 2012)
Scrum Cheat Sheet (Jan 2012)Scrum Cheat Sheet (Jan 2012)
Scrum Cheat Sheet (Jan 2012)
 
Agiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HECAgiles Anforderungsmanagement bei HEC
Agiles Anforderungsmanagement bei HEC
 
Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Mast...
Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Mast...Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Mast...
Lust, Last, List? Ein Scrum Projekt reflektiert von Product Owner, Scrum Mast...
 

Mehr von Christoph Wolf

PMI CH AMM2023 - Bye Bye Project Manager - SwissQ.pptx
PMI CH AMM2023 - Bye Bye Project Manager - SwissQ.pptxPMI CH AMM2023 - Bye Bye Project Manager - SwissQ.pptx
PMI CH AMM2023 - Bye Bye Project Manager - SwissQ.pptx
Christoph Wolf
 
Testen hoch 10 - Für den Bahnverkehr der Zukunft
Testen hoch 10 - Für den Bahnverkehr der ZukunftTesten hoch 10 - Für den Bahnverkehr der Zukunft
Testen hoch 10 - Für den Bahnverkehr der Zukunft
Christoph Wolf
 
Design thinking erleben - PO&RE-Day 2019
Design thinking erleben - PO&RE-Day 2019Design thinking erleben - PO&RE-Day 2019
Design thinking erleben - PO&RE-Day 2019
Christoph Wolf
 
Build-in Quality!? SAFe® Testing im Finnova-Express (Swiss Testing Day 2017)
Build-in Quality!? SAFe® Testing im Finnova-Express (Swiss Testing Day 2017)Build-in Quality!? SAFe® Testing im Finnova-Express (Swiss Testing Day 2017)
Build-in Quality!? SAFe® Testing im Finnova-Express (Swiss Testing Day 2017)
Christoph Wolf
 
Iqnite Schweiz 2013: Requirements Validation & Requirements-based Testing bei...
Iqnite Schweiz 2013: Requirements Validation & Requirements-based Testing bei...Iqnite Schweiz 2013: Requirements Validation & Requirements-based Testing bei...
Iqnite Schweiz 2013: Requirements Validation & Requirements-based Testing bei...
Christoph Wolf
 
Business Analysis @ Sunrise - REConf CH 2010
Business Analysis @ Sunrise - REConf CH 2010Business Analysis @ Sunrise - REConf CH 2010
Business Analysis @ Sunrise - REConf CH 2010
Christoph Wolf
 

Mehr von Christoph Wolf (6)

PMI CH AMM2023 - Bye Bye Project Manager - SwissQ.pptx
PMI CH AMM2023 - Bye Bye Project Manager - SwissQ.pptxPMI CH AMM2023 - Bye Bye Project Manager - SwissQ.pptx
PMI CH AMM2023 - Bye Bye Project Manager - SwissQ.pptx
 
Testen hoch 10 - Für den Bahnverkehr der Zukunft
Testen hoch 10 - Für den Bahnverkehr der ZukunftTesten hoch 10 - Für den Bahnverkehr der Zukunft
Testen hoch 10 - Für den Bahnverkehr der Zukunft
 
Design thinking erleben - PO&RE-Day 2019
Design thinking erleben - PO&RE-Day 2019Design thinking erleben - PO&RE-Day 2019
Design thinking erleben - PO&RE-Day 2019
 
Build-in Quality!? SAFe® Testing im Finnova-Express (Swiss Testing Day 2017)
Build-in Quality!? SAFe® Testing im Finnova-Express (Swiss Testing Day 2017)Build-in Quality!? SAFe® Testing im Finnova-Express (Swiss Testing Day 2017)
Build-in Quality!? SAFe® Testing im Finnova-Express (Swiss Testing Day 2017)
 
Iqnite Schweiz 2013: Requirements Validation & Requirements-based Testing bei...
Iqnite Schweiz 2013: Requirements Validation & Requirements-based Testing bei...Iqnite Schweiz 2013: Requirements Validation & Requirements-based Testing bei...
Iqnite Schweiz 2013: Requirements Validation & Requirements-based Testing bei...
 
Business Analysis @ Sunrise - REConf CH 2010
Business Analysis @ Sunrise - REConf CH 2010Business Analysis @ Sunrise - REConf CH 2010
Business Analysis @ Sunrise - REConf CH 2010
 

How to f... up your backlog - PO &RE Day

  • 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)  ? ✓  
  • 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