Wenn das Product Backlog Einträge enthält, die für sich genommen nicht wertschöpfend sind, entsteht Rauschen. Das behindert das Scrum Team und die Stakeholder bei der Erstellung von wertvollen Produkten. Zeit das Rauschen mit einem einfachen Trick abzustellen!
Wie das Rauschen entsteht
Der Scrum Guide sagt bezüglich Inhalts des Product Backlog folgendes:
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.
Und ist damit relativ unspezifisch. Scrum gibt im Grunde keine Vorgaben, sondern erlaubt eigentlich alles, solange es Änderungen am Produkt beschreibt.
Das schafft auf der einen Seite wichtigen und notwendigen Freiraum für den Product Owner bei der Organisation seiner Übersicht aller Eigenschaften des zu erstellenden Produkts.
Auf der anderen Seite führt das aber häufig zu Einträgen, die zwar notwendige, aber nicht wertschöpfende Arbeiten und Arbeitsschritte beschreiben. Typische Beispiele dafür sind:
- Konzept für XYZ erstellen.
- Webserver einrichten.
- Datenmodell für Warenkorb designen.
- Einarbeitung in $Technologie.
Oft entstehen solche Einträge während des ehrenwerten Versuchs, die User Stories kleiner zu schneiden, und damit für das Development Team schätzbar zu machen. Aber diese Einträge schaffen für sich allein keinen echten Wert. Sie sind lediglich notwendige Teilschritte auf dem Weg zum eigentlichen Wert. Sie fallen damit in die Verantwortung des Development Teams, das in Selbstorganisation überlegt, in welchen Schritten der Wert hergestellt werden kann.
Das Rauschen behindert alle Beteiligten
Die Ansammlung von nicht wertschöpfenden Einträgen erzeugt ein Rauschen im Backlog, welches den Product Owner bei seiner eigentlichen Aufgabe behindert:
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.
Bei der Planung stören solche Einträge im Backlog natürlich. Es wird ungleich schwieriger eine Strategie für die Produktentwicklung zu erstellen.
Während der Umsetzung ist das Development Team ebenfalls dankbar für wenige, aber dafür klar wertschöpfende Einträge. Es hilft dem Team sich auf das Ziel zu fokussieren und die beste Lösung dafür zu entwickeln. Weiter fördert es die Selbstorganisation des Teams, da nur das Ziel, aber nicht bereits der Weg (in Form von Teilschritten) hierfür im Backlog sind.
Auch im Review sind diese Einträge problematisch. Als Stakeholder interessieren mich Dinge wie Wissensaufbau oder die Erstellung einer Infrastruktur nur bedingt. Als Stakeholder will ich wissen, was sich für mich konkret zum Positiven verändert hat. Ein Review, dessen Inhalt die Vorstellung dieser unterstützenden Arbeiten ist, ist mit hoher Wahrscheinlichkeit eine vertane Chance sich über das Inkrement und seine Eigenschaften auszutauschen. Das wäre schade, denn schließlich warten wir jetzt wieder ein Sprint bis zum nächsten Review. Die Feedback-Schleife konnte nicht optimal genutzt werden.
Ein Rauschen sollte daher in jedem Fall vermieden werden!
Erlebbare User Stories sind die Lösung
Tatsächlich ist es relativ einfach heraus zu finden, ob ein Eintrag im Backlog überhaupt wertschöpfend sein kann. Stellen Sie sich bei jedem Eintrag einfach die Frage “Ist das Ergebnis dieser Arbeit durch den Anwender der Software erlebbar?” Wenn die Antwort “Nein” ist, dann ist eine Wertschöpfung ausgeschlossen. Lautet die Antwort “Ja”, so kann es sich um eine wertschöpfende Arbeit handeln — muss aber nicht 🙂
Erlebbar bedeutet, dass die Änderung für den Nutzer in der Anwendung oder seiner Umgebung wahrnehmbar ist. Das Erlebnis bei der Benutzung der Anwendung wird durch die User Story geändert. Das kann eine neue Benutzerführung sein, eine Funktion, eine grafische Überarbeitung oder die Verbesserung der Performance. Die Änderung führt zu einem Mehrwert und idealer Weise löst Sie ein konkretes Problem eines Stakeholders.
Es geht bei dem Begriff erlebbar darum, ob die Früchte unserer Arbeit beim Benutzer “ankommen” und ein Wert entsteht.
Mir persönlich hilft es immer, wenn ich mich schon beim Schreiben der User Story frage, wie ich das Ergebnis im Rahmen des Review präsentieren will. Ist es möglich die User Story in der Anwendung durch einen Stakeholder testen zu lassen? Kann der Stakeholder den Wert erkennen? Was kann ich tun um das Ergebnis erlebbar zu machen? Gibt es Reports aus Teststellungen, Metriken, Handbücher mit deren Hilfe ich eine neue Funktion erleben kann?
Mir ist klar, das es nicht immer möglich ist sämtliche Anforderungen in erlebbaren User Stories zu beschreiben. Hierzu gehören nicht funktionale Anforderungen wie z.B. das Einhalten von Datenschutz und Datensicherheit, die Betriebsumgebung, den Betrieb oder die Dokumentation jeglicher Art. Aber häufig ist das ein Zeichen dafür, dass diese Anforderung kein Kandidat für eine User Story ist, sondern für die DoD (Definiton of Done), ein lokales Akzeptanzkriterium, oder einen Teilschritt in einer anderen User Story.
Viel Erfolg beim Ent-Rauschen Ihrer Produkt Backlogs 🙂
Wenn Sie mehr über mich und meine Sicht auf Agilität erfahren wollen, können Sie mir auf Twitter folgen. Ich würde mich freuen!
