Braucht ein Team ein Sprint-Ziel in Scrum? / Sudo Null IT-Nachrichten

Das funktionsübergreifende, selbstverwaltete Scrum-Team wartet darauf, vom Inkrementhimmel zu fallen.Das funktionsübergreifende, selbstverwaltete Scrum-Team wartet darauf, vom Inkrementhimmel zu fallen.

Erinnern Sie sich, was der offizielle Scrum-Leitfaden über das Sprint-Ziel sagt:

Das Sprintziel ist das einzige Ziel im Sprint. Während sich Entwickler dem Sprint-Ziel verpflichtet fühlen, bietet es Flexibilität in Bezug auf die Auswahl der spezifischen Arbeit, die erforderlich ist, um es zu erreichen. Das Sprint-Ziel sorgt auch für Kohärenz und Fokussierung, indem es das Scrum-Team ermutigt, zusammenzuarbeiten, anstatt an getrennten Initiativen zu arbeiten.

Das Sprint-Ziel wird während der Sprint-Planung erstellt und dann dem Sprint-Backlog hinzugefügt. Entwickler behalten das Sprint-Ziel im Auge, wenn sie an Sprint-Problemen arbeiten. Wenn die Leistung nicht den Erwartungen entspricht, arbeiten sie mit dem Product Owner zusammen, um den Inhalt des Sprint-Backlogs innerhalb des Sprints zu überarbeiten, ohne das Sprint-Ziel zu ändern….

Während der Sprint-Planung… definiert das gesamte Scrum-Team gemeinsam das Sprint-Ziel, was erklärt, warum Sprint für die Stakeholder wertvoll ist. Das Sprintziel muss vor dem Ende des Sprint Plannings formuliert werden.

Die Verwendung des Sprint-Ziels hat mehrere Vorteile:

  • eine klare Fokussierung des Teams bei der Arbeit an der Zielerreichung

  • Kriterium für Änderungen an der Arbeit (ob sie zum Erreichen des Ziels beitragen oder im Gegenteil stören)

  • Motivationsfaktor bei der Arbeit, der ua gegenseitige Hilfe und Teamarbeit fördert

  • Transparenz der Teamarbeit für Stakeholder (Stakeholder)

  • Kriterium zur Bestimmung der Effektivität der Arbeit an der Überprüfung der Sprint- und Retro-Session

Aber das Setzen eines Sprintziels kann für ein Team eine ziemliche Herausforderung sein, und viele Teams haben damit zu kämpfen. Aber das ist ein regelmäßiger Prozess, das muss jedes Sprint Planning machen (im Durchschnitt plus oder minus einmal alle zwei Wochen). Wenn das Team selbst den Nutzen dieses Artefakts nicht sieht und die Formulierung des Ziels als Zeitverschwendung betrachtet, wird es es höchstwahrscheinlich nicht tun. Dadurch wird nach mehreren Initialzündungen im Projekt (erfahrungsgemäß dauert die Anfangssicherung 1-2 Monate bis sechs Monate) oder jedem mit dem Argument eingehämmert: „Wir können eine solche Verpflichtung nicht eingehen, all diese strengen Ziele und Fristen sind nicht agil“, “Für unser Team funktioniert das nicht.“, “Der Kunde kümmert sich nicht um diese Zwecke, daher gibt es keine Zeit damit zu verschwenden“etc. Oder das Ziel wird vom Product Owner / Manager per Auftrag festgelegt (in Teams, die an “Handsteuerung” arbeiten).
Manchmal wird ein Sprintziel zu einem Mehrfachziel, wenn das Team nicht bestimmen kann, was für den Kunden wichtig ist, welchen Nutzen ihm diese Steigerung bringt, und mehrere Punkte in das Sprintziel einbezieht. Ganz zu schweigen vom Level-80-Ziel: „Schließen Sie all diese verdammten Aufgaben für diesen Sprint ab!

Das Fehlen eines klaren Ziels für den Sprint kann dazu führen, dass das Team den Fokus verliert, was während des Sprints wichtig ist, jeder wird die Aufgaben erledigen, die jetzt Priorität zu haben scheinen (“wer sich mit Bugfixing beschäftigt, wer hinter technischer Schuld steckt“). Infolgedessen zahlen sich die Teammitglieder bei der Sprint-Review und Retrospektive mit bedeutungslosen Sätzen aus “alles scheint normal zu sein, alles ist wie gewohnt, es gibt keine Kommentare”, anstatt den Fortschritt beim Erreichen des Sprintziels zu diskutieren Die vorgeschlagenen Verbesserungen, die idealerweise auf den Ergebnissen der Retro-Sessions basieren sollten, wurden dem Backlog hinzugefügt, erübrigt sich zu sagen.

Ich habe solche Projekte und Teams in der Praxis kennengelernt, das Ergebnis ist fast immer vorhersehbar – Defokussierung des Teams, schneller Motivationsverlust bei den Entwicklern, fehlende Verbesserungen in der Arbeit, ständiges Verschieben von unerledigten Aufgaben in den nächsten Sprint, Auslieferung eines jeden neuen Releases 2-3-4 Monate. Und jetzt hat man statt Scrum nur noch einen im Wesentlichen leeren Cargo-Kult, und das Management sucht Ersatz für einen neuen Manager oder Scrum Master, denn das „brach zusammen“…

Anstatt dem Team zu sagen, dass es sein Bestes tun soll, um ein gutes Sprint-Ziel zu formulieren, können Sie sich ansehen, welche Hindernisse es bei der Formulierung eines relevanten Sprint-Ziels gibt. Das Team befürchtet negative Konsequenzen, wenn das Ziel nicht erreicht wird. Zu kurze Sprints. Dem Product Owner fehlt es an Autorität. Zu viele externe Abhängigkeiten. Die Tendenz der Geschäftsleitung oder der Kunden, Aufgaben mit “dringender Priorität und hoher Priorität” zu notieren.

Vergessen Sie nicht, sich ein Ziel für den bevorstehenden Sprint zu setzen, es kann ein sehr nützliches Werkzeug sein, wenn es richtig eingesetzt wird. Denken Sie daran, wo der offizielle Scrum-Leitfaden beginnt:

Jedes Element des Frameworks dient einem bestimmten Zweck, der notwendig ist, um den Gesamtwert und die Ergebnisse aus der Verwendung von Scrum zu erreichen. Das Ändern der Kernideen oder der Struktur von Scrum, das Auslassen von Elementen oder das Nichtbefolgen der Scrum-Regeln neigt dazu, Probleme zu verbergen, die Vorteile von Scrum einzuschränken und es möglicherweise sogar unbrauchbar zu machen.

Versuchen Sie nicht, Menschen zu überzeugen oder zu zwingen, ein Ziel zu formulieren – achten Sie vielmehr darauf, Hindernisse dafür zu identifizieren und zu beseitigen.

Similar Posts

Leave a Reply

Your email address will not be published.