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

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