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

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.

Widerstand: ein Geschenk in hässlicher Verpackung? 6 Impulse für einen konstruktiven Umgang

"Widerstand gegen Veränderungen ist ein Geschenk in hässlicher Verpackung." Dieser Satz meines geschätzen Co-Creators Matthias Pahl, hat mich ins nachdenken gebracht.  Widerstand soll ein Geschenk sein? Fühlt sich häufig nicht so an oder?  These:  Hinter Widerständen steckt eine innere Logik. Widerstand möchte etwas schützten, etwas stabilisieren und im Gleichgewicht halten. So irrational der Widerstand daher kommen mag. Er erfüllt einen Zweck, der verstanden werden will.  In diesem Blogartikel biete ich Ihnen 6 Impulse an, die einen versöhnlichen Blick auf Widerstände gegen Veränderungen legen und Lösungsansätze bieten sollen. 1. Widerstand erfüllt einen Zweck & folgt eigenen Wertevorstellungen & Handlungslogiken Hinter dem Widerstand stecken oft Ängste, wie Kontrollverlust oder das Infragestellen der eigenen Kompetenzen. Auch das Festhalten an Bewährtem und Zweifel am Nutzen der Veränderungen spielen häufig eine Rolle. Diese wollen verstanden und respektiert werden.

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 . 

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?

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.

Microsofts Wolkenkuckucksheim - Mein Erklärmodell für SharePoint, Teams, OneDrive und OneNote

"Was ist eigentlich der Unterschied zwischen OneDrive, OneNote und SharePoint?" Diese Frage wird mir mir schon seit meinen ersten Workshops zu Microsoft 365 gestellt. Mein heimlicher Gedanke damals war: "Super, solange es diese Frage gibt, ist mein Job sicher!" :) Geantwortet habe ich: "Es ist verständlicher, wenn wir die Gemeinsamkeiten betrachten: Alle drei sind von Microsoft. Alle drei eignen sich zur digitalen Zusammenarbeit." Bleibt allerdings die Frage: Was benutzt man wofür? 

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.

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?