Technical Story

Technical Story – ein Hilfsmittel zur Beseitigung technischer Schulden

Eine User Story ist eine kurze Beschreibung einer Funktionalität eines Systems aus Sicht eines Anwenders. Sie beschreibt, wer was mit welcher Intention von einem System möchte und stellt den Anwender in den Fokus. Doch was passiert, wenn ein Entwickler im Zuge eines Sprints ein Problem oder eine Optimierungsmöglichkeit bei einer bereits realisierten Lösung identifiziert? Hier bietet sich die Verwendung von sogenannten Technical Storys an. Mit ihnen lassen sich

• technische Schulden dokumentieren,
• User Storys technisch verfeinern,
• nicht-funktionale Anforderungen (bspw. mit Kriterien wie Performance und Verfügbarkeit, Skalierung oder Sicherheit) beschreiben.

Gehören technische Storys ins Backlog?

Wenn eine Technical Story in Scrum zur Dokumentation von technischen Schulden, zur Verfeinerung von User Storys oder für die Arbeit mit nicht-funktionalen Anforderungen verwendet wird, gehört sie dann ins Backlog? Die Meinungen darüber variieren.

Einerseits beschreiben technische Storys keinen direkten Nutzen eines Anwenders und das ist der wesentliche Unterschied zu User Storys. Der Nutzen des Anwenders ist für das Sprint-Planning und die Priorisierung von User Storys wichtig. Ergo: Die Technical Story gehört nicht ins Backlog. Andererseits werden in Backlogs oftmals nicht nur User Storys, sondern auch Epics, Features, Use Case Slices, Spike Storys etc. verwaltet. Sämtliche Backlog Items – der Scrum Guide spricht von Backlog Items und nicht von User Storys – werden priorisiert und in Sprints adressiert. Ergo: Die Technical Story – die manchmal auch als technische User Story bezeichnet wird – gehört ins Backlog. Da im Entwicklungsverlauf typischerweise technische Schulden zunehmen, ist es in vielen Organisationen üblich, in jedem Sprint etwas Zeit für die Beseitigung dieser Schulden einzuplanen. Auch das wäre ein Argument für die Verwaltung im Backlog.

So oder so: Im Gegensatz zu User Storys nehmen technische Storys eine Systemperspektive ein. Zusätzlich zur Dokumentation empfiehlt sich daher auch die Visualisierung in Form von User Story Maps.

Impuls zum Diskutieren:

Sollten technische Storys vermieden werden, da sie schwierig zu priorisieren sind und sich der Business Value nur schwer bestimmen lässt?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

Der Scrum Guide erwähnt weder Technical Storys, User Storys, Epics, Features, Use Case Slices, Spike Storys etc. Nichtsdestotrotz werden viele diese Elemente in Organisationen sehr aktiv genutzt.

Eine Empfehlung zum Umgang mit technischen Storys finden Sie im Beitrag: Boost your Backlog.

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt: