How to f... up your backlog - PO &RE Day
0 gefällt mir44 aufrufe
Das Dokument behandelt häufige Probleme bei der Implementierung und Verwaltung von Backlogs in agilen Teams, einschließlich unzureichender User Stories, fehlender Transparenz bei Priorisierungen und Herausforderungen durch externe Abhängigkeiten. Es werden verschiedene Lösungen vorgeschlagen, wie die Verbesserung der Definition von 'Done', die Optimierung von Prozessen und den Einsatz von Kanban. Insgesamt wird betont, dass agile Praktiken auf Vertrauen, Transparenz und klare Kommunikation angewiesen sind.
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