User Stories vs. Bugs vs. Product Backlog Items

Der Product-Backlog ist eines der wichtigsten Artefakte im Scrum-Prozess und wohl eines der am meisten unterschätzten zugleich.

In ihm sammeln sich alle Ideen, alle Anforderungen und Gedankenblitze, die der Kunde oder auch der Entwickler beim Arbeiten mit einem Produkt haben. Egal ob ausgereift oder fern in der Zukunft: Der Product-Backlog bietet zukünftigen Arbeiten an einem Produkt ein Zuhause.

Dieses Zuhause ist ein lebendes Artefakt. Durch Refinements werden seine Einträge darin gepflegt und sortiert.

Oft werde ich Zeuge einer Diskussion, die davon handelt, was der Product-Backlog wirklich beinhaltet? Sind die enthaltenen Einträge ganz naheliegend Product-Backlog-Items? Oder sind es User Stories? Und dürfen Bugs auch eine Rolle spielen, auch wenn sie weder User-Story noch PBI sind?

Für mich beschreibt ein Product-Backlog-Item erstmal einen Eintrag im Product-Backlog. Nicht mehr und nicht weniger. Dies ist etwas, was für das fertige Produkt getan werden muss, aber es ist erstmal keine User-Story und es ist kein Bug o.ä. Schaut man sich den Product-Backlog jedoch näher an, muss man unterscheiden. Allein schon, um alles, was der Eintrag hergeben soll so aussehen zu lassen, dass er möglichst viele Informationen enthält, ohne das „Wie setzen wir es um“ zu beantworten.

User-Stories

Eine User-Story beschreibt ein fehlendes Feature eines Produkts und gibt dem Team Informationen und einen Kontext zu diesem Feature. Die Schreibweise „As a … [someone] want[s] … to …, so that…“ enthält so viele nützliche Dinge, dass das Team …

1. … das Problem erkennt
2. … das Verhalten der Software nach dem Problem versteht
3. … die Möglichkeit gibt, eventuell etwas besseres vorzuschlagen

All diese Punkte wären ohne die Formulierung, die im Übrigen nur einen Satz umfasst, in der Kürze nicht möglich. Eine User-Story gibt immer genug Kontext, eine Umgebung, wenn auch nur gedanklich, um das Team in die Situation von jemandem zu versetzen, das Problem zu verstehen und das Zielverhalten zu erkennen. Nur so kann man das Knowhow im Team durch Scrum nutzen und vielleicht eine besser Lösung finden.

Somit gibt es Product-Backlog-Items, die ohne weiteres eine User-Story sein sollten. Eine Formulierung, die der Product-Owner, der Kunde, das Team oder eine Kombination der genannten machen kann (im Review beispielsweise) sollte eine User-Story immer als eine solche erkennbar machen.

Somit: Nicht jedes Product-Backlog-Item ist eine User-Story wert. Aber manche Product-Backlog-Items sind als User-Story formuliert ideale Möglichkeiten die besten Lösungen umzusetzen und das maximale rauszuholen.

Bugs

Meiner Meinung nach gehören Bugs, ohne Wenn und Aber, in den Product-Backlog. Sie gehören geplant. Sie gehören priorisiert. Bugs sind keine User-Stories und Bugs sind keine Product-Backlog-Items. Sie sind natürlich ein Eintrag im Product-Backlog. Aber sie bleiben ein Bug. Trotzdem muss die Frage geklärt werden: „Ist der Bug wichtiger, als die User Story xyz und Product-Backlog-Item abc?“. Woher soll das Team sonst wissen, was es zuerst bearbeiten soll?

Bugs haben meistens eine Menge Informationen. Dazu gehören Schritte zum Nachstellen, aktuelles Verhalten, gewolltes Verhalten, also die Beschreibung des Fehlverhaltens. Im Idealfall noch Infos zum Betriebssystem, Screenshots/Videos und und und. Beim Lesen wird das Team also in die Lage versetzt schon alle möglichen Informationen über den Eintrag zu haben. Zwar in mehr als einem Satz, aber alle Infos sind da. Ein Bug erfüllt also auch hier den Zweck, alles zu wissen, was man wissen muss um den Bug zu beheben. Der Kontext ist vorhanden, es sollten wenig Fragen offen sein.

Product-Backlog-Items

Product-Backlog-Items sind meiner Ansicht nach Sachen, die in sich schon so informativ gereift sind, dass jedes Umformulieren keinen Mehrwert mehr erzeugen würde.

„Reduziere die Ladezeit der Seite xyz beim erstmaligen Laden auf unter eine Sekunde“ wäre ein Kandidat, der keine User-Story verdienen würde. Es ist klar, was gemacht werden muss, der Kontext ergibt sich ebenso. Die Frage „Wie wird es umgesetzt“ bleibt beim Team, die Anforderung ist absolut klar.

Zusammenfassung

Ein Product-Backlog hat von aussen gesehen viele Einträge. Eben Product-Backlog-Items. Diese können User-Stories sein, sie können Bugs sein. Oder eben Product-Backlog-Items bleiben. Man muss unterscheiden. Am Besten im Refinement im Team oder in der Diskussion. Wichtig ist, dass zwischen den verschiedenen Formen unterschieden wird und dass die Information, was getan werden muss, zweifelsohne übermittelt werden ohne die Frage zu beantworten, wie das Item umgesetzt werden soll. Der Kontext für das Team muss gegeben sein. Dies kann und sollte aber auch über Refinements geschehen. Der Product-Backlog ist ein lebendes Artefakt und sollte es durch die dynamik in den Items bleiben und so ein geeignetes Ort für Anforderungen und Wünsche jeder Art bieten. So bleibt er interessant und wird hoffentlich in Zukunft nicht mehr so sehr unterschätzt 😉

Einflüsse:

http://programmers.stackexchange.com/questions/102523/pbi-vs-user-story

https://social.msdn.microsoft.com/Forums/vstudio/en-US/f8ec9ec0-95c2-4cfa-8bdb-f9f4220d6698/whats-the-different-between-product-backlog-item-and-user-stories?forum=tfsworkitemtracking

http://blogs.adobe.com/agile/2012/06/20/does-every-item-in-the-product-backlog-require-a-user-story/