Gut gedacht – zu viel gemacht: wenn User Stories Spielraum lassen

PrintFriendly and PDF

spielraum

Auch in gut laufenden agilen Projekten ist am Ende eines Sprints nicht immer das entstanden, was am Wichtigsten gewesen wäre. Dafür lassen User Stories zu viel Spielraum.

In einem Projekt sind alle User-Stories gut durchdacht, die Prioritäten klar verteilt und die Entwickler arbeiten die Stories streng nach Priorität ab. Trotzdem ist der Kunde am Ende der Sprints nicht zufrieden: Wichtiges wurde nicht geschafft, Unwichtiges hingegen getan. Wie kann das passieren?

User Stories lassen Spielraum in der Umsetzung

Eine User Story beschreibt nur, was das System ermöglichen soll, nicht aber, wie das System genau aussehen soll. Die aus einer User Story abgeleiteten Anforderungen sollen sich zwar während eines Sprints nicht ändern. Jedoch kann kaum ein Kunde alle Details im Voraus vollständig durchdenken und spezifizieren. Viele Fragen klären sich erst im Laufe eines Sprints.

Als Entwickler taucht man im Laufe der Umsetzung automatisch tief in die Details ein und es fallen einem Sonderfälle und unvorhergesehene Probleme auf. Gleichzeitig kommen einem viele gute Ideen, wie man das System und sein Verhalten verbessern kann. Das betrifft sowohl das Innere des Systems als auch seine Oberfläche.

Vor allem in der UI gibt es viele Wege, die Bedienerfreundlichkeit zu verbessern. Die einfachste Art, eine neue Funktion zu integrieren, mag zwar ausreichen, um die User Story abzuschließen und den Kunden zufrieden zu stellen. Aber als Entwickler identifiziert man sich mit seiner Arbeit und möchte sie schön abliefern. Somit ist es verführerisch, die Umsetzung aufzuhübschen und Aufwand in Dinge zu stecken, die weniger wichtig sind, als die folgende Story anzugehen.

Aber auch im Design des Systems gibt es viele Wege, eine User Story umzusetzen. Vor allem, wenn man etwas Anspruch an die Qualität seiner Arbeit hat und gerne ein paar Schritte voraus schaut, ist die Versuchung groß, eine einfache Aufgabe komplexer umzusetzen als nötig.

Eine strenge Definition of Done verlangt eine vollständige Umsetzung

Eine weitere Falle liegt in der Definition of Done – einer Übereinkunft, wann eine User Story als fertig umgesetzt gilt. Eine strenge Auslegung der Definition of Done besagt, dass eine User Story erst dann fertig ist, wenn sich das Team später nicht noch einmal damit befassen muss. Der Vorteil dieser Auslegung ist, dass der Kunde sofort alles erhält, was er bestellt, und alle aufgetretenen Fehler beseitigt sind.

Jedoch ist nicht jede Teilfunktionalität einer User Story gleich bedeutend wie jede andere. Auch in User Stories mit der höchsten Priorität finden sich Aufgaben, die für das Gesamtprojekt eine geringere Priorität haben. Bei einer strengen Definition of Done werden somit alle Aspekte einer User Story sofort erledigt, auch diejenigen, die weniger wichtig sind als die folgenden User Stories.

Was lässt sich tun?

Ich sehe die Verantwortung in erster Linie bei uns Entwicklern. Wir müssen selber darauf achten, keine Nebenthemen mit geringer Wichtigkeit anzugehen. Vor allem bei unseren eigenen Ideen müssen wir vorsichtig sein. Mit diesen Ideen identifizieren wir uns und möchten sie gerne realisieren, ungeachtet der Bedeutung für den Kunden.

Darüber hinaus halte ich es für wichtig, auch die kleinen Details während des Sprints eng mit dem Kunden abzustimmen und klare Entscheidungen einzufordern, was getan und gelassen werden soll.

Schließlich ist auch die Definition of Done nicht nur Sache des Entwicklerteams, sondern muss ebenso mit dem Kunden abgestimmt werden. Der Kunde muss wissen, ob eine strenge Definition of Done in seinem Interesse ist.

Und hier noch ein paar Tipps zum Weiterlesen: