Product Backlog
Geordnete Liste alles Notwendigen für das Produkt.
Der Product Backlog ist eine emergente, geordnete Liste von allem, was für das Produkt benötigt wird. Er wird vom Product Owner verwaltet. Commitment des Product Backlogs ist das Product Goal.
Passende Übungsfragen
❌Den nächsten Sprint detailliert planen
✅Das Increment inspizieren und das Product Backlog gemeinsam mit Stakeholdern anpassen
❌Die Developers bewerten
❌Die Zusammenarbeit im Team verbessern
Im Sprint Review inspizieren Scrum-Team und Stakeholder das Increment und passen das Product Backlog an. Die Team-Verbesserung ist Thema der Retrospektive.
❌Epics, Stories, Tasks
✅Product Backlog (Product Goal), Sprint Backlog (Sprint Goal), Increment (Definition of Done)
❌Backlog, Board, Burndown
❌Vision, Roadmap, Release-Plan
Die drei Artefakte mit ihren Commitments: Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done.
❌Die Developers
❌Der Kunde direkt
✅Der Product Owner
❌Der Scrum Master
Der Product Owner verantwortet das Product Backlog: Inhalt, Verfügbarkeit und Reihenfolge. Andere können beitragen, aber die Verantwortung liegt allein beim PO.
☝️ SingleEin Manager möchte den Developers direkt Aufgaben zuweisen. Was ist die scrum-konforme Reaktion?
❌Die Zuweisung akzeptieren, da Manager weisungsbefugt sind
✅Transparent machen, dass Arbeitszuweisung die Selbstverwaltung untergräbt, und den Bedarf über den Product Owner ins Backlog führen
❌Den Sprint abbrechen
❌Den Manager aus allen Scrum-Events ausschließen
Bedürfnisse von außen sind legitim – sie gehören aber über den Product Owner ins Product Backlog, nicht als Direktauftrag an einzelne Developers.
✍️ OffenEin Scrum Team ist auf 14 Personen angewachsen. Die Daily Scrums dauern 30 Minuten, Entscheidungen ziehen sich hin. Beschreiben Sie das Problem und mögliche Vorgehensweisen.
Musterantwort: Das Team liegt deutlich über der Orientierung von typischerweise 10 oder weniger Personen. Große Teams erzeugen überproportional viele Kommunikationswege, was Abstimmungsaufwand, Entscheidungsdauer und Event-Länge erhöht und die Kohäsion senkt. Mögliches Vorgehen: das Team selbst die Aufteilung erarbeiten lassen (Selbstverwaltung) – etwa entlang von Produktbereichen, Wertströmen oder Nutzergruppen, nicht entlang von Fachdisziplinen, damit jedes entstehende Team cross-funktional bleibt und eigenständig ein Increment liefern kann. Wichtig: bei einem gemeinsamen Produkt bleibt es bei EINEM Product Backlog und EINEM Product Owner; jedes Team braucht eine gemeinsame Definition of Done und ein integriertes Increment. Alternativ prüfen, ob das Team nur temporär gewachsen ist. Ein Skalierungsrahmenwerk (z.B. Nexus) ist erst sinnvoll, wenn mehrere Teams dauerhaft am selben Produkt arbeiten.
Bewertet werden: Bezug zur Größenorientierung (10 oder weniger) + Kommunikationsaufwand als Ursache + Aufteilung durch das Team selbst + Schnitt nach Wert statt nach Fachdisziplin + gemeinsames Product Backlog/PO/DoD bei einem Produkt.