Technische User Stories

Das letzte Treffen der SCRUM User Group Karlsruhe hatten das Product Backlog als Thema.

Es dauerte nicht lange, bis auch darüber diskutiert wurde, ob Dinge, die keine User Stories sind, in ein Product Backlog gehören. Dies ist nicht ungewöhnlich – an der Frage, ob es technische Stories in einem Scrum Product Backlog geben darf scheiden sich bekanntlich die Geister.

Ich schaue mir das Hin- und Her jetzt mehr als 6 Jahre an und ehrlich gesagt – mich langweilt es. Die einen verkaufen den Ansatz “nur Kundenanforderungen im Backlog”, die anderen beharren darauf, dass auch technische Themen explizit im Backlog zu platzieren sind.

Die einen sagen “technische Themen müssen autmatisch miterledigt werden”, die anderen weisen darauf hin, dass dies bei vielen Themen nicht möglich ist.

Die einen leben in einer Welt, in der (fast) alles neu ist, das Team organisatorisch gut aufgestellt und technisch überdurchschnittlich gut ist, die anderen stecken im Sumpf der Mittelmäßigkeit und wissen, dass sie froh darum sein müssen, zumindest durchschnittliche Entwickler zu haben, die an einem durchschnittlich gutem Bestandprodukt arbeiten.

Sind wir einmal ehrlich: Wir alle wissen, dass gewisse technische Themen nicht einfach “mit gemacht” werden können, da dies einen mehr als spürbaren Impact auf die Lieferleistung von Kundenanforderungen hat. Und wer hat ein Interesse an der Lieferleistung? Der Product Owner und die ganzen Stakeholder. Diese müssen wissen was passiert, schon alleine, da wir sonst nicht offen kommunizieren würden, was wir gerade tun (Verstoß gegen den Wert “Offenheit”).

Refactoring vs Redesign

Ich rede jetzt nicht vom einfachen Refactoring, welches im Rahmen einer Story durchgeführt werden kann, sondern von einem Redesign, welches auf Grund der Entscheidungen einer mehrjährigen Produktentwicklung mit einem durchschnittlichen Team irgendwann nötig wird. Interessant hierbei ist auch die Definition von Refactoring und Redesign: Ich verstehe unter Refactoring Arbeit zur Verbesserung der Softwarestruktur, die nicht mehr als 1-2 Tage maximal benötigt. Bei mehr Aufwand ist es kein Refactoring mehr sondern ein Redesign.

Qualität gesetzt?

Da können jetzt alle schreien: “Hey! Nicht sauber gearbeitet! Nicht aufgepasst!”. Aber wisst ihr was? Selbst ein Kernkraftwerk fliegt in die Luft weil es nicht perfekt ist und es zu Fehlern im Detail kommt. Wie soll es da um eine 08/15 Softwarelösung stehen, die unter Kostendruck mehrere Jahre lang entwickelt wurde? Bei der fast keiner der ursprünglichen Entwickler mehr da ist?

Kunde ist nicht der einzige Stakeholder

Für mich bedeutet dies, daß man sich der Realität stellen muss. Nicht nur Kunden haben ein Interesse an den durch das Team erstellen Artefakten. Nein, es sind ganze Heerscharen an Stakeholder. Was hilft es mir beispielsweise, wenn ich Mehrwert für Kunden schaffe, aber interne Reportingvorgaben nicht erfüllen kann?

Budget gestrichen, Produkt tot, alle arbeitslos. Kunden glücklich?

Das Problem mit der USER Story

Die Frage ist natürlich, ob dies eine USER Story ist oder eine andere Art von Backlog Item. Mittlerweile bin ich immer skeptischer, was USER Stories angeht. Folgt man der grundlegenden Idee von User Stories, dann wird man in komplexen Umgebungen Probleme bekommen. Warum? Werfen wir doch einen Blick in das Buch von Frank Wirdemann: “Scrum mit User Stories”. Erst kürzlich erneut versucht zu lesen, es aber nach kurzer Zeit wegen akutem Bluthochdruck wieder zur Seite gelegt. Das Buch ist “old school”, so wie ich Scrum vor 7 Jahren verstanden haben:

  • Eine User Story beschreibt keine Details sondern nur den Benutzeraspekt. Details sind böse, böse, böse!
  • Spezifikation erfolgt mündlich. Schriftliche Dokumentation ist böse, böse, böse!
  • Geschätzt wird in Story Points, die Dauer ist zu vernachlässigen (nicht relevant)
  • Man arbeitet mit einer gemittelten Velocity, Schwankungen in der Kapazität (Urlaub etc) werden nicht berücksichtigt (übers Jahr gesehen sind wir ja beim Mittel)

Ja, ich möchte in einem Umfeld arbeiten, in dem diese Ansätze ausreichen, um erfolgreich zu sein. Ich kann jedoch nur jeden warnen, in einem komplexeren Umfeld mit mehreren Stakeholdern, externen Terminen, Budgetplanungen etc. sich komplett auf diese vereinfachte Sichtweise zu verlassen

Ich habe mehr als ein Team gesehen, das “so” in das Verderben geführt wurde. Als Product Owner bin ich dann auch meist gezwungen, harte Kämpfe durchzustehen, um eine Planbarkeit zu bekommen. Die brauche ich, um ausserhalb des Scrum Teams argumentieren zu können. Kann ich dies nicht, dann stehe ich blank da.

Ja, das ist ein Impediment. Ja, daran muss gearbeitet werden. Aber hey, es ist zu just diesem Zeitpunkt eben Realität. Und jetzt einmal unter uns: Das Ignorieren der Realität hilft nur in Ausnahmefällen.

Vorgehensweise

Hierbei hilft es eine Kernaussage (User Story) ganz bewusst in der Nähe des Implementierungshorizontes mit Details zu annotieren. Oft ist es jedoch nicht leicht, herauszufinden, wann welche Details hinzugefügt werden müssen.

Damit wird wir schnell bei einem zentralen Thema in agilen Prozessen: Wie formulieren ich Anforderungen?

Dieses Thema werde ich in einem anderen Artikel – “Lebenszyklus eines Backlog Items” (ich vermeide hier “User Story”) diskutieren.

Ach – wer sich für ein umfassendes Modell von agilen Anforderungen interessiert, dem sei ein Artikel von Dean Leffingwell empfohlen: Updated Agile Requirements Metamodel (Enterprise Backlog Model)

One thought on “Technische User Stories

  1. Schöner Post. :)

    Ich habe mir die Frage ganz einfach danach beantwortet, was das Backlog aus meiner Sicht darstellen soll: die Produktvision. Und um allen Projektbeteiligten die Transparenz zu geben, entscheiden zu können, ob die Produktvision eingehalten werden kann, ist es meiner Meinung nach unerlässlich auch technische Anforderungen im Backlog festzuhalten.

    Wie sonst soll ein nicht-technischer Betrachter des Backlogs sehen können, dass die 25 nächsten User Stories nur die halbe Wahrheit sind.

Comments are closed.