t2informatik » Wissen kompakt » Technical Story

Technical Story

Technische Aspekte im Sprint dokumentieren

Eine User Story in Scrum 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 wird kein Nutzen eines Anwenders beschrieben 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. Es empfiehlt sich dennoch, Technical Storys im Product Backlog zu verwalten, ähnlich wie Epics, Features oder Use Case Slices. Dies führt dazu, dass sie auch in einem Sprint adressiert und realisiert werden können; hier wird häufig von der Beseitigung technischer Schulden gesprochen. Im Entwicklungsverlauf nehmen technischen Schulden typischerweise zu, so dass es in vielen Organisationen üblich ist, in jedem Sprint etwas Zeit für die Beseitigung dieser Schulden einzuplanen.

Technical Storys können neben der Dokumentation von technischen Schulden auch zur technischen Verfeinerung von User Storys oder für die Arbeit mit nicht-funktionalen Anforderungen (für die Beschreibung von Kriterien wie Performance und Verfügbarkeit, Skalierung oder Sicherheit) genutzt werden. Im Gegensatz zur User Storys nehmen sie eher eine Systemperspektive ein. Zusätzlich zur Dokumentation im Product Backlog empfiehlt sich auch die Visualisierung in Form von User Story Maps.

„Das ist mal ein Newsletter, der mich wirklich weiterbringt und auf den ich mich jede Woche freue.“

Wöchentliche Tipps, Meinungen und Informationen gibt es im t2informatik Blog – regelmäßig mit renommierten Gastautoren.

Share This