User Storys sinnvoll schneiden – eine Kurzanleitung

Diese Anforderungen werden im Format einer User Story in das Backlog des Teams aufgenommen und dort anhand der INVEST-Kriterien detailliert. Damit wird beispielsweise sichergestellt, dass die gewünschten Funktionalitäten einen Mehrwert schaffen (Valuable in INVEST) oder dass die Anforderungen unabhängig von anderen Funktionalitäten entwickelt werden können (Independent in INVEST). Die Anforderungen in kleine, sinnvolle Portionen aufzuteilen, stellt jedoch meist eine besondere Schwierigkeit dar (Small in INVEST). Stakeholder:innen wünschen sich bekanntlich umfangreiche Funktionalitäten einer Software, die dann auch schnell sehr komplex sind.

Unsere Übersicht zeigt Dir verschiedene Ansatzpunkte auf, den Umfang in mehrere Teile zu zerlegen. Beispielsweise könnte die User Story mehrere „Eingangskanäle“ umfassen, sodass eine Zerlegung pro Kanal denkbar wäre. Andere User Storys sehen womöglich diverse Operationen wie Erstellen, Löschen und Ändern eines Datenobjektes vor. Hier könnte die Aufteilung der Operationen sinnvoll sein.

Doch warum ist es überhaupt lohnenswert, eine User Story in einer kleinen Größe zu bearbeiten? Kleinere Anforderungen haben den Vorteil, dass sie in kürzeren Iterationen umgesetzt werden können und das Team damit schneller Feedback der Stakeholder:innen erhält. Außerdem lassen sich mehrere kleine User Storys flexibel über mehrere Sprints und Teammitglieder verteilen.