“The engineers of the future will be poets.”
Terence McKenna
Der Product Owner hat die Aufgabe, dem Development Team zu erzählen, was der Kunde benötigt. Das klingt erst einmal sehr einfach, ist aber eines der größten Probleme der Software Entwicklung.
In der Vergangenheit wurden gerne dicke Pflichtenhefte und Spezifikationen geschrieben, die von sich behaupteten, jedes Detail der Kundenanforderungen zu adressieren. Häufig genug fehlten aber nicht nur viele Details, oftmals waren wichtige Aspekte schlicht vergessen worden. Das weitaus größere Problem mit diesen Pflichtenheften war jedoch der Zeitaufwand für die Erstellung. Bis manches Pflichtenheft erstellt war, konnten sich die Kundenanforderungen schon mehrfach geändert haben.
Um schnell auf Änderungen zu reagieren, arbeiten agile Methoden iterativ. In jeder Iteration wächst die bestehende Lösung um neue Kundenanforderungen an. Die Aufgabe des Product Owners ist es, alle bekannten Kundenanforderungen zu sammeln um sie beizeiten mit dem Team zu klären und umsetzen zu lassen. Die Sammlung dieser Anforderungen nennt sich Product Backlog.
“Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when ‘Done’.”
Scrum GUIDE
Obwohl im Scrum Guide nicht angegeben ist, wie die Kundenanforderungen zu formulieren sind, verwenden fast alle Scrum Teams das User Story Format. Alternativ könnten die Kundenanforderungen also auch in Form von Use-Cases oder Limericks formuliert werden.
Alle User Stories haben den folgenden grundlegenden Aufbau.
“Als Rolle möchte ich Funktion haben, weil Nutzen“
Die Rolle entspricht dabei einer Gruppe von Anwender der Software, z.B. Ahnenforscher, Administrator oder Archivar. Die Funktion ist eine irgendwie geartete Funktionalität, die sich der Anwender vorstellt. Der Nutzen ist dabei Hinweis auf die Motivation des Anwenders und auf den Wert der Funktion für ihn.
Ein Hinweis, ob eine User Story gelungen ist, geben die INVEST Kriterien.
Independent: Eine User Story ist unabhängig von anderen Stories. Stories die erst bearbeitet werden können, nachdem andere Stories fertiggestellt wurden, können nicht unabhängig priorisiert werden. Aus dem Backlog wird so leicht ein Abhängigkeitsgeflecht. Üblicherweise passiert dies, wenn Stories falsch geschnitten werden und nur technische Aspekte behandeln, z.B. Einrichten der Datenbank, Ändern der Rest Schnittstelle, Einbau einer Queue.
Negotiable: User Stories sind kein Pflichtenhefte, sondern Diskussionsgrundlage. Sie werden vom Product Owner und dem Development Team gemeinsam detailliert, umformuliert oder sogar verworfen. Bis zur Umsetzung im Sprint können sich Voraussetzungen, Verständnis und Mehrwert einer Story verändern. Auch aus diesem Grund werden User Stories im Planning auch nicht einfach abgehakt, sondern noch einmal besprochen.
Valuable: Jede Story muss einen Mehrwert für den Kunden liefern. Ohne einen Mehrwert für den Kunden ist ein neues Feature sinnlos und sollte verworfen werden. Aber immer wieder tauchen Stories im Backlog auf, die sich mit dem technischen Unterbau der Software beschäftigen und keinen Mehrwert für den Kunden beinhalten. Manche Kollegen finden es schick, mit solchen Stories Probleme der Architektur für die Stakeholder sichtbar zu machen. In meinen Augen weisen solche Stories in der Regel nur darauf hin, dass die Teams sich in ihrer Eigenständigkeit unsicher fühlen und sich die Erlaubnis der Verantwortlichen abholen möchten.
Estimatable: Die Entwickler müssen die Umsetzung der Story abschätzen können. Ist dies nicht möglich, dann ist entweder die Story unverständlich, die Story ist zu groß oder es fehlen die notwendigen Kompetenzen im Team. Dann muss die User Story entweder in mehrere kleinere Stories aufgeteilt werden oder der Inhalt weiter diskutiert werden.
Small: Eine User Story sollte gut in einen Sprint passen, denn sonst kann das Development Team die Story nicht fertig stellen. Große Stories haben den Nachteil, dass die Komplexität und die Anhängigkeiten überproportional anwachsen. Wenn die Möglichkeit besteht eine User Story zu verkleinern, dann sollte davon Gebrauch gemacht werden.
Testable: Nur über Tests kann geprüft werden, ob eine Story erfolgreich umgesetzt wurde. Kann man eine Story nicht testen, dann hat sie zumeist auch keinen Mehrwert für den Kunden.
Werden Online-Tools wie Jira zur Erstellung von Stories verwendet, entwickeln sich allzu leicht einige Bad Practices, die man tunlichst abstellen sollte.
Es wird zuwenig formuliert und referenziert. Vielleicht existiert irgendwo eine Spezifikation oder eine Wiki-Seite, auf der jemand schon einige Informationen zusammengetragen hat. Dann kann die Versuchung groß sein, nur einen Verweis in die Story zu schreiben. Dieses Vorgehen hat viele ganz unterschiedliche Nachteile. Zum einen bekommt das Development Team das Gefühl, der Autor der User Story gibt sich keine große Mühe. Das Arbeiten mit verteilt dokumentierten User Storys ist unübersichtlich, zeitaufwendig und erzeugt Frust. Andererseits kann das referenzierte Dokument mehr Informationen enthalten, die nicht zur Story gehören. Dann ist es ein Glücksspiel für den Product Owner, was er am Ende tatsächlich erhält. Bei Referenzen kann es auch passieren, dass die Dokumente am anderen Ende sich laufend verändern und auch dann nicht klar ist, was tatsächlich entwickelt wird.
Es wird spezifiziert. Der wunderbare Vorteil einer Karteikarte zum Formulieren von User Stories ist ihre Größe. Der Autor ist gezwungen sich kurz zu halten. Ist das Formular einer Online Story geöffnet, dann können viele Details der gewünschten Funktionalität formuliert werden. Die User Story wächst unaufhörlich an und wird spätestens im Refinement vom Development Team gestutzt.
Es wird archiviert. Ein Stapel Karten auf dem Schreibtisch gibt dem Product Owner eine bessere Sicht auf die Menge der unrealisierten User Stories als ein Online Tool. Natürlich weiß er, dass er 300 Stories noch vor sich hat, aber er kann sie sortieren, verschieben, filtern. Das gibt ein Gefühl der Kontrolle und Sicherheit die nicht existiert. Und immer wieder tauchen dann aus den Tiefen der Tools längst vergessene Features wieder auf, für die es eigentlich schon viel zu spät ist.
Es wird kommentiert. Online Tools wie Jira sind eigentlich Ticket Systeme und keine Online Backlogs, daher kann man darin User Stories kommentieren. Das Diskutieren der User Stories sollte aber in den obligatorischen Scrum Meetings erfolgen, denn so werden tatsächlich alle Argumente und Ideen erörtert. Außerdem kommt es immer wieder vor, dass Änderungen an der User Story nicht in der Beschreibung stehen sondern im Kommentarverlauf. Wird eine solche Änderung übersehen, dann produziert das Development Team etwas falsches.
Es wird selbst geschrieben. Grundsätzlich kann jeder Einträge ins Backlog einfügen. Egal ob Kunde, Manager, Product Owner oder Entwickler. Leider kann nicht jeder eine gute User Stories formulieren und mancher schneidert seine User Stories auf sich zu. Funktioniert das Scrum Team, dann werden solche Stories korrigiert, anderenfalls degeneriert das Team zu Einzelkämpfern.
In welcher Form auch immer Backlog Einträge formuliert werden, wichtig bleibt die Diskussion aller Beteiligten über den darin enthaltenen Mehrwert für den Kunden.
Ein Spediteur auf den Kanaren
der möcht’ kein Bild von seinen Waren
denn ob schwarz oder bunt
ob eckig ob rund
er will beim Druck Toner sparen!
Ein Backlog Limerick