Der Scrum Guide empfiehlt, mit einem Product Backlog zu arbeiten. Dies ist eine sortierte Liste, die alles das auflistet, was später im Produkt enthalten sein soll. Was bedeutet das konkret?
Im Scrum Guide (vom November 2017) steht:
„Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. Ein Product-Backlog-Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert. Product-Backlog-Einträge enthalten oft Testbeschreibungen, die ihre Vollständigkeit nachweisen, wenn sie fertig [„Done“] sind.“
Das Product Backlog stellt die Frage: „Wie sieht die nächste Version unseres Produktes (oder unseres Service) aus?“ Es stellt nicht die Frage, womit sich das Entwicklungsteam beschäftigt. Daher finden sich in einem guten Product Backlog auch keine Todos oder Aktivitäten.
Bei Softwareprojekten haben wir uns daran gewöhnt, Product Backlog Items in Form von sog. User Storys festzuhalten.
Es gibt kritische Stimmen zum Einsatz von User Storys, weil in einigen Teams der Sinn von User Storys noch nicht angekommen ist. User Storys, die Funktionen des Produktes beschreiben, sind nützlich. User Storys, die nur das Format erfüllen, aber nicht wirklich zeigen, wie sich das Produkt dadurch verbessert, helfen nicht.
Eine User Story ist so zu lesen: „Ab der nächsten Version unseres Produktes kann ein Anwender, der sich am ehesten der Rolle X zuordnen lässt, auch noch Tätigkeit Y machen, damit er sein Ziel Z erreicht.“
Jeff Gothelf und Josh Seiden schlagen in Lean UX ein anderes Format vor: „Wir glauben, dass wir das Ziel A erreichen, wenn wir die Funktion B für die Leute der Benutzergruppe C anbieten. Wir merken, dass dies wahr ist, wenn das Feedback D da ist.“ (/1, S. 23/).
Es gibt einige Leute, die von technischen User Storys sprechen. Sie meinen damit oft die Einrichtung oder Anpassung der Infrastruktur wie z. B. das Einrichten einer Datenbank. Das sind aus meiner Sicht keine User Storys, weil sie keinen Wert für einen Nutzer beschreiben. Es sind einfach Tätigkeiten, die im User-Story-Format beschrieben sind. Aber diese Tätigkeiten kann man auch in der Sprintplanung als Tasks an die erste User Story hängen.
Immer, wenn sich Menschen vorm Bildschirm vor einem Schalter befinden, eignen sich User Storys, um die Ziele festzuhalten.
Wie sieht es mit einem komplexeren Produkt aus, das aus Hardware, Software, Dokumentation und externen Zertifikaten besteht?
Bei technischen Anlagen kann man sich an Konzepten wie Quality Function Deployment oder Modular Function Deployment orientieren. Bei dieser Arbeitsweise werden erst die Funktionen aufgelistet, die das Produkt haben soll und dann die technische Umsetzung. Gunnar Erixon führt in seiner Arbeit ein Beispiel für einen Staubsauger auf. Die Hauptfunktion ist das Entfernen von Schmutz und Staub. Die Unterfunktionen davon sind „Vakuum erzeugen“, „jeden Platz erreichen“ und „Staub entsorgen“. Als technische Lösungen kommen dann ein Lüfter, eine mobile Einheit und ein entsorgbarer Beutel in Betracht /2, S. 107/. Der Vorteil dieser Vorgehensweise ist, dass das Entwicklungsteam neben den bereits bekannten technischen Lösungen auch neue Ideen findet. Z. B. könnte man statt eines Beutels auch einen herausnehmbaren Behälter nehmen. Oder man könnte den Staub auf der anderen Seite wieder herausblasen. Für einen Staubsauger vielleicht eine merkwürdige Idee. Aber für eine Schneefräse passt es.
Glen Alleman schlägt vor, in Fähigkeiten zu denken, die das Produkt oder der Service bedienen sollen. Im Beispielprojekt eines Küchenumbaus soll die neue Küche „fähig“ sein, folgende Dinge zu tun /3, Pos. 2211/:
Perfekt! Wenn Sie es bereits wissen, dann listen Sie doch einfach die Teile auf, die alle geliefert werden sollen:
Ilia Pavlichenko schreibt in einem Blogbeitrag bei scrum.org, dass die Product Backlogs oft sehr unordentlich sind. Die Erfahrung machen wir auch in unseren Projekten. Deswegen empfehlen sich ein paar Prüffragen:
Was sagt der Scrum Guide über ein Product Backlog?
Im Scrum Guide (vom November 2017) steht:
„Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. Ein Product-Backlog-Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert. Product-Backlog-Einträge enthalten oft Testbeschreibungen, die ihre Vollständigkeit nachweisen, wenn sie fertig [„Done“] sind.“
Das Product Backlog stellt die Frage: „Wie sieht die nächste Version unseres Produktes (oder unseres Service) aus?“ Es stellt nicht die Frage, womit sich das Entwicklungsteam beschäftigt. Daher finden sich in einem guten Product Backlog auch keine Todos oder Aktivitäten.
Das Product Backlog listet Ergebnisse auf
Bei Softwareprojekten haben wir uns daran gewöhnt, Product Backlog Items in Form von sog. User Storys festzuhalten.
Es gibt kritische Stimmen zum Einsatz von User Storys, weil in einigen Teams der Sinn von User Storys noch nicht angekommen ist. User Storys, die Funktionen des Produktes beschreiben, sind nützlich. User Storys, die nur das Format erfüllen, aber nicht wirklich zeigen, wie sich das Produkt dadurch verbessert, helfen nicht.
Eine User Story ist so zu lesen: „Ab der nächsten Version unseres Produktes kann ein Anwender, der sich am ehesten der Rolle X zuordnen lässt, auch noch Tätigkeit Y machen, damit er sein Ziel Z erreicht.“
Jeff Gothelf und Josh Seiden schlagen in Lean UX ein anderes Format vor: „Wir glauben, dass wir das Ziel A erreichen, wenn wir die Funktion B für die Leute der Benutzergruppe C anbieten. Wir merken, dass dies wahr ist, wenn das Feedback D da ist.“ (/1, S. 23/).
Es gibt einige Leute, die von technischen User Storys sprechen. Sie meinen damit oft die Einrichtung oder Anpassung der Infrastruktur wie z. B. das Einrichten einer Datenbank. Das sind aus meiner Sicht keine User Storys, weil sie keinen Wert für einen Nutzer beschreiben. Es sind einfach Tätigkeiten, die im User-Story-Format beschrieben sind. Aber diese Tätigkeiten kann man auch in der Sprintplanung als Tasks an die erste User Story hängen.
Immer, wenn sich Menschen vorm Bildschirm vor einem Schalter befinden, eignen sich User Storys, um die Ziele festzuhalten.
Wie sieht es mit einem komplexeren Produkt aus, das aus Hardware, Software, Dokumentation und externen Zertifikaten besteht?
Bei technischen Anlagen kann man sich an Konzepten wie Quality Function Deployment oder Modular Function Deployment orientieren. Bei dieser Arbeitsweise werden erst die Funktionen aufgelistet, die das Produkt haben soll und dann die technische Umsetzung. Gunnar Erixon führt in seiner Arbeit ein Beispiel für einen Staubsauger auf. Die Hauptfunktion ist das Entfernen von Schmutz und Staub. Die Unterfunktionen davon sind „Vakuum erzeugen“, „jeden Platz erreichen“ und „Staub entsorgen“. Als technische Lösungen kommen dann ein Lüfter, eine mobile Einheit und ein entsorgbarer Beutel in Betracht /2, S. 107/. Der Vorteil dieser Vorgehensweise ist, dass das Entwicklungsteam neben den bereits bekannten technischen Lösungen auch neue Ideen findet. Z. B. könnte man statt eines Beutels auch einen herausnehmbaren Behälter nehmen. Oder man könnte den Staub auf der anderen Seite wieder herausblasen. Für einen Staubsauger vielleicht eine merkwürdige Idee. Aber für eine Schneefräse passt es.
Glen Alleman schlägt vor, in Fähigkeiten zu denken, die das Produkt oder der Service bedienen sollen. Im Beispielprojekt eines Küchenumbaus soll die neue Küche „fähig“ sein, folgende Dinge zu tun /3, Pos. 2211/:
- Die Küche soll genug Platz, Zugriffsmöglichkeiten und einen guten Fluss durch die Küche bieten, um Dinnerpartys mit 12 Paaren veranstalten zu können.
- Die Geräte sollen die Energiesparvorgaben noch unterbieten.
- Es soll möglich sein, drei Hauptgänge gleichzeitig zu kochen. Es soll genug Platz geben, um die Küchenutensilien unterzubringen und um die Teller zu servieren.
Perfekt! Wenn Sie es bereits wissen, dann listen Sie doch einfach die Teile auf, die alle geliefert werden sollen:
- Gerät X mit den Moduln A, B und D. D ist eine neue Variante von C mit den Änderungen a, b, und c.
- Software Y mit folgenden Anpassungen …
- Anwenderdokumentation mit Kurzanleitung, Handbuch und Onlinehilfe.
- Vertriebsdokumentation mit Beschreibung auf Webseite, Preisliste in 3 Sprachen für 15 Regionen.
- Zulassungsdokumente
Wird das wirklich alles gebraucht?
Ilia Pavlichenko schreibt in einem Blogbeitrag bei scrum.org, dass die Product Backlogs oft sehr unordentlich sind. Die Erfahrung machen wir auch in unseren Projekten. Deswegen empfehlen sich ein paar Prüffragen:
- Fehlt dem Kunden etwas, wenn ich diesen Eintrag weglasse?
- Was passiert mit der Lieferung, wenn ich diesen Eintrag weglasse?
- Ist es möglich, das gleiche Ergebnis mit dem halben Aufwand zu liefern?
- Geht es auch einfacher?
- Würde der Kunde für diesen Backlogeintrag extra bezahlen?
- Erzeugt dieser Eintrag mehr Komplexität?
Anmerkungen
- /1/ Gothelf, Jeff: Lean UX : Applying Lean Principles to Improve User Experience. Sebastopol: "O'Reilly Media, Inc.", 2013.
- /2/ Erixon, Gunnar. Modular function deployment: a method for product modularisation. Royal Inst. of Technology, Department of Manufacturing Systems, Assembly Systems Division, 1998.
- /3/ Alleman, Glen B.: Performance-Based Project Management : Increasing the Probability of Project Success. New York: AMACOM Div American Mgmt Assn, 2014.
- /4/ Ilia Pavlichenko: When Product Backlog Is A Mess, Blog der scrum.org, erschienen am 27. Juni 2017, abrufbar unter https://www.scrum.org/resources/blog/when-product-backlog-mess
Kommentare
Kommentar veröffentlichen