Jede User Story sollte beschreiben welchen Mehrwert sie erzeugt
Über die letzten Jahre habe ich mit einer mittleren zweistelligen Zahl von Product Ownern zusammengearbeitet, mit manchen nur einige Tage, mit anderen länger als ein Jahr. Es waren gute dabei, sehr gute, schlechte und durchschnittliche, aber einen Fehler haben sie früher oder später alle gemacht: das Verfassen einer User Story oder Anforderung aus der nicht hervorging welchen Mehrwert sie erzeugen sollte.
Klassische User Stories sind nach einem einheitlichen Muster aufgebaut: "Als <Person mit Rolle X> möchte ich <Aktion Y durchführen können> um <einen Mehrwert Z zu erhalten>". Bei diesem Vorgehen ist der Mehrwert offensichtlich, er ergibt sich aus dem Zwecksatz am Ende des Story-Titels. Einige meiner Product Owner wollten sich nicht auf dieses Muster einlassen, waren aber bereit die entsprechenden Informationen in die Detail-Felder zu schreiben, was etwa so aussah: Rolle: A, Funktionalität: B, Mehrwert: C. Eine weitere Möglichkeit wendet ein Kollege an mit dem ich gerade zusammenarbeite, indem er seinen Anforderungen einen "Motivations-Satz" hinzufügt: "Um den Microservice X aus dem Monolithen herauslösen zu können muss Voraussetzung Y geschaffen werden". Diese Variante macht vor allem bei Backend-lastigen Aufgaben Sinn. Zuletzt ist in einigen Fällen der Mehrwert so offensichtlich, so dass er nicht gesondert genannt werden muss, etwa im Fall "Optimierung der Seite für den Browser Q". Und hier lauert ein Risiko.
Gerade wenn ein Product Owner mit seinem Team schon seit längerem an einem Thema arbeitet sind das Verständnis untereinander und das Verständnis der Fachlichkeit häufig so gross, dass die Beteiligten glauben, der Mehrweit sei für sie eigentlich immer offensichtlich. Der Zwecksatz, bzw. die Motivation erscheint dann als ein "Schnörkel", den man "auch mal weglassen kann". Am Anfang mag das sogar stimmen, aber sobald sich diese Angewohnheit einmal einschleift sind meistens unangenehme Effekte die Folge. Einer davon kann sein, dass der Scope ausufert und "schon mal Vorarbeiten für eine spätere Story mitgemacht werden", was besonders dann ärgerlich ist wenn diese spätere Story wegpriorisiert oder nochmal umgeschrieben wird. In diesem Fall war die Arbeit umsonst. Auch das Gegenteil kann der Fall sein, etwa wenn "nur ein Minimum Viable Product umgesetzt wird", was zwar die Ressourcen schont, aber ggf. nicht ausrollbar ist weil das neue Feature nicht dem Nutzerführungs-Konzept entspricht. Und zwischen diesen beiden Grenzfällen gibt es noch zahllose Zwischen- und Misch-Typen.
Wenn der Mehrwert in einer der oben genannten Formen spezifiziert ist kann man dagegen ganz anders an die Umsetzung herangehen. Zum einen kann man sich fragen ob der Funktionsumfang für den angestrebten Mehrwert überhaupt ausreichend ist. Beispielsweise ist die Anforderung "ich möchte eine reduzierte mobile Version der Website haben" gegebenenfalls zu unspezifisch, während "ich möchte eine reduzierte mobile Version der Website haben, damit sie auch bei einer Edge-Verbindung in unter fünf Sekunden geladen wird" wesentlich klarer ist. Zum anderen gibt die Nennung des Mehrwertes dem Team ein Gefühl dafür, was im Zweifel weggelassen und nach hinten priorisiert werden kann. Auch hier ein Beispiel: die Story "Als Kunde möchte ich Vorschau-Kacheln mit möglichen Ersatzartikeln sehen" lässt nicht erkennen was auf diesen Kacheln abgebildet sein soll; die Versuchung ist groß dort mehr abzubilden als eigentlich nötig. Im Fall der Story "Als Kunde möchte ich Vorschau-Kacheln mit möglichen Ersatzartikeln sehen, damit ich die Preise vergleichen kann" ist die Lage wesentlich klarer. Produktname, Vorschaubild, Preis - mehr braucht es nicht um den angestrebten Mehrwert zu erreichen.
Zuletzt kann auch ein ganz spezieller Fall auftreten: ich habe es auch schon erlebt, dass Product Owner mir gar nicht sagen konnten welchen Mehrwert eine Story mit sich bringt. Die sind mir ehrlich gesagt sogar die liebsten - man kann sie einfach weglassen und kommt dadurch schneller voran als gedacht.
