Direkt zum Hauptbereich

Ideen für Backlogs

Ideen für Backlogs

Zeig mir dein Backlog und wir versuchen euch zu sagen, wo eure Herausforderungen liegen. Das geht nicht immer, aber sehr oft. Mit meinem Kollegen Lino Otolski bin ich gerade zusammen für einen Kunden im Einsatz. Dabei hat es sich ergeben, dass wir uns beide bei einem Kaffee zum Thema Backlog unterhalten haben. Uns haben die Inhalte des Gesprächs so gut gefallen, dass wir diese an euch weitergeben wollten. Wir hoffen, dass dieser Artikel euch inspiriert, mit Hilfe des Backlogs bessere Produkte zu entwickeln.

Michael: "Hi Lino, fangen wir doch ganz grundlegend an! Was ist in deinen Worten ein Backlog und warum sollte ein Produkt-Entwicklungsteam ein Product-Backlog (PBL) haben?"

Lino: "In einem PBL ist die Arbeit strukturiert und zugänglich abgelegt, die ein Team leistet, um seine Ziele zu erreichen und seiner Vision gerecht zu werden. Ein PBL sorgt für ein Alignment im Team und dient ebenso als Hilfestellung, Arbeit fokussiert und priorisiert nach Geschäftszielen (hoffentlich user-centric) zu leisten. Das PBL ist damit ein zentrales Artefakt agiler Produktentwicklung."

"Was ist in deinen Augen die größte Herausforderung in Bezug auf das PBL?"
Michael: "In vielen Teams ist das Backlog tatsächlich ein “BACKlog”. Es ist veraltet (Wie ein Blick zurück, statt in die Zukunft). Ein agiles Team lernt im Grunde jeden Tag etwas dazu. Das heißt, das Team muss lernen all diese kleinen Erkenntnisse auch im Backlog transparent zu machen."

"Lino wie löst du diese Herausforderung in deinen Teams? Ist es deiner Erfahrung nach "OK" Einträge auch einmal zu löschen?” 
Lino: "Aus meiner Sicht ist ein Backlog ein lebendes Artefakt. Somit sind Änderungen an diesem erwünscht und sogar notwendig. Die Kunst dabei ist es, den Detailgrad der Arbeitspakete entsprechend der Relevanz zu wählen. Man will im Grunde so viel Arbeit wie nötig in das Backlog stecken und so wenig wie möglich. Somit können wir agil bleiben mit möglichst wenig Risiko, viel Zeit in die Planung irrelevanter Aufgaben zu investieren. Regelmäßiges Aktualisieren entsprechend nach dem DEEP (detailed/estimated appropriately, emergent, prioritized as needed) Prinzip ist meiner Erfahrung nach sehr hilfreich. Oftmals wird das Backlog in regelmäßigen wiederkehrenden Terminen gepflegt (z.B. Refinement, Estimation oder andere)."

"Michael, ich habe in der Vergangenheit bei dir herausgehört, dass du damit ein wenig “Bauchschmerzen” hast. Warum ist das so?"
Michael: "Etablierte, feste Termine für die Entwicklung des PBL sind alleine kein Garant für Erfolg. Diese Termine können das Team auch unflexibel und damit ineffektiver machen. Ich mag nicht sagen, dass vor allem junge Teams nicht mit solchen Teilschritten arbeiten sollten, um stückweise zu lernen, ein besseres Backlog zu entwickeln. Es ist aber für mich definitiv nicht das Zielbild. Der Scrum Guide empfiehlt Refinement als kontinuierlichen Vorgang während des Sprints zu verstehen und z.B. bei einem zweiwöchigen Sprint ca. 6 Stunden aufzuwenden. Bei 10 Arbeitstagen sind das ca. 30 Minuten am Tag!"

"Lino was für Prinzipien können mir helfen, um in dieser Zeit ein gutes PBL zu bekommen?" 
Lino: "Das Prinzip DEEP hatte ich bereits erwähnt, welches sich auf den Detailgrad der Arbeitspakete bezieht. Eine andere Perspektive ist, effizient mit den PBI ‘s arbeiten zu können. Hier unterstützt das INVEST-Prinzip. In diesem Fall steht INVEST für Independent, Negotiable, Valuable, Estimable- Sized appropriately, Testable. Sprich ein PBI sollte INVESTed sein. Jedes dieser Worte beinhaltet eine Menge. Beispielsweise ist die Voraussetzung für “Testable” ein für jeden verständlich kommuniziertes Outcome, welches im Optimalfall nach den SMART-Kriterien definiert ist (Spezifisch, Messbar, Akzeptiert, Realistisch, Terminiert). Ganz schön viele Buzzwords – aber sie machen den Unterschied."

"Michael was denkst du ist neben diesen Prinzipien noch wichtig, damit ein gutes PBL entstehen kann?"
Michael: "Die Teams, in denen ich arbeite, hören von mir oft provokativ den Satz: “ein Produktbacklog ohne Produktvision ist nur ein Haufen Arbeit”. Wenn wir es mit einer Wanderung vergleichen: “Nur weil wir weit laufen, heißt das nicht, dass wir auch am Ziel ankommen! Deshalb braucht es in meinen Augen eine klare Vision in jedem Team. Für ein erfolgreiches Produkt müssen die einzelnen Vorgänge auch auf eine Vision einzahlen."

"Aber Lino apropos Vorgänge. Das Backlog ist die einzige Quelle von Arbeit. Morgens aufstehen, habe ich bisher aber nie reingeschrieben. Was kommt alles in ein Backlog Lino? Was hältst du von einer Faustregel, wie alles, was länger als 30 Minuten dauert?"

Lino: "Ich denke in ein PBL gehören alle Produktideen, die das Team umsetzen möchte, um das Produkt zu verbessern. Umgesetzt werden dann die wertvollsten. Der Rest wächst mit der Zeit aus dem PBL heraus. Pauschal zu sagen, dass kleine Aufgaben nicht in das PBL kommen, ist meiner Ansicht nach nicht passend. Wichtige Informationen könnten so verloren gehen. Aber es ist sicherlich sinnvoll, nicht 20 Minuten etwas zu dokumentieren, wenn die Umsetzung nur eine Minute dauert und die Relevanz für das Team oder das Produkt eher klein ist."

"Was funktioniert denn konkret in dem Team, indem du aktuell tätig bist, gut in Bezug auf die PBL-Pflege?" 
Michael: "Wir sind richtig schnell darin, neue und in meinen Augen gute Stories zu erstellen. Neue Informationen sammeln wir kurz zur Besprechung in Miro für unser Daily. Dort nimmt die Story dann jemand mit und bereitet sie für das Team vor. In einem gemeinsamen Termin mit den Stakeholdern sprechen wir dann noch einmal kurz drüber und dann landet sie meistens direkt im nächsten Sprint. Als Struktur hat sich das Job Story Template sehr bewährt. Wir schaffen gerade oft eine Zykluszeit von weniger als einer Woche. Das macht viel Spaß. Das klappt unter anderem so gut, weil sich jeder für das Backlog verantwortlich fühlt und auch merkt, wie gut es funktioniert, wenn das alle machen." 

"Was klappt bei dir gut Lino?"
Lino Antwort: "Bei uns funktioniert es gut, einen festen Blocker am Tag zu haben, den wir flexibel für die Aktivitäten nutzen können, die uns helfen keine Bottlenecks aufkommen zu lassen. Sprich plannings, task-breakdowns, estimations, knowledge-sharing usw.. Wir ziehen uns sozusagen die Arbeit immer dann, wenn wir wieder Kapazität haben. So aktualisieren wir kontinuierlich und bedarfsorientiert das PBL. Oftmals beobachten wir das von Teams gefordert wird, an vielen Themen gleichzeitig zu arbeiten." 

"Michael was ist schlecht daran und wie können Teams eine solche Situation auflösen?" 
Michael: "Es ist schlecht, weil es einfach ineffektiver ist, an vielen Dingen parallel zu arbeiten. Ein Team kann eine solche Situation auflösen, in dem es priorisiert. Oft gibt es dann auch verschiedene Stakeholder, für die einzelnen Themen. In einem gemeinsamen Termin sollte, eine Reihenfolge der Themen festgelegt werden. Roadmaps können hier bei der Visualisierung und Kommunikation helfen!"


Das waren kurze Gedanken von Lino Otolski und Michael Thiel zum Thema Backlog. Wir freuen uns auf Feedback oder eure Ideen zu dem Thema und hoffen, dass die ein oder andere Idee euch hilft bessere Produkte zu entwickeln. 

Viel Spaß beim Nachdenken, 
 Lino & Michi

Kommentare

Beliebte Posts aus diesem Blog

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

"Wollt Ihr die totale Konkurrenz?!" - Nein, danke. Ich will lieber Erfolg, ich will spielen!

Es wird Zeit, dass wir uns daran erinnern, um was es wirklich geht: Dass wir gemeinsam gestalten, spielen und auch gemeinsam gewinnen. Und was wir riskieren, wenn wir das ignorieren.    

Scrum und Kennzahlen (KPIs, Metriken)

In regelmäßigen Abständen hören wir die Frage, welche Kennzahlen (neudeutsch KPIs) bei Scrum sinnvoll sind. Zeit für einen längeren Beitrag, auf wichtige Ressourcen zu verweisen. Der Scrum-Guide selbst gibt dazu keine erschöpfende Auskunft. Und das hat seine Gründe.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

Die Krankheit des Besser-Wissens! Drei powervolle Fragetechniken und eine Haltung zur Heilung.

Kennst Du das: Du betrittst einen Raum und bist Teil einer Situation, hörst eine Problembeschreibung, siehst eine Aufgabe oder list eine Anfrage. Auf jeden Fall weisst Du mit einem Blick, einem Satz, einem Augenzwinkern sofort Bescheid. Du weisst: um was es geht was das Problem ist wieso das passiert ist was als Nächstes passiert und oft auch was dann (nicht) zu tun ist So wie mit dem Video hier: Ziemlich klar oder? Was für Gedanken gehen Dir durch den Kopf? Vielleicht sowas wie Oh weh!, Unfall!,  gibts Verletzte?  Oder Gehts denen gut? Wo ist das passiert? Viel Spass beim Flottmachen! Etc, etc... Auf jeden Fall aber: Was für ein Malheur! - oder irgend etwas Anderes in der Art. oder? Anderes Beispiel. Schau Dir mal folgendes Bild an und les im Geiste die beiden Reihen vor: A-B-C 12-13-14 oder? Unser Geist beruft sich auf sein Wissen und gibt uns in sekundenschnelle seine Annahme, seine Interpretation, seine Projektion der Wirklichkeit ein. Und die ist in dem Video oben nunmal ein ver