Direkt zum Hauptbereich

Was steht in einem Product Backlog?

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?


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.
Jetzt werden Sie sagen: „Alles schön und gut, Jan. Ich weiß doch, aus welchen Teilen mein Produkt besteht. Wieso soll ich mir die Mühe machen und das Format ändern?“

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
Gehen Sie einfach mit dem Entwicklungsteam rückwärts den Ablauf durch: welche End- und Hilfsprodukte werden im Projekt gebraucht?

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?
Projektteams neigen dazu, sich viel Arbeit zuzumuten. Es lohnt sich, jeden Eintrag im Product Backlog zu prüfen, ob er einen Zusatznutzen stiftet.

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

Beliebte Posts aus diesem Blog

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

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.

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.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

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.

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?

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.