Skip to content

Best Practices – Product Backlog

Diese Anleitung unterstützt Product Owner dabei, ein verständliches, gepflegtes und wertorientiertes Product Backlog zu führen.

Ziel eines guten Backlogs

Ein gutes Backlog ist:

  • Transparent: Inhalt und Reihenfolge sind für alle nachvollziehbar.
  • Aktuell: Es wird regelmäßig gepflegt und bereinigt.
  • Feingranular oben, grob unten: Oben liegen klar beschriebene Items, weiter unten grobere Ideen.
  • Wertorientiert: Die Reihenfolge spiegelt Kundennutzen und Geschäftswert wider.
  • Schätzbar: Das Team kann Aufwand und Komplexität in etwa einschätzen.

User Stories formulieren

Ziel: Anforderungen aus Sicht der Nutzer beschreiben.

  • Empfohlenes Format:
    „Als [Rolle] möchte ich [Ziel/Wunsch], um [Nutzen/Zweck] zu erreichen.“
  • Jede Story liefert erkennbaren Mehrwert.
  • Akzeptanzkriterien ergänzen, um Klarheit und Testbarkeit zu sichern.
  • INVEST-Prinzip beachten (Independent, Negotiable, Valuable, Estimable, Small, Testable).

Beispiel:

Als Kunde möchte ich meine Buchung stornieren können, um flexibel reagieren zu können.

User Stories aufteilen (Splitting)

Ziel: Große Stories (Epics) in handhabbare Einheiten zerteilen.

Mögliche Splitting-Strategien:

  • Entlang des Nutzungsvorgangs (z. B. Anzeigen → Auswählen → Bezahlen).
  • Nach Daten-/Rollenvarianten (z. B. verschiedene Benutzerrollen).
  • Technisch schrittweise (z. B. zuerst Backend-Funktion, dann UI).

Daumenregel: Eine Story sollte in wenigen Tagen (z. B. 1–3 Tage) umsetzbar sein.

Schätzen

Ziel: Gemeinsames Verständnis von Aufwand und Komplexität.

  • Planning Poker mit Story Points verwenden.
  • Fokus auf Komplexität, nicht auf exakte Zeit.
  • Eine Referenzstory festlegen, die als Vergleich dient.
  • Große Unterschiede in Schätzungen besprechen.

Schätzungen sind immer eine Teamaufgabe – nicht Aufgabe des Product Owners.

Priorisieren

Ziel: Sicherstellen, dass das Team an den wertvollsten Themen arbeitet.

Methoden:

  • MoSCoW: Must / Should / Could / Won’t
  • WSJF: Weighted Shortest Job First
  • Value vs. Effort: Nutzen gegen Aufwand abwägen
  • Kano-Modell: Basisfaktoren, Leistungsmerkmale, Begeisterungsmerkmale

Einflüsse:

  • Geschäftswert und Kundennutzen
  • Risiken / Unsicherheit
  • Abhängigkeiten
  • Kundenfeedback & Marktveränderungen

Priorisierung ist ein kontinuierlicher Prozess – nicht nur kurz vor dem Sprint Planning.

Optional: Backlog Refinement

  • Wöchentliches Treffen (ca. 10 % der Sprintzeit).
  • Teilnehmende: PO, Entwicklungsteam, bei Bedarf Scrum Master.

Ziele:

  • Stories prüfen, überarbeiten, verfeinern.
  • Schätzungen ergänzen oder aktualisieren.
  • Prioritäten klären.

Definition of Ready (DoR)

Eine Story ist „bereit für den Sprint“, wenn typischerweise:

  • Beschreibung verständlich ist.
  • Akzeptanzkriterien vorhanden sind.
  • Abhängigkeiten bekannt und geklärt sind.
  • Eine Schätzung vorliegt.

Zusammenfassung

Ein wirkungsvolles Product Backlog entsteht durch:

  • klare User Stories,
  • regelmäßiges Refinement,
  • transparente Priorisierung und
  • kontinuierliche Pflege.

So schafft der Product Owner den Rahmen, in dem das Team den maximalen Wert liefern kann.