016 ~ Gespräch Jutta Eckstein

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.
avatar
Toby Baier

Anfang und Begrüßung

00:00:00

Toby ist mittlerweile Agile Coach — Retrospective Facilitators Gathering — Austausch zur Ausrichtung von Retrospektiven.

Vorstellung Jutta Eckstein

00:03:58

(Freie Beraterin)  — Diving for hidden treasures: Uncovering the Cost of Delay in Your Project Portfolio — Jutta arbeitet seit 1998 eigenständig als Agile Coach.

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.

Verzugskosten

00:12:29

Nachdenken über den Gewinn, den man nicht macht, und die zur gleichen Zeit anfallenden Entwicklungskosten — Pragmatische Übersetzung des Buchs von Don Reinertsen.

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?) .

Verabschiedung

00:29:35

015 ~ Karl Popper und agile Produktentwicklung mit Patrick Breitenbach

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.
avatar
Toby Baier
avatar
Patrick Breitenbach

014 ~ Der Product Owner in der agilen Transition

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.
avatar
Toby Baier
avatar
Corinna Baldauf

Corinna arbeitet bei sipgate: Flexible Telefonie für zu Hause, unterwegs und das Büro.

013 ~ Scaling Agile Teil 2

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.
avatar
Toby Baier
avatar
Bernd Schiffer

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

Scaling Scrum (Ansatz)

00:47:07

(irrtümlich Scaling Agile genannt)  — Scrum Inc (Jeff Sutherland) — Informationen hinter Paywall versteckt — Scrum selbst ist schon fraktal.

XSCALE

00:50:41

(Excellence Scale-Symmetry Continuous Autonomous Lean Ecosystem — aus Sydney (Australien) — bedient sich aus den verschiedenen bestehenden Modellen — obskur mit vielen Inhalten: Lean Startup, Open Space, Behaviour Driven Development, git... — "Alles was geht" (Toby)) .

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

Teil zwei Scaling Agile: live am 10.6.2015

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!

012 ~ Scaling Agile mit Bernd Schiffer

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.
avatar
Toby Baier
avatar
Bernd Schiffer
avatar
Tagamemnon
avatar
v0tti

Intro

00:00:00

Begrüßung

00:00:28

Heute als Gast: Bernd Schiffer — Während der Sendung findet ein Fussballspiel zwischen Deutschland und Australien statt — it-agile — Tobias Baier — Buzzword-Bingo.

Was heißt Agile?

00:06:29

Agile heißt felxible Planung — Scrum — Kanban.

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 Large Scale Scrum

01:09:44

Craig Larman — Bas Vodde — Scrum Alliance (Buch: LSS - more with less)  — Scaled Agile Framework (“SAFe”) — Spotify Approach — Marty Cagan.

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

Weitere unstrukturierte Modelle

01:53:46

ScAleD (rekursives Akronym) (basiert auf Prinzipien anstatt auf Prozessvorgaben)  — Donald Reinertsen Buch: Product Development Flow (auch eine Ansammlung von Prinzipien)  — Foliensatz zum Thema.

Outro

02:05:17

011 ~ Taskboards

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?
avatar
Toby Baier
avatar
Alexander Fürstenau

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.

Ende

00:37:15

010 ~ Schätzen oder nicht schätzen

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.
avatar
Toby Baier
avatar
Alexander Fürstenau

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

009 ~ Backlog und User Stories

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.
avatar
Toby Baier
avatar
Alexander Fürstenau

Anfang und Begrüßung

00:00:00

Buch von Mike Cohn: User Stories Applied.

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.

Akzeptanzkriterien

00:17:21

Kriterien, anhand derer Entwickler erkennen können, ob sie auf dem richtigen Weg sind — Rahmenbedingungen und Randbedingungen — Nicht-Funktionale Anforderungen — Anzahl der Akzeptanzkriterien pro User Story ist nicht fest — Sven Röpstorff (Scrum in der Praxis)  — Blog von Sven über Produktmanagement (Akzeptanzkriterien können nicht vollständig sein) .

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

008 ~ Backlog Grooming

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.
avatar
Toby Baier
avatar
Alexander Fürstenau

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.

Abschluss und Verabschiedung

00:37:11

(Bitte um Kommentare im Blog) .