Team-Backlog & Stories

In SAFe fließt Arbeit durch eine Hierarchie:

Epic → Feature → Story

• Epics sind große Initiativen, die sich über mehrere PIs erstrecken. Sie leben im Portfolio-Kanban und erfordern Lean Business Cases.
• Features sind Funktionsinkremente, die dem Nutzer Wert liefern. Sie leben im Programm-Backlog und sind so dimensioniert, dass sie in ein einzelnes PI passen. Product Management ist für die Feature-Priorisierung verantwortlich.
• Stories sind kleine, implementierbare Arbeitspakete, die ein Team innerhalb einer Iteration abschließen kann. Sie leben im Team-Backlog. Der Product Owner ist für die Story-Priorisierung verantwortlich.

Der Zerlegungsfluss: Product Management zerlegt Epics während des PI Planning in Features. Product Owner zerlegen Features während des Iteration Planning (und in Refinement-Sessions) in Stories.

Gute Stories folgen den INVEST-Kriterien:

• Independent (Unabhängig) — Können entwickelt werden, ohne von anderen Stories abzuhängen
• Negotiable (Verhandelbar) — Details werden diskutiert, nicht diktiert
• Valuable (Wertvoll) — Liefert klaren Wert für den Nutzer oder das System
• Estimable (Schätzbar) — Team kann den Aufwand schätzen
• Small (Klein) — Passt in eine einzelne Iteration
• Testable (Testbar) — Klare Akzeptanzkriterien

Nicht alle Arbeit liefert direkten Nutzerwert. Enabler sind Stories (oder Features oder Epics), die die technische Grundlage für zukünftige Fähigkeiten schaffen.

SAFe definiert vier Arten von Enablern:

Architektur-Enabler: Bauen architektonische Runway auf – gemeinsame Services, APIs, Infrastruktur, die zukünftige Features benötigen werden. Beispiel: Einrichtung eines Message-Queue-Systems, bevor ereignisgesteuerte Features entwickelt werden.

Infrastruktur-Enabler: Richten Entwicklungs-, Test- und Deployment-Infrastruktur ein. Beispiel: Erstellung einer CI/CD-Pipeline, Einrichtung von Monitoring, Bereitstellung von Umgebungen.

Explorations-Enabler: Untersuchen Optionen und reduzieren Unsicherheit. Beispiel: Prototyping zweier verschiedener Ansätze, um zu sehen, welcher besser funktioniert, Spike-Stories.

Compliance-Enabler: Erfüllen regulatorische oder Policy-Anforderungen. Beispiel: Implementierung von Audit-Logging, Datenverschlüsselung oder Barrierefreiheitsstandards.

Enabler im Backlog verwalten:

Enabler konkurrieren mit Feature-Stories um Kapazität. Ein gesundes Team verbringt ungefähr:

• 70-80% mit Feature-Stories (direkte Wertlieferung)
• 20-30% mit Enablern (architektonische Runway, technische Schulden, Infrastruktur)

Dieses Verhältnis ist nicht starr – es hängt von der Reife des Systems ab. Neue Produkte benötigen mehr Enabler-Arbeit; reife Produkte können sich stärker auf Features konzentrieren. Der Schlüssel liegt darin, Enabler-Arbeit sichtbar zu machen, anstatt sie zu verstecken.

Während des Iteration Planning bestimmen Teams, wie viel Arbeit sie zusagen können:

Kapazität = verfügbare Teammitglieder × Stunden pro Tag × Tage in der Iteration, abzüglich Meetings und bekannter Unterbrechungen. Teams lernen ihre tatsächliche Kapazität durch Erfahrung – es ist eine empirische Messung, keine Berechnung.

Story Points schätzen relative Komplexität. Teams kalibrieren sich im Laufe der Zeit. Die Schlüsselmetrik ist Velocity – die durchschnittlichen Story Points, die pro Iteration abgeschlossen werden. Velocity stabilisiert sich nach 3-4 Iterationen und wird zu einem verlässlichen Planungswerkzeug.

Commitment im SAFe-Kontext:

Team-Commitments in einer Iteration richten sich nach PI Objectives aus, die während des PI Planning festgelegt werden. Das Iterationsziel sollte sich auf den Fortschritt bei einem oder mehreren PI Objectives abbilden lassen. Dies schafft nachvollziehbare Ausrichtung von der Teamarbeit zum Programmwert.

Wenn Teams mitten in der Iteration feststellen, dass sie ein Commitment nicht einhalten können:

1. Sofort kommunizieren (Transparenz)
2. Mit dem PO zusammenarbeiten, um den Scope anzupassen (Verhandlung)
3. An den RTE eskalieren, wenn es andere Teams betrifft (Koordination)
4. Niemals Qualität opfern, um ein Datum zu erreichen (eingebaute Qualität)

Die Vorhersagbarkeitsmetrik: SAFe verfolgt, wie gut Teams ihre PI Objectives liefern. Es geht nicht darum, Verfehlungen zu bestrafen – es geht darum, die Schätzungs- und Planungsgenauigkeit im Laufe der Zeit zu verbessern. Ein Team, das zuverlässig 80% seiner Objectives liefert, ist wertvoller als eines, das 100% verspricht und unvorhersehbar liefert.