Seit einem Jahr bin ich nun stolzer Product Owner von CenterDevice . Und die ganze Zeit hadere ich mit mir und der Art und Weise, wie ich das Product Backlog in Form halte. Oder besser, wie ich daran scheitere. Vor drei Wochen entschied ich dann, dass ich nicht der Schuldige bin, sondern meine Herangehensweise. Also habe ich diese geändert.
Was waren die Schwierigkeiten, höre ich Euch fragen? Die Herausforderungen? CenterDevice ist aktuell ein StartUp, das kurz vor dem Durchbruch steht. Es ist nicht so, dass wir keine Kunden hätten, das Gegenteil ist der Fall. Wir haben so viele Kunden, dass die ganzen Kleinigkeiten, die aus dem Vertrieb, den Kundenbetreuern, dem Support und dem Management auf uns zukommen, uns ohne Probleme komplett beschäftigen können. Andererseits, und wie könnte es anders sein, hätte ich nichts gegen viel mehr Neukunden 🙂
Um die Kundenbasis auszubauen und das Wachstum zu steigern, würde ich neue Funktionen gerne schneller in Betrieb nehmen, neue Sachen ausprobieren, messen ob sie funktionieren, usw. Die ganze Lean StartUp-Palette eben.
Aber das in einem „klassischen“ Product Backlog abzubilden war eine ziemliche Herausforderung. Eine lange Liste von Product Backlog Items, schön geordnet und geschätzt. Wir haben es als Scrum Team geschafft das Sprint Backlog während eines Sprints einigermaßen intakt zu halten. Aber in einem Kontext wie dem unseren ist einfach viel Dynamik im Product Backlog. Dies führte zu der Situation, dass die nächsten 1-2 Sprints einigermaßen auf die Releaseplanung projezierbar waren, aber danach herrschte das reine Chaos.
Eines Morgens kam ich darauf, dass nicht alle Einträge im Product Backlog gleich zu behandeln sind, und ich kategorisierte schnell in drei Töpfe, und ebenso schnell ersonn ich eine Metapher, die bis heute erstaunlich gut trägt. Wenn man bedenkt, dass das die erstbeste Idee war.
Meine Damen und Herren, darf ich vorstellen: Die Produkt-Speisekarte! (Jajaja, auf Deutsch hört sich das furchtbar an.)
Die Produkt-Speisekarte (Product Menu) – Eine neue Art das Product Backlog zu strukturieren
Das Hauptgericht (Main Dish)
Das ist der Fokus. Das Entwicklungsteam wird sich hauptsächlich darauf konzentrieren. Jeden Sprint werden wir uns auf ein neues Hauptgericht konzentrieren. Um es in User Story-Sprache auszudrücken, dies ist eine „Epic“. Hauptgerichte können eine Hypothese sein, die es zu testen gilt, ein neues Feature, Verständnis das aufgebaut werden muss, etwas das es über den Kunden zu lernen gibt, etc. Es ist das Sprint Ziel, welches unter allen Umständen gehalten werden sollte. Als Product Owner ist es meine Pflicht das Hauptgericht in einige User Stories zu zerlegen (es ist eben eine Epic). I schätze, dass 5 bis 10 (ein bis zwei Handvoll) User Stories angemessen sind, sodass wir während der Sprintplanung noch etwas Platz haben, um alles „einzurütteln“. Meine Annahme ist weiterhin, dass es auch bei einem Hauptgericht einen abnehmenden Grenznutzen gibt. Also bringen wir es innerhalb eines Sprints so weit nach vorne, wie es sinnvoll ist. Jede Arbeit, die bei Sprintende noch nicht abgeschlossen ist, wird nicht ausgeliefert. Commits können rückgängig gemacht werden, Branches werden abgeschnitten. Wenn ich entscheide, dass es klug ist, das Thema weiter zu treiben, erstelle ich dafür später ein neues Hauptgericht.
Die Beilagen (Side Orders)
Jedes Hauptgericht wird im Sprint um einige Beilagen ergänzt. Das ist vermutlich, was dem normalen Product Backlog am nahesten kommt. Beilagen sind nach meinen Kriterien geordnet, aber nicht zusammenhängend. Sowohl zwischen den einzelnen Beilagen besteht (kaum) ein Zusammenhang, als auch zu dem Hauptgericht. Aber sie müssen erledigt werden, aus welchem Grund auch immer. Also liefern wir mit jedem Hauptgericht auch einige Beilagen aus. Wahrscheinlich so zwei bis drei, aber das hängt natürlich auch vom Entwicklungsteam und deren Velocity ab.
Die Knabbereien (Snacks)
Und dann gibt es noch die Vielzahl der kleinen Dinge: Kleine Bugs, kleine Verbesserungen, technische Aufgaben, usw. Diese Dinge sollten einerseits demnächst erledigt werden, wenn nicht würde ich das Ticket direkt löschen, andererseits ist mir die Organisation und Priorisierung aber für den Nutzen der Kleinigkeiten viel zu hoch. Stattdessen gibt es jetzt die Sammlung der Knabbereien, aus denen sich das Entwicklungsteam selbständig bedienen kann. Eine Knabberei sollte wirklich klein sein, maximal einen halben Tag Arbeit verursachen, je weniger desto besser. Wenn ich es als Product Owner für wichtig erachte, wann etwas erledigt sein sollte, müsste ich daraus eine Beilage machen.
Fazit
Mit dem Hauptgericht, den Beilagen und Knabbereien habe ich hoffentlich eine gute Balance gefunden, um das Scrum Team auf wichtige Dinge zu fokussieren, um das Product Backlog schnell umorganisieren zu können und trotzdem den Aufwand dafür minimal zu halten. Das CenterDevice Scrum Team hat gerade erst damit angefangen, diese Idee umzusetzen. Mit Erfahrungsberichten kann ich also leider noch nicht dienen, aber ich werde von mir hören lassen, sobald es etwas Neues gibt. Nach ersten Diskussionen scheint die Produkt-Speisekarte aber einen Nerv zu treffen, oder ist zumindest nach dem ersten Augenschein nicht kompletter Blödsinn. Also, was denkst Du über die Produkt-Speisekarte? Wirst Du das ausprobieren? Ist das etwas, das jeder Product Owner in seinem Werkzeugkoffer haben sollte? Wie siehst Du den Zusammenhang zu anderen Praktiken, die Du benutzt (oder kennst)?
Fragen & Antworten
Um die Beschreibung der Produkt-Speisekarte knapp zu halten, habe ich einige Aspekte in diesen Abschnitt ausgegliedert.
Ist das eine Abweichung von Scrum?
Nein. Laut Scrum kann sich das Product Backlog mit jedem Sprint komplett ändern, und es ist in der Verantwortung des Product Owners es zu warten. Das Product Backlog als Speisekarte aufzubauen ist nur ein spezieller Umgang mit den Product Backlog Items.
Wie verhält sich die Speisekarte zu Schätzungen und Releaseplänen?
Die geschätzten Stories helfen dem Team immer noch während der Planung ein gutes Gleichgewicht zwischen Hauptgericht und Beilagen zu finden. Als Product Owner stütze ich mich nicht mehr allzu sehr auf die Schätzungen (und habe es vermutlich auch kaum getan). Es ist viel einfacher jedem Sprint gedanklich ein Hauptgericht zuzuordnen, und um ein paar Beilagen zu ergänzen. Das funktioniert für meine Bedürfnisse und Ansprüche gut genug. Ja, damit habe ich vermutlich einen großen Schritt in Richtung #NoEstimates unternommen.
In welchen Umständen sollte man eine Produkt-Speisekarte anwenden?
Wenn ich versuche die Situation, in der sich CenterDevice gerade befinden, zu generalisieren – oder um genauer zu sein: die, des CenterDevice Core/Web-Teams; andere haben noch keine Speisekarte, dann sind das die Kernpunkte:
- Es gibt ein bestehendes Produkt. Wenn Du auf der grünen Wiese anfängst, würde ich vermutlich nur Hauptgerichte benutzen, und die Beilagen und Knabbereien erstmal ganz beiseite lassen.
- Der Weg in die Zukunft ist noch nicht klar, auch wenn man eine großartige Vision hat. Wenn Du nichts ausprobieren musst und eine klare Vorstellung davon hast (oder glaubst zu haben…) wie es weiter geht, dann brauchst Du vermutlich keine Hauptgerichte, sondern kannst dich ausschließlich von Beilagen (also dem „normalen“ Product Backlog) ernähren.
- Es gibt ausreichend Kunden, um Dich zu beschäftigen. Wenn Du es zulässt. Wenn Du noch nichts in Betrieb genommen hast, solltest Du das schleunigst tun 🙂 Und wenn Dein Backlog nicht diese vielen, kleinen Items enthält: Gut für Dich, gut gemacht!
Kann ein Scrum Team mehr als ein Hauptgericht servieren?
Klar, warum nicht? Für uns würde das aktuell nicht funktionieren, aber warum nicht? Hey, warum skalierst Du die Scrum Teams nicht wie in einem Restaurant zu einer Großküche?
Wie hält man das Gleichgewicht zwischen Hauptgericht, Beilagen und Knabbereien?
Erfahrung und Zusammenarbeit während der Sprintplanung. Haltet das Gleichgewicht! Wenn Du Dich nur auf das Hauptgericht konzentrierst, wird es vermutlich langweilig, also würze es etwas nach! Wenn Du nur von den Knabbereien naschst, ist das auch ungesund!
War dieser Beitrag hilfreich?
Weitere Beiträge
von Andreas Ebbert-Karroum
18.11.2020 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Andreas Ebbert-Karroum
Agile Principal Consultant
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.