Produkt
Vehikel zur Wertlieferung mit klarer Grenze und definierten Nutzern.
Der Scrum Guide beschreibt ein Produkt als Vehikel zur Wertlieferung mit einer klaren Grenze, bekannten Stakeholdern sowie definierten Nutzern oder Kunden. Ein zu eng geschnittenes Produkt, etwa eine einzelne technische Komponente, macht Steuerung nach Wert praktisch unmöglich, weil Wert erst am Ende der Kette entsteht.
Passende Übungsfragen
❌Der Product Owner, weil er das Increment abnimmt
❌Ausschließlich eine dedizierte QA-Abteilung
❌Der Scrum Master
✅Das gesamte Scrum Team, wobei die Developers die Einhaltung der Definition of Done sicherstellen
Qualität ist Teamsache. Die Developers verpflichten sich der Definition of Done; eine externe Abnahmeinstanz ist in Scrum nicht vorgesehen.
✍️ 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.
✅Sie müssen eine gemeinsame Definition of Done haben, damit ein integriertes Increment entstehen kann
❌Die DoD wird pro Sprint neu ausgehandelt
❌Jedes Team definiert seine eigene, unabhängige DoD
❌Der Product Owner legt für jedes Team eine eigene DoD fest
Ohne gemeinsame DoD lässt sich die Arbeit mehrerer Teams nicht zu einem einheitlich fertigen Increment integrieren.
☝️ SingleMehrere Scrum Teams arbeiten am selben Produkt. Was gilt für Product Backlog und Product Owner?
✅Ein Produkt hat ein Product Backlog, ein Product Goal und einen Product Owner
❌Jedes Team führt ein eigenes Product Backlog mit eigenem Product Owner
❌Jedes Team hat ein eigenes Product Goal
❌Das Backlog wird pro Team kopiert und synchronisiert
Auch bei mehreren Teams bleibt es bei einem Product Backlog, einem Product Goal und einem Product Owner. Jedes Team hat aber ein eigenes Sprint-Ziel und Sprint Backlog.
❌Sie werden außerhalb des Backlogs in einem separaten Fehlerprozess bearbeitet
✅Sie werden als Product-Backlog-Einträge geführt und vom Product Owner eingeordnet
❌Sie werden gesammelt und im Hardening Sprint behoben
❌Sie werden immer sofort und unabhängig vom Sprint-Ziel behoben
Alles, was am Produkt zu tun ist, läuft über das Product Backlog – das ist die einzige Quelle der Arbeit. Dringlichkeit bildet der PO über die Reihenfolge ab.