Vom Geschichten erzählen (User Stories)

In Scrum ist das Product Backlog der User Stories der zentrale Ort für Priorisierung und Umsetzung von Anforderungen. Die Qualität der User Stories ist somit ein wesentlicher Erfolgsfaktor für ein agiles Projekt. Für erfahrene Business Analysten aus traditionellen Projekten, welche möglicherweise die Rolle des Product Owner übernehmen, ist die Umstellung vom Schreiben klassischer Konzepte hin zum Verfassen von User Stories nicht immer ganz einfach. Während ein Softwarekonzept natürlich auch sukzessive entstehen kann aber letztendlich doch vollumfänglich alle notwendigen Funktionen beschreiben sollte, bevor eine Zeile Code umgesetzt wird, „lebt“ das Product Backlog parallel zur Entwicklung. Auch der Stil der User Stories unterscheidet sich fundamental von einem herkömmlichen Konzept. Wie man grundsätzlich an das Thema Agiles Requirement Engineering herangeht ist in der Fachliteratur hinlänglich beschrieben. In der Praxis zeigt sich oft, dass es einer gewissen Erfahrung und Lernkurve beim Schreiben von User Stories bedarf. Deshalb ist es sinnvoll, jedem „neuen“ Product Owner (PO) oder einem PO-Team einen erfahrenen PO zur Seite zu stellen, um folgende konkreten Risiken zu minimieren.
  • Falsche Priorisierung der Stories: Was benötigt man, um möglichst schnell einen „Durchstich“ zu bekommen, d.h. ein lauffähiges System? „Schöner machen“ kann man anschließend.
  • Definition of Ready wird nicht erreicht: Sind alle Aspekte inkl. der Akzeptanzkriterien enthalten und verstehen die Entwickler, was sie zu tun haben? Falls nicht, besteht die Gefahr, dass Funktionen mit nachfolgenden Stories mehrfach überarbeitet werden müssen, was den Aufwand in die Höhe treibt.
Was hier so banal klingt, kann in der Praxis sehr negative Konsequenzen haben. Scrum lebt davon, dass ein interdisziplinäres Team möglichst zu 100% für das Projekt abgestellt ist und zielgerichtet an einem Vorhaben arbeitet. Das bedeutet aber auch, dass dieses Scrum Team permanent zu 100% vom Projektbudget lebt, was die anfänglichen Kosten des Projekts im Vergleich zu einem klassischen Wasserfall-Projekt oft höher erscheinen lässt. Insofern ist es klar, dass dieses Budget möglichst zielgerichtet eingesetzt werden muss. Es sollte so schnell wie möglich ein Nutzen für den Endanwender ersichtlich sein. Auch wenn die finalen Gesamtkosten eines agilen Projekts meist positiver ausfallen als bei klassischen Projekten, besteht eben die Gefahr, dass Stakeholder auf „halber Wegstrecke“ die Notbremse ziehen, wenn das Kosten-Nutzen-Verhältnis aus ihrer Sicht nicht stimmt und sie das Gesamtzielbild nicht sehen. Genau aus diesem Grund ist das Schreiben der User Stories, die entsprechende Priorisierung und Strukturierung in sinnvolle und nachvollziehbare Epics und Releases ein wesentlicher Erfolgsfaktor.
November 2019
July 2019
November 2018
April 2018
October 2017
February 2017
November 2016
August 2016
June 2016
April 2016
March 2016
February 2016