Sprint-Ziele bereiten deinem Scrum Team Probleme?
Dann bist du nicht allein. Ich habe jahrelang unterschiedliche Methoden ausprobiert, um Sprint-Ziele einzuführen. Manche haben funktioniert, andere nicht.
Diejenigen, die funktioniert haben, habe ich in vier bewährte Tipps verpackt und mit 100 anderen Scrum Mastern geteilt, die ebenfalls mit diesem Problem kämpfen. Hier findest du die Aufzeichnung davon in meinem Webcast bei Scrum.org:
Am Ende des Webcasts wurden mir von den Zuhörern viele Fragen zu Sprint-Zielen und rund um das Sprint Planning gestellt. Da ich nicht alle beantworten konnte, möchte ich dies jetzt nachholen. Besonders möchte ich auf 5 Irrtümer eingehen und dir zeigen, wie ich die Scrum Werte für mich nutze, um zu entscheiden, ob eine Aussage ein Irrtum ist.
Denn am Ende sollten wir Scrum Master nie vergessen:
Bei Scrum geht es mehr um Verhaltensweisen als um einen stringenten Prozess.
Oder wie es der Scrum Guide formuliert:
„Diese Werte geben dem Scrum Team die Richtung vor, was seine Arbeit, seine Handlungen und sein Verhalten betrifft.“
Lasst uns nun einige der Irrtümer betrachten und die Scrum Werte nutzen, um sie zu entlarven.
Los geht's:
Irrtum 1: Das Scrum Team kann mehrere Sprint-Ziele im Sprint verfolgen
Bei Sprint-Zielen handelt es sich um „Commitments“.
Der Scrum Guide beschreibt sie so:
„Jedes Artefakt beinhaltet ein Commitment, um sicherzustellen, dass Informationen bereitgestellt werden, welche Transparenz und Fokus verbessern, um den Fortschritt messbar zu machen.“
Das Commitment zum Sprint Backlog ist das Sprint-Ziel. Und wie wird der Fokus verbessert? Indem sich das Scrum Team auf ein oder auf mehrere Sprint-Ziele verpflichtet?
Du siehst meinen Punkt, oder? Nur ein einziges Ziel liefert den nötigen Fokus im Sprint. Und dieser Fokus ist nötig, um komplexe Probleme zu lösen.
Irrtum 2: Das Sprint-Ziel wird vom Product Owner vorgegeben
Scrum ist ein Teamsport.
Daher kommt auch der Name. Der Unterschied zwischen einem Team und einer Gruppe ist ein gemeinsames Ziel. Jeder im Team bringt sich mit seiner fachlichen Expertise ein, um ein gemeinsames Ziel für den Sprint zu definieren.
Deshalb beschreibt der Scrum Guide den Ablauf des Sprint Plannings so:
„Der Product Owner schlägt vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprint-Ziel zu definieren, das verdeutlicht, warum der Sprint für die Stakeholder wertvoll ist.“
Durch sein Verständnis für den Kunden, die Nutzer und die Marktsituation schlägt der Product Owner ein Ziel vor, welches den Wert des Produkts steigern könnte. Es braucht allerdings auch die technische Einschätzung der Entwickler, ob dieses Ziel realisierbar ist. Die Kombination aus technischer Umsetzbarkeit und Wertstiftung liefert ein Ziel, das wertvoll für das Unternehmen und die Stakeholder ist.
Mit dieser Zusammenarbeit lebt das Team den Scrum Wert „Respekt“. Die Teammitglieder respektieren sich gegenseitig als fähige und unabhängige Personen und zeigen, dass jede Perspektive im Team für den Erfolg wichtig ist. Und mehr noch:
Sie respektieren auch die Zeit und das Geld, welche die Stakeholder in das Team investieren.
Irrtum 3: Das Sprint-Ziel sollte ein „Stretch Goal“ sein
Stretch Goals stehen im Widerspruch zum Scrum Wert „Commitment“:
„Das Scrum Team verpflichtet sich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen.“
Bei der Entwicklung von Produkten läuft es selten wie geplant. Daher ist es unrealistisch, zu erwarten, dass ein Scrum Team in jedem Sprint sein Ziel erreicht. Aus meinen Erfahrungen tragen „Stretch Goals“ oder übermäßig ambitionierte Ziele weniger zur Motivation des Teams bei. Sie führen stattdessen dazu, dass die Qualität leidet. Außerdem werden technische Schulden leichtfertig in Kauf genommen.
Dadurch kann das „Commitment“ zum Produkt, festgehalten durch die „Definition of Done“, leiden.
Irrtum 4: Die Einträge im Product Backlog müssen vor dem Sprint Planning bereits die Umsetzung beschreiben
Jedes Artefakt soll den Fokus auf einen bestimmten Aspekt der Arbeit oder des Werts legen.
Das Product Backlog beschreibt das „Was“, also welche Aspekte am Produkt verbessert werden sollten. Wie diese Verbesserungen umgesetzt werden, definieren die Entwickler des Scrum Teams im Sprint Planning:
„Das Sprint Backlog besteht aus dem Sprint-Ziel (Wofür), den für den Sprint ausgewählten Product-Backlog-Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie).“
Aus meiner Sicht ist es nicht verboten, im Refinement der Product-Backlog-Einträge bereits Ideen zur Umsetzung zu diskutieren. Es sollte jedoch immer klar sein, dass der Fokus auf dem „Was“ liegt.
Da sich das Product Backlog ständig ändert, wird nicht jeder Eintrag umgesetzt. Zeit für die Überlegung, wie ein Eintrag umgesetzt werden soll, könnte dann verschwendet sein. Agilität zielt darauf ab, diese Art von Verschwendung zu vermeiden.
„Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.“
Wenn du mehr über das Refinement erfahren willst, dann wirf einen Blick auf diesen Artikel: „Eine Anleitung zum Product Backlog Refinement, die dir Antworten auf das Wer, Wann und Was liefert (damit Anforderungen verstanden werden)“
Zum Schluss noch ein Irrtum zum „Timeboxing“:
Irrtum 5: Dauert der Sprint eine Woche, muss das Sprint Planning 8 Stunden dauern
Das Sprint Planning sollte seinen Zweck erfüllen und dabei so kurz wie möglich sein.
Der Scrum Guide verdeutlicht dies mit dem Konzept des „Timeboxing“:
„Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event entsprechend kürzer.“
„Timeboxing“ ist eines der wichtigsten Konzepte in Scrum. Die zeitliche Begrenzung hilft dem Team, sich auf das Wesentliche zu fokussieren: die Planung dieses Sprints und die Definition eines Sprint-Ziels.
Gleichzeitig ermöglicht „Timeboxing“ empirisches Arbeiten. Sollte die Planung nicht innerhalb der vorgegebenen Zeit abgeschlossen sein, macht die Timebox dies transparent. Das Scrum Team kann die Abweichung spätestens in der Sprint Retrospektive überprüfen. Und dort können Verbesserungsmaßnahmen überlegt werden.
Transparenz, Überprüfung, Anpassung – die drei Säulen, die empirisches Handeln ausmachen.
Willst du noch tiefer in Scrum eintauchen?
Wenn einige der Irrtümer neu für dich waren, dann wirf unbedingt einen Blick auf die „Scrum im Selbststudium“-Reihe. Dort erkläre ich in 18 ausführlichen Artikeln die Grundlagen von Scrum Schritt für Schritt.
Behalte dabei im Hinterkopf:
Es geht nicht darum, Scrum als Prozess rigoros zu befolgen. Es geht darum, Scrum als Rahmenwerk zu nutzen. Mit dem Ziel, Verbesserungen in der Arbeitsweise unseres Teams zu identifizieren. Die Umsetzung der Verbesserungen sind dann erfolgreich, wenn sie die Scrum Werte im Team mehr zum Vorschein bringen.