Jutta Eckstein berät seit 1998 vor allem große Firmen und begleitet sie auf ihrem Weg zu mehr Agilität. Während des Retrospective Facilitatörs Gathering 2016 in Sagres habe ich ein Gespräch mit ihr aufgezeichnet.
Anfang und Begrüßung
00:00:00
Toby ist mittlerweile Agile Coach — Retrospective Facilitators Gathering — Austausch zur Ausrichtung von Retrospektiven.
Product Owner in großen agilen Umgebungen
00:06:01
Alignment der Ziele und Synchronisation — POs stimmen sich in der Mitte des Sprints ab — Technische Product Owner (Jutta versucht, techniklastige Product Owner zu vermeiden — lieber ehemalige Requirements Engineers, Fachleute) — Produktlinien-Entwicklung.
Definition of ready, wie geht man damit um?
00:19:32
Gemeinsames Verständnis vom gewünschten Outcome.
Abschweifung: Verzugskosten und Bauzinsen im Hausbau
00:22:57
Continuous Delivery — Wertstromanalyse sollte darauf achten, wie lange Anforderungen im Backlog liegen, bevor sie angefangen werden.
Abschließender Rat für Product Owner
00:27:02
Konkrete Überlegung vorab zur Qualität (Welche Qualität ist gefordert, welche wird bezaht?) .
00:00:00.000 Anfang und Begrüßung
00:03:58.000 Vorstellung Jutta Eckstein
00:06:01.000 Product Owner in großen agilen Umgebungen
00:12:29.000 Verzugskosten
00:19:32.000 Definition of ready, wie geht man damit um?
00:22:57.000 Abschweifung: Verzugskosten und Bauzinsen im Hausbau
00:27:02.000 Abschließender Rat für Product Owner
00:29:35.000 Verabschiedung
Ein Ausflug der agilen Produktentwickler in die Welt der Philosophie, nicht anderes kann man erwarten, wenn Patrick Breitenbach vom Soziopod zu Gast ist im Agilen Produktmanagement. Anlass war ein Treffen beim Soziopod Live Event in Hamburg, bei dem mir bewusst geworden ist, wie gut Poppers kritischer Rationalismus auf agile (oder "lean") Produktentwicklung passt. Diese Episode ist also als Einwurf zu verstehen, oder wie gesagt als Ausflug, nicht aber ohne konkrete Hilfestellungen im Alltag des Product Owners zu entwickeln.
Corinna Baldauf ist zu Gast. Sie ist bekannt durch den Retromaten, ein Tool zur leichteren Gestaltung von Retrospektiven, und hat alle Rollen der agilen Welt durchlebt. Gemeinsam betrachten wir, was eine agile Transition ist, warum der Begriff "Transition" eigentlich irreführend ist, und was dies für den Product Owner bedeutet.
Corinna arbeitet bei sipgate: Flexible Telefonie für zu Hause, unterwegs und das Büro.
Bernd Schiffer hat noch ein paar weitere Ansätze, wie agile Skalierung (Scaling Agile) in Unternehmen funktionieren kann, die im ersten Teil nicht drangekommen sind. Das schließen wir heute ab. Spannend am Ende die Frage: für wen ist Scaling Agile eigentlich eine Herausforderung? Denn: sobald man bei diesem Problem angekommen ist, sollten vorher eine ganze Reihe anderer Probleme (allgemeiner Entwicklungs-Workflow, Agil im Kleinen) gelöst sein, so dass die Skalierung gar nicht mehr so schwierig sein sollte.
ScALeD
00:08:56
(Scaled Agile Lean Development — Entstanden aus Missmut mit SAFE — geleitet durch Prinzipien: Autonomie, Meisterschaft, Zweck (Dan Pink) — hochperformante Teams) — Begeisterte Kunden, produktive Mitarbeiter, globale Optimierung (Abhängigkeiten reduzieren) — Handlungsanweisungen und Werte (Werte sind dazu da, Werkzeuge und Prozesse einzusortieren — "Prinzipien sind Brücken zwischen Werten und Praktiken" (Bernd)) .
Product Development Flow
00:21:38
(Buch von Don Reinertsen — Studieren, nicht lesen! — Don beweist, dass agile Prinzipien richtig sind mit schlüssigen Argumentationsketten — Aus der Lean Development Ecke, aber die Prinzipien sind allesamt für agile Skalierung zu empfehlen — Dezentraliserung von regelmäßigen Entscheidungen — Innovation sollte nicht zentralisiert sein) .
Holacracy
00:31:33
(bei Zappos — nach dem dezentralen Experimentieren sollte die Implementierung zentral entschieden werden) — Frische Ansätze:.
MAXOS
00:36:55
(Matrix of services — Genau wie die Technik in Microservices geteilt wird, passiert es auch mit Teams — Kleine Teams, Jedes mit eigener Vorgehensweise und Kultur — Google, Amazon, Facebook nutzen es — Blog post von Andy Singleton — Teams haben mindestens einen Service — Abhängigkeiten werden von Teams selbst entschieden — Nicht zu verwechseln mit Matrix-Organisation disziplinarisch/fachlich — Kultur muss nicht unbedingt konsistent sein, aber Schnittstellen müssen funktionieren — QA wird von Programmierern selbst gemacht — alle Tests werden automatisiert — Scrum und Agil sind zu langsam — keine Methode zum Kopieren) .
Wie skaliert man Werte?
00:57:13
(Frage: ist agil für alle Oranisationen hilfreich? Verschiedene Lager — "Too-big-to-fail Organisationen sollten nicht agil werden" (Bernd) — Agil setzt einen gewissen Level an Softwareentwicklung voraus — Auf dieser Stufe kann man direkt mit Prinzipien arbeiten und braucht keine konkreten Handlungsanweisungen — DAD hat als Verkaufsargument, dass man weniger Coaches braucht, weil die Dokumentation alles abdeckt) — Vielleicht muss man gar nicht skalieren (Vorher abklären: was soll durch die Skalierung erreicht werden — Wenn jemand Agile Skalierung als Problem nennt aber noch Probleme mit der Entwicklung selbst hat, sollte er diese vielleicht zuerst lösen) .
00:00:00.000 Intro
00:08:56.000 ScALeD
00:21:38.000 Product Development Flow
00:31:33.000 Holacracy
00:36:55.000 MAXOS
00:47:07.000 Scaling Scrum (Ansatz)
00:50:41.000 XSCALE
00:57:13.000 Wie skaliert man Werte?
01:07:13.000 Abschluss
Bernd Schiffer und ich wollen das Thema „Scaling Agile“ noch etwas abrunden, daher gibt es einen zweiten Teil zum Gespräch, das in Episode 12 angefangen hat. Ihr könnt live zuhören unter https://streams.xenim.de/pubkameraden/APM013/ oder hinterher zeitsouverän hier im Podcast.
Wir freuen uns übrigens über Fragen: einfach hier im Blog oder auf Twitter an @berndschiffer und @tobybaier!
Die meisten Veröffentlichungen zu Scrum, Kanban und anderen agilen Methoden konzentrieren sich auf die Situation mit genau einem Team. Dabei ist der Übergang zu agilen Methoden mit mehreren Teams alles andere als trivial, gerade für den oder die Product Owner. In dieser Episode erklärt Bernd Schiffer, was man hierzu alles machen kann. Bitte beachtet die Shownotes für Links und weitere Informationen. Wenn genügend Wünsche eintrudeln, dass wir die wegen Audio-Breakdown übersprungenen weiteren unstrukturierten sowie ganz neuen Modelle auch noch besprechen, machen wir einfach eine weitere Episode.
Skalierung
00:13:33
In den Firmen in denen Tobias bisher arbeitete, gab es nicht nur ein Entwicklungsteam — Herausforderungen bei mehreren Scrum-Teams — Vorgeschlagene Teamgröße: 9 Personen — Auch Teams mit 15 Leuten waren schon erfolgreich — Bei größeren Teams ist eine Spaltung sinnvoll — "Wenn man ein Team spaltet, hat man hinterher Zwei" (Tobias) — Product Backlog — Product Owner ist ein sehr anspruchsvoller Job — Lernen zu delegieren ist das A und O als Product Owner — "Ist Big Corporate ein Buzzword?" (Bernd) — Bei vielen Teams hat man eine Teamlandschaft.
Übergang zum agilen Produktmanagement
00:32:07
Firmen die auf agile umschwenken — Agiler Pilot — Projektbasiert statt teambasiert — Ein ranghoher Manager (Sponsor) hält den Rücken frei — Als Agiler Pilot sollte man nicht das beste Team verwenden — Wasserfallmodell — Flächendeckendes Ausrollen ist eine weitere Methode.
Herausforderungen bei der Zusammenarbeit mehrerer Agilen Teams
00:42:02
Gemeinsamen Backlog — Oft gibt es Abhängigkeiten bei mehreren Teams ('Large Scale Scrum-Methode' - hierachische Product Owner Struktur) — Bereichs Product Owner <> — Alternative PO Modelle — Gießkannenprinzip — Scrum Master.
Was ist SAFe?
01:18:02
Keine generelle Empfehlung von Bernd — Dean Leffingwell — RUP — SAFe Big Picture: Extreme Programming, Kanban, Scrum, ... (nichts für kleine Unternehmen: SAFe´s kleinste Einheit ist 50-150 Leute - Aglie Release Train) — "Endlich mal was los in diesem Podcast!" (Tobias) — "DAD ist eigentlich sowas wie SAFe, nur hats nicht so einen coolen Namen" (Bernd) — Evidence Based Management — "Geldverdienen an sich ist ja auch nichts Unanständiges" (Tobias).
00:00:00.000 Intro
00:00:28.000 Begrüßung
00:06:29.000 Was heißt Agile?
00:13:33.000 Skalierung
00:32:07.000 Übergang zum agilen Produktmanagement
00:42:02.000 Herausforderungen bei der Zusammenarbeit mehrerer Agilen Teams
01:09:44.000 Was ist Large Scale Scrum
01:18:02.000 Was ist SAFe?
01:40:57.000 Spotify-Ansatz
01:53:46.000 Weitere unstrukturierte Modelle
02:05:17.000 Outro
In dieser Episode geht es um elektronische und physische Taskboards (nicht etwa physikalische, wie ein verwirrter Podcaster behauptet). Was macht man mit Boards, wie viele Spalten braucht man, und was ist dieser Schneepflug?
Start und Begrüßung
00:00:00
Thema heute: Taskboards
00:00:51
"Das zentrale Element um sich abzustimmen" (Alex) — Eine Wand wo visualisiert wird, woran man arbeitet — physische Wand, Fenster, irgendeine Fläche — Karteikarten, auf denen die Aufgaben stehen — Wand bildet den Workflow ab: (arbeit kommt ins Team — wird bearbeitet — wird fertig und verlässt das Team) — Spalten und Zeilen (Zeilen für einzelne Karten, die von links nach rechts wandern) — Spalten: mindestens links "To-Do", Mitte "in progress", rechts "done" — weitere Spalten für z.B. Qualitätssicherung, Review, Live-Schaltung oder anderes — Taskboards im arabischen Raum: rechts nach links? — Exkurs: Gewohnheiten ändern um den Kopf fit zu halten (invert Y-Axis) — Toby sieht gesteigerte Komplexität am Board eher skeptisch — Spalten am Board können nie explizite Kommunikation ersetzen — "Das Minimum ist nicht immer das Optimum" (Alex) — 130 Tickets am Taskboard sind auch nicht sinnvoll — Es sollte sich lieber das Board der Realität anpasst, als die Realität dem Board — Indikator: wenn sich das Board nicht ändert, sollte man seinen Prozess und das Board überprüfen — Am Board hängen Karten mit Aufgaben, z.B. User Stories — Board dient der Gesprächsunterstützung beim Daily Stand-Up.
Zustandsvisualisierung
00:12:48
Anhand des Fortschritts der Karten von links nach rechts den Fortschritt im Sprint erkennen — Blocker auf den Karten visuell darstellen.
Schneepflug
00:15:52
Die obersten Karten sollten die wichtigsten sein und zuerst "nach rechts" wandern — Wenn Stories weiter unten zuerst bewegt werden, sollte man darüber nachdenken — Ersetzt möglicherweise auch das Burn Down Chart — Wenn man Dinge tut, die nicht hilfreich sind, sollte man sie sein lassen — Sprint-Ziel am Board hilft beim Fokussieren — Definition of Done und Ready (Vertrag, der beschreibt, wann eine Story in die nächste Spalte kann) — Achievements — Legende: was bedeuten Farben und Namenskürzel — Board nicht zu weit weg vom Team aufstellen!.
Elektronische Boards
00:21:46
Atlassian Jira — Redmine — Trello — Tickets elektronisch verwalten — Einschränkung der Flexibilität, spontane Ideen sind nicht leicht umzusetzen — Issue Tracking, Bug Tracking — Bugzilla — Jira Agile, ehemals Greenhopper — Scrum oder Kanban Board — Issues als virtuelle Karte verwalten, gestützt durch Datenbank — Vorteile: (Workflow muss eingehalten werden — Reports werden automatisch erstellt — nicht ortsgebunden — Statusänderungen werden automatisch protkolliert) — Planning Mode der Scrum Boards vor allem für Product Owner sehr wertvoll — Jira Tastaturkürzel — Nachteil von elektronischen Boards: (Änderungen schwieriger umzusetzen) — Elektronische Boards sind sehr gut zur Vorbereitung und Dokumentation — Physische Boards sind besser in Teams, die gemeinsam davor stehen.
Fallstricke
00:31:52
Board wird nicht benutzt -> veraltete Information — Board wird nicht geändert -> Arbeitsweise passt sich nicht mehr der Wirklichkeit an — Synchronisierung von elektronischem und physischem Board -> welches führt? (man könnte die feinere Granularität dem physischen Board vorenthalten) — Sichtbarkeit und Rechte in elektronischem Board zu gering -> die richtigen Leute können nicht sehen oder damit arbeiten — "Das Board soll helfen, die Arbeit zu visualisieren, die man normalerweise nicht sieht." (Alex) — Automatisches Verlinken von git commits und Jira Tickets.
00:00:00.000 Start und Begrüßung
00:00:51.000 Thema heute: Taskboards
00:12:48.000 Zustandsvisualisierung
00:15:52.000 Schneepflug
00:21:46.000 Elektronische Boards
00:31:52.000 Fallstricke
00:37:15.000 Ende
In dieser Episode geht es um das Thema "Schätzen". Projektbeteiligte, vor allem die Auftraggeber, haben immer ein berechtigtes Interesse daran zu erfahren, wann etwas bestimmtes "fertig" ist. Dabei ist es wirklich nicht leicht in die Zukunft zu schauen, um das Fertigstellungsdatum eines Features oder gar eines ganzen Produktes zu schätzen. Also was tun? Die agile Welt schätzt Story Points, aber warum? Dazu einiges zum Einstieg in dieser Episode, dessen Fazit ist: erstellt nur solche Schätzungen, anhand derer Ihr auch wirklich Entscheidungen trefft.
Anfang und Begrüßung
00:00:00
Schätzen oder nicht schätzen
00:00:53
(der Versuch in die Zukunft zu schauen (Alex) — Es geht darum vorherzusagen, wie umfangreich Aufgaben sind) — Schon "damals" im Studium gelernt (Function-Point-Verfahren) — Projektmanagement im Allgemeinen (Bedürfnis eine Voraussage zu machen, wann eine bestimmte Sache fertig ist — Kostenabschätzung — Abhängigkeit anderer auf die Produktentwicklung, bspw. Kommunikation/Marketing — "Manntage" schätzen) .
Schätzen in der agilen Welt
00:04:26
(Story Points — Schätzrunden mit dem ganzen Team — Planning Poker) — "Das Ziel warum wir schätzen ist, dass wir ein gemeinsames Verständnis herstellen, wie diese Story umgesetzt werden soll" (Quote: Alex) (Schätzwert ist nur Nebenprodukt — Bei zu großen Differenzen im Planning-Poker-schätzen wird weiter diskutiert, um mehr Erkenntnis zu erreichen) — Welche Größe wird geschätzt? (Zeit, Schwierigkeit, Komplexität — Blogbeitrag von Mike Cohn) — Story Point Schätzungen sollten für nichts anderes verwendet werden, vor allem nicht für Vergleiche mit Anderen oder Gehaltsverhandlungen — "Es ist hilfreich, größere Zahlen zu haben, damit man eine bessere Auflösung nach unten hat" (Toby) — Statt Fibonacci Zahlen kann man sich auch auf zwei Größen beschränken: "klein genug" für einen Sprint, oder eben "zu groß" — Fibonacci Zahlen bilden die größere Ungenauigkeit bei größeren Schätzungen ab (Illusion der Präzision in MS Project) — "Vergesst Präzision beim Schätzen" (Toby).
No Estimates Bewegung
00:17:30
("Ich möchte Teil einer Jugendbewegung sein" (Toby zitiert Tocotronic) — Bewegung um Neil Killick — und Woody Zuill — Wofür schätzen wir eigentlich? Nutzen wir die Ergebnisse der Schätzung für etwas sinnvolles? — Wenn mit den Informationen, die wir zusammentragen, keine Entscheidungen getroffen werden, braucht man sie auch nicht zusammentragen — "Durch das Schätzen wird die Story auch nicht schneller fertig" (Toby)) .
Function-Point-Verfahren
00:21:28
(Gantt Charts — Dreckstool — Vergleich: Software-Entwicklung / Hausbau funktioniert nicht) — Was kann schiefgehen beim Schätzen? (Zeit schätzen — Sich auf die Schätzung verlassen, sich unter Druck setzen — Schätzung setzt minimale Zeit, wenn Aufgaben schneller gehen nimmmt man sich trotzdem so lang wie geschätzt — nicht alle relevanten Leute befragen — zu viel Zeit auf die Schätzung verbringen, um eine "bessere" Schätzung zu erreichen) — Abschluss ("Wenn Ihr schätzen wollt, überlegt Euch genau warum und wie. Verzichtet auf zu hohe Präzision" (Toby)) .
00:00:00.000 Anfang und Begrüßung
00:00:53.000 Schätzen oder nicht schätzen
00:04:26.000 Schätzen in der agilen Welt
00:17:30.000 No Estimates Bewegung
00:21:28.000 Function-Point-Verfahren
Heute geht es endlich um das, was wir schon so oft erwähnt haben: das Backlog in all seinen Ausprägungen und die User Stories, die sich häufig darin befinden. Das von mir gewählte Beispiel der Schiebetür am Auto ist zwar etwas spontan und albern, abstrahiert aber vielleicht gut genug davon, was wir ITler so im täglichen Job erleben.
Backlog
00:01:58
Wichtigste Liste für den Product Owner (mit Dingen, die das Entwicklungsteam umsetzen soll) — Backlog hat eine Reihenfolge — Absolut Sortiert nach Priorität — Nicht etwa: vieles hat Priorität eins, der Rest eins plus — "Wenn alles die höchste Priorität hat, ist nichts wichtig" (Alex zitiert jemanden) — Das Wichtigste ist immer ganz oben — Dann guckt man gar nicht nach unten, da sammelt sich so der Schmodder" (Alex) — Verschiedene Backlogs: (Sprint Backlog — Product Backlog — Epic Backlog) — Das Product Backlog sollte nicht zu wenig und nicht zu viele Einträge haben — Sprint Backlog ist nicht nur oberster Teil des Product Backlogs, sondern außerdem während des Sprints geschützt. — Atlassian Jira — Greenhopper / Agile — Unterschied zwischen Einträgen im Epic Backlog und Product Backlog sind (Größe / Umfang — Detailgrad der Beschreibung) .
User Stories
00:11:38
(in Wikipedia) — Form: Als "Rolle" möchte ich "dies und das" um "zu erreichen" (Rolle: wer möchte etwas erreichen — Maßnahme: was möchte die Rolle erreichen — Grund: warum möchte die Rolle es erreichen) — "Eine User ist das Versprechen, darüber zu sprechen" (Toby zitiert Jeff Patton) — Jeff Patton — User Story ist eine Aufforderung zur Kommunikation, damit ein gemeinsames Verständnis erreicht wird — Begriff Story vielleicht ungünstig, weil Geschichten keine Konversation sind — Extreme Programming (Kent Beck) (Card, Conversation, Confirmation) — Trello.
Epics und Themes
00:23:10
Größere Themenbereiche — User Stories sollten immer in einen Sprint passen (Epics können viele User Stories umfassen) — Bilden eine Klammer und bieten Orientierung — Epics müssen nicht in einem Rutsch abgearbeitet werden.
User Story Mapping
00:25:03
Man hängt alle Epics nebeneinander, und jeweils darunter die dazugehörigen User Stories — User Stories sind auch hier nach Priorität sortiert — Schneiden von Releases — Sichtbarkeit von Abhängigkeiten — Buch dazu von Jeff Patton.
Discovery
00:29:22
(Füllen des initialen Backlogs durch Workshops) — Entdeckungsreise mit Blick in alle Richtungen — Andere Einträge im Backlog als User Stories.
Schwierigkeiten bei Backlogs und User Stories
00:33:07
Backlog ist zu umfangreich, vollgestopft und unübersichtlich — Backlog zu kurz: Produkt schon fertig? — Backlog ist nicht sichtbar (innerhalb der Firma) — "Immer wenn wir was geschafft haben, schicken wir die User Stories an die Konkurrenz" (Alex zitiert jemanden) — Reporting durch das Backlog — "Was hilft denn Transparenz wenn keiner guckt" (Toby) — User Stories im Backlog mit dem Epic markieren zur Übersichtlichkeit — User Story ersetzt Anforderungsdokument, ist vollständig und final -> kein Gespräch — User Story ist zu knapp beschrieben (reicht nicht für den Start) — Backlog ist falsch sortiert: nicht nach Prio, sondern nach Epics — Zu viele oder zu wenige Rollen — "Als Nutzer möchte ich die Funktionalität bedienen, damit es funktioniert" (Toby) — Goldenen Mittelweg finden, wie so oft — Why-Teil ist optional, aber verhement wichtig.
Abschluss und Verabschiedung
00:42:45
00:00:00.000 Anfang und Begrüßung
00:01:58.000 Backlog
00:11:38.000 User Stories
00:17:21.000 Akzeptanzkriterien
00:23:10.000 Epics und Themes
00:25:03.000 User Story Mapping
00:29:22.000 Discovery
00:33:07.000 Schwierigkeiten bei Backlogs und User Stories
00:42:45.000 Abschluss und Verabschiedung
Das erste non-essential in der Reihe Scrum Essentials: das Backlog Grooming gehört nicht wirklich zu den Pflicht-Meetings im Scrum Zyklus. Dennoch ist es ein sehr wertvolles Mittel, um das Product Backlog zu pflegen. In dieser Episode erklären wir, was das für ein Meeting ist, wie man es durchführt, was die Ziele sind, und was schiefgehen kann.
Anfang und Begrüßung
00:00:00
Fünfte Runde der Scrum Essentials, erstes Nicht-Standard-Meeting — "Die Serie ist beendet, wir fangen jetzt die Non-Essentials an" (Toby).
Backlog Grooming Meeting
00:01:35
(auch: Gardening, Refinement) — Grooming heißt Pflegen, Reinigen — Backlog ist die in eine Reihenfolge sortierte Liste der Dinge, die man für das Produkt noch erledigen will.
Ziele für das Backlog Grooming
00:02:52
besser sortiertes Backlog — zu kurzes Backlog auffüllen, zu großes Backlog kürzen — zwei bis drei vorbereitete Sprints sind ideal (Anzahl und Größe der Einträge, die bereit für den Sprint sind, reichen für drei Sprints aus) — Definition of Ready: beschreibt, wann ein Eintrag bereit für den Sprint ist — Einträge im Backlog können User Stories sein, müssen aber nicht — Backlog muss Einträge mindestens für den nächsten Sprint haben, aber auch nicht viel mehr als für die nächsten drei Sprints — "Auch Vorbereitung kann Waste sein" (Toby).
Priorisierung der Einträge im Backlog
00:07:22
Kundenwert — Risiko — Zusammengehörigkeit der Einträge für ein gutes Sprintziel, Epics — Löschen von obsoleten Stories.
Durchführung von Grooming Meetings
00:09:05
Alle zwei Wochen, das ganze Team.
Wissensverbreitung durch Diskussion
00:11:03
Stake Holder können helfen, Einträge im Backlog noch besser zu verstehen — Backlog ist das wichtigste Artefakt für den Product Owner (PO sollte sehr viel Wert auf das Grooming Meeting legen und sehr gut vorbereiten) — PO sollte die Einträge sehr gut kennen — "Warum ist das Grooming Meeting kein fester Bestandteil von Scrum?" (Alex).
Kritik an Grooming Meetings
00:14:10
Jeff Patton: Grooming Meetings as Team Torture — Grooming Meetings müssen nicht fester Bestandteil von Scrum sein, wenn das Team anders bei der Backlog Pflege hilft — Ergebnis des Workshops beim ProductCamp Berlin 2013 — Festes Thema für ein Grooming Meeting ist hilfreich.
Exkurs: Planning Poker
00:19:18
Einschätzung der Komplexität eines Eintrags — Erkenntnis, ob alle das gleiche Verständnis haben — Abstrakter Wert im Bezug auf beliebige Referenzgröße — Finger statt Karten im Planning Poker — Hauptsache Kommunikation.
Was kann schiefgehen im Backlog Grooming
00:22:57
zu viele Details können Waste sein — zu wenig Vorbereitung durch den PO (Energie des Teams sinkt — PO sollte eigentlich immer gut über das — "Shit in, Shit out, wenn das Backlog schlecht ist, wird auch das Produkt schlecht" (Alex)) — Thema langweilig (hängt vom Produkt ab, könnte Rückschlüsse zulassen) — Zeitdruck (Team hat nie Zeit, muss man explizit einplanen und einfordern — Team hat keine Lust — Team fordert vorgekaute Stories — Grooming ist Teil des Jobs auch von Entwicklern, Bewusstsein schaffen) — Einträge, die bereits implementierte Komponenten obsolet machen (den Entwicklern liegt etwas daran, Implementiertes zu erhalten — Übel an der Wurzel packen: woran liegt es?) — Stolz auf das Geschaffene ist gut, aber man darf nicht dran hängen (es kann immer passieren, dass man anhand der Implementierung erkennt, das bereits gebaute Software so nicht gebraucht wird) — "Wir machen das ja nicht mit Absicht" (Toby) — Im Grooming Meeting kann es zu Verstimmung kommen.
Tipp: Pre-Grooming
00:33:05
Ein Entwickler des Teams hilft, das Grooming vorzubereiten (Auswahl der Stories für das Grooming Meeting — Erste Fragen aufnehmen und klären — Im Grooming Meeting Unterstützung durch diesen Entwickler bekommen) — Artikel von Roman Pichler — Entfernen von Einträgen ist auch wichtig (und fühlt sich gut an) — Atlassian Jira — Grooming für Epic Backlogs oder Portfolio Roadmaps — Epic Points vs Story Points, nicht verwechseln.
00:00:00.000 Anfang und Begrüßung
00:01:35.000 Backlog Grooming Meeting
00:02:52.000 Ziele für das Backlog Grooming
00:07:22.000 Priorisierung der Einträge im Backlog
00:09:05.000 Durchführung von Grooming Meetings
00:11:03.000 Wissensverbreitung durch Diskussion
00:14:10.000 Kritik an Grooming Meetings
00:19:18.000 Exkurs: Planning Poker
00:22:57.000 Was kann schiefgehen im Backlog Grooming
00:33:05.000 Tipp: Pre-Grooming
00:37:11.000 Abschluss und Verabschiedung
-
-
Outcome of a grooming session
-
-
How to run a grooming session
-
-
What can go wrong?