Transparenz erhöhen durch Technische Stories

Agile Puristen vertreten oft die Meinung, dass es in einer agilen Organisation genau zwei Typen von Anforderungen gibt – Epics und User Stories. Es ist leicht zu motivieren, dass es mindestens auch noch Bug-Tickets geben sollte. Warum es sinnvoll ist neben User Stories auch technische Stories zu betrachten erkläre ich in diesem Beitrag.

Abhängigkeiten und Transparenz in User Stories

Schauen wir uns zunächst noch einmal an was eine User Story ist. Eine User Story beschreibt in der agilen Produktentwicklung eine Anforderung des Kunden an das Produkt. Hierbei stehen drei wesentliche Dinge im Vordergrund. Dies sind die Rolle in welcher sich der Kunde als Benutzer befindet, die umzusetzende Funktion und die Begründung für den Umsetzungswunsch. Die Schablone für eine User Story ist also wie folgt:

Als Rolle möchte ich das Feature, weil Begründung.

Es ist ganz natürlich, dass sich diese Feature oftmals Abhängigkeiten zwischeneinander aufweisen. Schauen wir uns also an, welche verschiedenen Arten von Abhängigkeiten es zwischen zwei User Stories geben kann.

Unabhängige User Stories

Zunächst können zwei User Stories gar keine Abhängigkeiten haben. In diesem Fall lassen sie sich unabhängig voneinander diskutieren, bewerten und implementieren. In unserem Beispiel sollen dies zwei Stories mit einer Komplexität von jeweils fünf und acht Story Point sein.

Einfache Abhängigkeiten zwischen User Stories

Diese User Stories könnten natürlich auch eine einfache Abhängigkeit voneinander haben. In diesem Fall ist es notwendig die User Stories in einer bestimmten Reihenfolge zu implementieren. Die Abhängigkeit wird bei der Planung des Teams also entsprechend zu berücksichtigen sein. In unserem Beispiel muss die Story mit fünf Punkten vor der Story mit 8 Punkten implementiert werden.

Sich Überlappende User Stories

Jetzt wird es interessant. Es kann sein, dass sich die in zwei User Stories beschriebenen Funktionalitäten überlappen. In diesem Fall ist die Transparenz des Backlogs gefährdet. Während die beiden unabhängigen User Stories eine Komplexität von insgesamt 13 Punkten haben, kann bei überlappenden User Stories keine gesicherte Aussage über die Komplexität gemacht werden. Dies ist nicht gut und muss unbedingt durch Dekomposition und Refinement aufgelöst werden.

Split von User Stories

Der Teil welcher in beiden User Stories enthalten ist wird als eigene Anforderung formuliert und die Abhängigkeiten entsprechend sichtbar gemacht. In unserem Beispiel ergibt sich also eine Gesamtkomplexität von 10 Punkten für die dekomponierten und neu bewerteten User Stories.

In der Praxis ergibt sich dieser Fall allerdings deutlich seltener für echte User Stories als für technische Anforderungen. Es passiert deutlich häufiger, wenn Infrastruktur in tiefer liegenenden Schichten der Architektur geschaffen werden muss, beispielsweise in der Datenbankschicht. Diese neue Infrastruktur dient dann als Grundlage für die Umsetzung der eigentlichen User Stories.

Einführung von Technischen Stories

Schauen wir uns nun an wie man mit solchen technischen Anforderungen umgehen sollte. Als kundenerlebbares Feature lassen sie nicht formulieren. Aus diesem Grund sollten diese Anforderungen als technische Stories formuliert werden. Diese technischen Stories bilden dann die Anforderungen an die Technologie eines Produktes ab, welche den Kunden im Normalfall gar nicht interessiert. Als zusätzlicher Nutzen können auch technische Schulden in Form von technischen Stories erfasst und somit transparent gemacht werden.

Zu Formulierung einer technischen Story kann auf die äußere Form einer User Story zurückgegriffen werden. Die Aufgaben werden dann aus Sicht der entsprechenden Rolle des Entwicklers formuliert. Dies erleichtert es nicht nur die User Stories entsprechend zu verfeinern, sondern erhöht auch die Transparenz.

Als Entwicklerrolle möchte ich Refactoring / Datenbankanbindung / etc., weil Begründung.

Transparenz Erhöhen Durch Technische Stories

Ein entscheidender Pluspunkt der Nutzung von technischen Stories ist die erhöhte Transparenz in der Entwicklung. Gehen wir zunächst von einem Entwicklungsteam aus das lediglich klassische User Stories nutzt und alle Aufgaben auf diesen Anforderungstypen abbildet.

Das Diagram zeigt die Velocity des Teams über einen Zeitraum von sechs Sprints nach Beginn einer neuen Produktentwicklung. Die Velocity ist stabil und auf den ersten Blick erscheint das Team als sehr produktiv. Anhand dieses Diagramms lässt sich aber keine Aussage darüber treffen ob das Team tatsächlich Funktionalität und Mehrwert an den Kunden ausliefert. Da alle Aufgaben als User Stories erfasst wurden lässt sich nicht sagen wie hoch der Anteil der gelieferten Funktionalität an den insgesamt erledigten Aufgaben ist.

Unterscheiden wir die Stories in kundenerlebbare Features und technische Anforderungen ergibt sich ein deutlicheres Bild. Dann zeigt sich, dass das Team in den ersten beiden Sprints noch sehr viele technische Grundlagen schaffen musste. Ab Sprint drei jedoch stieg der Anteil der gelieferten User Stories jedoch immer weiter an. Auf diese Weise lässt sich sehr transparent darstellen an welcher Art von Aufgaben das Team tatsächlich arbeitet. Dies erleichtert es deutlich den Zustand des Produktes zu inspizieren und in zukünftigen Planungsrunden Anpassungen an der Entwicklung vorzunehmen.

Technische Schulden Verfolgen Durch Technische Stories

Am beeindruckendsten zeigt sich der Mehrwert der erhöhten Transparenz im hinblick auf technische Schulden. Im unten stehenden Diagramm ist nun auch die Velocity des siebten bis neunten Sorints dargestellt. Wie wir sehen ist diese konstant. Das Team liefert auf den ersten Blick mit konstant hoher Geschwindigkeit neuen Mehrwert für den Kunden aus.

Auf den zweiten Blick zeigt die transparente Darstellung der technischen Stories, dass der Anteil an User Stories in der Umsetzung wieder zurückgeht. Dies kann auf einen Anstieg der technischen Schulden im Gesamtsystem zurückzuführen sein. Sollte dieser Anstieg nicht bewusst und geplant vorkommen, hilft die transparente Darstellung der technischen Velocity bei der Inspektion und Adaption. Ohne eine Trennung der technischen Anforderungen wäre dies deutlich schwieriger.

Abschließende Gedanken

Zusammenfassend sind technische Stories eine sehr gute Möglichkeit Anforderungen zu erfassen welche sich nicht direkt auf einen Kundennutzen beziehen. Dies erhöht die Transparenz des Produktbacklogs, da klar unterschieden werden kann zwischen funktionalen Anforderungen und technischen Anforderungen, bzw. technischer Schuld. Da technische Schulden immer klein gehalten werden sollten kann somit auch eine qualifizierte Aussage zur Höhe der bekannten technischen Schulden gemacht werden. Ebenso kann der Abbau dieser Schulden aktiv verfolgt und eingeplant werden.