Das Product Backlog Priorisieren statt alles gleichzeitig wollen

Das Product Backlog ist die eine Liste, auf die sich alle einigen: Was soll das Produkt können? Was ist am wichtigsten? Was kommt als Nächstes? Der Product Owner hält diese Liste aktuell, sortiert sie nach Wert und macht sie für das Team verständlich. Ohne Product Backlog kein Scrum — so einfach ist das.

Product Backlog auf einen Blick

Was?
Priorisierte Liste aller Produktanforderungen
Wer pflegt?
Der Product Owner (mit Input vom Team)
Format
Meist als User Stories formuliert
Regel
Immer nur ein Product Backlog pro Produkt
▲ Höchste Priorität User Story: Login-Funktion 8 SP User Story: Profil bearbeiten 5 SP User Story: Passwort zurücksetzen 3 SP Technische Schuld: API-Refactoring Idee: Dark Mode (noch nicht verfeinert) ▼ Niedrige Priorität
Ein Product Backlog: Oben das Wichtigste, unten die Ideen für später

Wie ist ein Product Backlog aufgebaut?

Das Product Backlog ist keine To-do-Liste — es ist eine priorisierte, lebendige Sammlung aller Anforderungen, Wünsche und Ideen für ein Produkt. Ganz oben stehen die wichtigsten und am besten verstandenen Einträge, ganz unten die vagen Ideen für irgendwann.

Typische Einträge sind:

  • User Stories: Anforderungen aus Nutzersicht („Als Nutzer möchte ich mich einloggen können, damit ich auf mein Profil zugreifen kann")
  • Bugs: Bekannte Fehler, die behoben werden müssen
  • Technische Aufgaben: Refactoring, Performance-Optimierung, Infrastruktur
  • Spikes: Forschungsaufgaben, wenn unklar ist, wie etwas umgesetzt werden kann

Wichtig: Es gibt immer nur ein Product Backlog pro Produkt — auch wenn mehrere Teams daran arbeiten. Der Product Owner ist die einzige Person, die es priorisiert.

Was passiert im Backlog Refinement?

Das Backlog Refinement (früher „Grooming") ist ein regelmäßiger Termin — meist ein- bis zweimal pro Woche — bei dem das Team das Backlog gemeinsam durchgeht. Dabei passiert:

  1. Verfeinern: Grobe Einträge werden in konkrete, umsetzbare User Stories zerlegt
  2. Schätzen: Das Team bewertet den Aufwand (z.B. mit Planning Poker)
  3. Priorisieren: Der Product Owner passt die Reihenfolge an aktuelle Erkenntnisse an
  4. Streichen: Einträge, die nicht mehr relevant sind, fliegen raus

Faustregel: Die oberen 2-3 Sprints im Backlog sollten immer gut genug verfeinert sein, dass das Team sie direkt ins Sprint Planning übernehmen kann.

Wie priorisiert der Product Owner?

Priorisierung ist Kunst und Wissenschaft zugleich. Bewährte Kriterien:

  • Geschäftswert: Was bringt dem Nutzer oder dem Unternehmen am meisten?
  • Risiko: Gibt es technische Unbekannte? Dann früh angehen, nicht aufschieben.
  • Abhängigkeiten: Manche Features müssen zuerst gebaut werden, damit andere darauf aufbauen können.
  • Aufwand vs. Wirkung: Kleine Änderungen mit großer Wirkung wandern nach oben (Low-Hanging Fruit).

Methoden wie MoSCoW (Must, Should, Could, Won't) oder WSJF (Weighted Shortest Job First) helfen, die Priorisierung zu strukturieren — statt nach Bauchgefühl oder nach dem, wer am lautesten ruft.