Der Product Backlog
Der Product Backlog kann als ein Speicher für die Anforderungen (Features), aber auch alle anderen im Verlaufe der Projektentwicklung angedachten Aufgabenstellungen gesehen werden. Sein Inhalt wird vom Product Owner in Abstimmung mit dem Kunden erstellt. Dies geschieht oft im Rahmen eines Workshops, kann aber auch basierend auf bestehenden Anforderungsdokumenten (Lastenhefte, Anforderungskataloge etc.) geschehen, wobei es in jedem Fall ausschlaggebend für den Projekterfolg ist, dass Anforderungen mit dem Kunden besprochen und geklärt werden. Für eine erfolgreiche Umsetzung ist es wichtig, mit dem Kunden gemeinsam Umfang und Inhalt von Anforderungen festzustellen und gemeinsam festzulegen, was der Kunde erwartet und was nicht.
Der Product Backlog wird vom Product Owner verantwortet. Er entscheidet, welche Einträge aufgenommen werden und wie mit diesen verfahren wird. So kann er Einträge aufteilen, zusammenfügen, anpassen oder gar wieder aus dem Product Backlog entfernen. Er priorisiert die Inhalte auch basierend auf deren Wertschöpfung fürs Unternehmen (Business Value). Dabei sind neben Nutzen und Kosten auch das Risiko und ggf. weitere Faktoren von Bedeutung. Die Auswahl und Gewichtung der Kriterien obliegt dabei dem Product Owner. Es ist seine Verantwortung, sicherzustellen, dass der Kunde für sein Investment eine maximale Wertschöpfung erzielt.
Zur Verwaltung des Product Backlogs werden teils spezialisierte Software-Produkte eingesetzt, aber viele Organisationen arbeiten auch mit Excel oder Karten. Tatsächlich stellt man immer wieder fest, dass gerade viele spezialisierte Werkzeuge relativ geringe Freiheitsgrade erlauben und Teams manchmal sogar in Vorgehensweisen zwingen, welche von diesen eigentlich nicht gewollt sind. Entsprechend empfiehlt es sich in jedem Fall vor der Anschaffung irgendwelcher Tools oder dem Buchen irgendwelcher Online-Services Erfahrungen mit Scrum zu machen, um danach, bei Bedarf, basierend auf den eigenen Bedürfnissen die richtigen Werkzeuge zu beschaffen.
User-Stories
Eine gebräuchliche Form, Kundenanforderungen festzuhalten, stellen User-Stories dar. Dabei werden Anforderungen strikt aus Business-Sicht so festgehalten, dass sie die Kommunikation mit dem Kunden unterstützen und dabei verifiziert werden können. Der Aufbau einer User-Story folgt einer einfachen Struktur:
Als *Rolle* möchte ich *Wunsch*, damit ich *Nutzen*.
Ein einfaches Beispiel könnte sein:
Als *Kunde* möchte ich *meine offenen Rechnungen online einsehen können*, damit ich *sicherstellen kann, dass ich keine Rechnungen übersehe und diese fristgerecht bezahlen kann*.
Tatsächlich empfiehlt es sich dabei, gerade in Bezug auf die Rolle möglichst konkret zu werden. So ist es durchaus denkbar, dass unterschiedliche Kunden Angebote ganz unterschiedlich nutzen und ganz unterschiedliche Wünsche an eine Lösung haben. Werden diese verschiedenen Ansprüche festgehalten, kann die Lösung womöglich passgenauer ausgerichtet werden. Dazu empfiehlt es sich, Rollen klarer darzustellen, also beispielsweise von «Endkunde» oder gar von «Inhaber eines Handwerksbetriebes» zu sprechen, wenn diese Rolle spezifische Anforderungen hat. Ansätze wie der Einsatz von Personas haben sich hierbei bewährt.
Bei der Formulierung von User-Stories (oder auch weiterer Anforderungen) sollte darauf geachtet werden, dass stets das gewünschte Ziel und nicht der Weg dorthin festgehalten wird. Wer dem Entwicklerteam ein fertiges Entwicklungsrezept vorsetzt, welches dieses nur noch abarbeiten muss, nutzt dabei nicht die Fähigkeiten und Erfahrungen der Fachleute für die Entwicklung von Anforderungen und wird damit womöglich nicht die beste Lösung mit der höchsten Wertschöpfung erhalten.
User Stories – «3C-Pattern»
Es ist wichtig zu verstehen, dass eine User-Story nicht einfach ein Auszug aus einem Anforderungsdokument ist, sondern eine Aufforderung zum Dialog darstellt. Dies wird mit dem «3C–Pattern» dargestellt. «3C» steht dabei für Card / Conversation / Confirmation. Gemeint ist damit, dass die festgehaltenen User-Stories mit dem Kunden besprochen werden. Es gilt sicherzustellen, dass Anforderungen richtig verstanden wurden, dass möglichst alle Fragen in Hinblick auf eine Umsetzung geklärt wurden und sichergestellt wird, dass auch Rahmenbedingungen, Anforderungsgrenzen, Nutzen etc. verstanden sind. Nur so kann sichergestellt werden, dass das Team auch das Richtige umsetzt und sich nicht in Nebenschauplätzen verliert und der Product Owner die Anforderung andererseits richtig priorisieren kann. Basierend auf diesem Gespräch wird der Product Owner auch die Akzeptanzkriterien festlegen und mit dem Kunden abstimmen. Man könnte diese so umschreiben: «Das, was genau umgesetzt werden muss, damit die Anforderungen und die Nutzenserwartung des Kunden in Bezug auf dieses Feature erfolgreich umgesetzt wurde.»
Epics (Epen) und Tasks (Aufgaben)
Anforderungen können in verschiedener Form festgehalten werden. Wichtig ist dabei, dass die Form sicherstellt, dass sowohl die Kommunikation mit dem Kunden sichergestellt wird, wie auch ermöglicht werden muss, dass die Entwickler die Anforderung korrekt umsetzen können. User-Stories sind dabei eine der häufigsten Formen, es sind aber durchaus auch andere denkbar, wie beispielsweise Use-Case-Darstellungen oder einfacher Text.
Neben User-Stories finden sich in Bezug auf Aufgabenstellungen und Anforderungen in der Literatur oft noch zwei weitere Ausdrucke: Epics (Epen) und Tasks (Aufgaben).
Epics stellen grosse Anforderungsblöcke dar, welche noch nicht weiter detailliert sind und erst im Verlauf der Entwicklung – wenn die Priorisierung sie in die «oberen» Bereiche des Produkt Backlogs hebt – weiter detailliert und bearbeitet werden. Auch hier gilt die Idee, dass in Scrum «Just in Time» geplant wird. Es macht keinen Sinn, Anforderungen bereits zu einem Zeitpunkt zu detaillieren, wo die Umsetzung noch weit in der Zukunft liegt und sich sowohl Rahmenbedingungen wie auch Kundenanforderungen noch verändern können. Erst wenn die Umsetzung in greifbarer Nähe ist, macht es Sinn, darauf Zeit zu verwenden.
Tasks sind Einzelaufgaben, welche das Entwicklerteam im Rahmen der Sprint-Planung als Teile zur Umsetzung von Product-Backlog-Items (Anforderungen) identifiziert hat. Sie werden nur auf Ebene des Sprint Backlogs genutzt, nicht aber auf der Ebene «Product Backlog». Tasks bilden die Grundlage für die Planung der Arbeitsabläufe innerhalb des Sprints.
INVEST-Pattern und Definition of Ready
Damit Anforderungen, unabhängig davon, ob diese in Form von User-Stories oder in anderer Form festgehalten wurden, erfolgreich vom Entwicklerteam umgesetzt werden können, sollten diese gewisse Grundvoraussetzungen erfüllen. Man könnte hier auch von einem Quality Gate sprechen. Es wird auch oft «Definition of Ready» genannt. Die dabei genutzten Kriterien werden mit dem «INVEST-Pattern» dargestellt.
I ➔ Independent (unabhängig) – User-Stories sollen untereinander so unabhängig wie möglich sein. Wenn wir untereinander abhängige Anforderungen haben, reduziert sich für den Produkt Owner die Freiheit, die Priorisierung der Anforderung nach ihrem Business Value zu gestalten und er muss stattdessen manche (weniger wertvolle) Anforderungen vorziehen, weil andere, höherwertige, davon abhängig sind.
N ➔ Negotiable (verhandelbar) – Gemeint ist, dass Anforderungen zur Kommunikation und Diskussion anregen sollen. Anforderungen sollen so festgehalten werden, dass das Entwicklungsteam verschiedene Lösungsansätze diskutieren und den für den Kunden Sinnvollsten auswählen kann.
V ➔ Valuable (wertvoll) – Jede Anforderung soll in sich einen Beitrag zur Wertschöpfung des Kunden leisten (Business Value) und darauf basierend priorisierbar sein. Anforderungen, welche keine Wertschöpfung bieten, können womöglich vernachlässigt werden.
E ➔ Estimate-able (schätzbar) – Anforderungen sollen so formuliert werden, dass das Entwicklerteam die Möglichkeit hat, sich über den Umsetzungsaufwand zu verständigen und diesen zu schätzen.
S ➔ Small (klein) – Anforderungen, welche bereit zur Umsetzung sind, sollten klein genug (gemeint ist der Aufwand für ihre Umsetzung) sein, um im Verlauf eines Sprints umgesetzt zu werden. Idealerweise sollten die Anforderungen dabei nicht «genau» den Sprint ausfüllen, sondern klein genug sein, dass das Entwicklerteam diese im Rahmen der Gesamtentwicklung einplanen kann. Noch nicht bereite Anforderungen (z.B. Epics) sind oft erheblich grösser. An ihnen muss noch gearbeitet werden, bis sie bereit sind, dass ein Entwicklerteam sie umsetzen kann.
T ➔ Testable (testbar) – Testen ist Teil jeder Entwicklung. Damit erfolgreich getestet werden kann, ist es notwendig, dass Akzeptanzkriterien und Anforderungen klar dargestellt wurden und dabei auch klar festgelegt wurde, welche Anforderungen enthalten sind und welche nicht.
Selbstverständlich sind die genannten Kriterien in vielen Fällen nur schwer messbar und wenn, dann enthält das INVEST-Pattern doch keine Grenzwerte. Was genau macht beispielsweise eine Anforderung mehr oder weniger wertvoll? In vielen Fällen wird dies nur der Kunde, oft erst beim Einsatz, festlegen können. Entsprechend geht es beim INVEST-Pattern mehr darum, dass man sich bei jeder Anforderung die entsprechenden Kriterien vor Augen hält und sicherstellt, dass diese beachtet wurden, als dass es klare Merkmale gibt, welche herbeigezogen werden könnten, um «Punkte» zu verteilen und basierend auf dem Resultat «ready» oder «nicht ready» entscheiden zu können.
