Was ist neu im Scrum Guide 2020?

Scrum Guide

In den frühen 1990er Jahren haben Jeff Sutherland und Ken Schwaber Scrum entwickelt. Im Jahr 2010 wurde erstmalig der Scrum Guide veröffentlicht, um das Verständnis des agilen Projektmanagement Frameworks für alle transparent einsehbar zu machen. Im Laufe der Zeit hat sich die Methodik verändert und auch der Scrum Guide wurde aktualisiert.

Dies geschah das letzte Mal im Jahr 2017 und jüngst erschien die neueste Version im November 2020. (Eine Übersicht der Veränderungen von der 2017 zu der aktuellen 2020 Version ist hier zu finden.)

In diesem Artikel möchte ich die größten Veränderungen des Scrum Guides erläutern. Hierbei gehe ich nicht auf die grundsätzliche Bedeutung der angesprochenen Begriffe ein, dies wird in anderen Artikeln behandelt.

Autor/in
Alexander Yzer
Product Owner Mehr erfahren
Alexander Yzer
Alexander Yzer hat 15 Jahre Erfahrung im Projektmanagement und in der IT-Beratung. Bei IT-P ist er seit 2019 als Product Owner im Competence Center Project Management tätig. Dort befasst er sich vor allem mit der Analyse und Verbesserung von Prozessen sowie dem Anforderungsmanagement und der Durchführung agiler Projekte. Privat beschäftigt er sich momentan intensiv mit Automatisierungs-Lösungen für das Smart Home. ... mehr vom Experten

Allgemeines

Insgesamt ging es auch darum, den Scrum Guide wieder etwas übersichtlicher und weniger starr zu gestalten. Es wurde sich wieder mehr darauf fokussiert, einen minimalistischen Rahmen eines Frameworks zu geben und keine harten Vorgaben zu machen. Dies spiegelt sich sowohl im Sprachbild als auch im um fünf Seiten gekürzten Umfang wider.

 

Produktziel

Bisher wird ein Sprintziel definiert, welches es pro Sprint zu erreichen gilt und auf das sich das Team committet. Im Scrum Guide 2020 wird dies ergänzt durch ein Produktziel, das sogenannte Product Goal, welches übergreifend über mehrere Sprints und Inkremente gilt.
Alle Elemente im Product Backlog zielen nun auf die Erfüllung dieses Produktziels hin. Das sorgt unter anderem dafür, dass man sich das Backlog nicht mit Stories füllt, die nicht im Fokus sind. Das Team committet sich nun auch auf das Produktziel als übergeordnetes Element.
Jedes Sprintziel bringt das Team dabei einen Schritt näher an das übergeordnete Produktziel.

Produktvision vs. Produktziel

Anders als das Produktziel ist die Produktvision als Leitbild, auf das hingearbeitet wird, nicht im Scrum Guide enthalten. Dennoch ist die Produktvision in vielen Projekten und Teams etabliert und elementarer Bestandteil.

Sowohl die Produktvision als auch das Produktziel sind sinnvoll und wichtig. Unabhängig von ihrer Erwähnung im Scrum Guide schließt das eine das andere nicht aus, denn eine Vision unterscheidet sich von einem Ziel. Die Produktvision bildet etwas Abstrakteres, ein fernes Ziel, auf das hingearbeitet wird, was aber so voraussichtlich nicht erreicht wird bzw. werden kann. Hierdurch ergibt sich die Richtung, die das Team verfolgt.

Das Produktziel hingegen ist konkreter und vor Allem erreichbar. Es ist zwar auch ein langfristiges Ziel, muss aber per Definition im Scrum Guide erreicht werden können, da (erst) nach Beendigung des einen Produktziels ein neues Ziel definiert werden kann.

Planning

Eine Neuerung bezieht sich auf das Planning. Bisher ging es im Planning um zwei Fragestellungen, nämlich „Was wollen wir im Sprint tun?“ und „Wie wollen wir es tun?“. Nun wurde eine Frage in Bezug auf das Sprint Planning ergänzt, und zwar „Was ist Mehrwert des Sprints in Bezug auf das Produktziel?“. Dadurch bekommt das Sprintziel eine höhere Wertigkeit und zahlt direkt auf das neue Produktziel ein.

 

Estimation

In meinem Blogartikel „Aufwandsschätzung im agilen Projektmanagement – Wir funktioniert das?“ bin ich ausführlich auf das relative Schätzen eingegangen.
Diese Schätzungen begleiten auch viele Scrum Teams im Sprint-Rhythmus und führen nicht selten zu langen Diskussionen und Umut. Vor Allem bieten sie dem Management aber immer wieder Ansatzpunkt für Diskussionen zur Leistungserbringung, Fertigstellung und Forecasts in Bezug auf Deadlines.
In diesem Zusammenhang wies ich im genannten Artikel bereits daraufhin, dass sich Schätzungen auch leicht zu WOMBATS (waste of money, budget and time) entwickeln können.

Um so besser ist es, dass der aktuelle Scrum Guide nicht mehr von Schätzungen spricht. Der Begriff estimations wurde vollständig aus dem Framework entfernt. Was aber geblieben ist, ist die „size“ (Größe) einer Story. Es geht also weiterhin darum, dass eine Story so klein geschnitten ist, dass sie in einem Sprint umgesetzt werden kann.

Durch den Wegfall der Schätzungen fokussiert sich Scrum noch weiter auf die Generierung von Outcome in Form eines Mehrwerts für den Kunden, der auf das Sprint- und Produktziel ausgerichtet ist. Die Zeit in einem Sprint kann nun noch sinnvoller für das Ziel genutzt werden, da Meetings wie das Estimation Meeting und zahlreiche Auswertungen, in denen relative Schätzzahlen zu absoluten Management-KPIs werden, entfallen.

 

Definition of Done

Die Definition of Done (DoD) definiert Kriterien, die zur vollständigen Erfüllung eines Inkrements maßgeblich sind. Diese Kriterien wurden nun in ihrer Wertigkeit gesteigert. Sie werden jetzt auch offiziell als Artefakt betitelt. Auch für die DoD ist nun ein explizites Commitment gefordert.

Commitments

Jedes Artefakt bekommt jetzt auch per Defintion sein eigenes Commitment, wodurch die Wertigkeit und Abhängigkeit der Artefakte verdeutlicht werden.

Team

Auch in Bezug auf das Team gab es zwei Anpassungen. Das Team besteht weiterhin aus dem Scrum Master, dem Product Owner und den Entwicklern, jedoch ist nicht mehr vom Entwicklungsteam die Rede, sondern von Entwicklern. Damit soll auch erreicht werden, dass es wieder EIN Scrum Team mit einem gemeinsamen Fokus gibt und sich nicht einzelne Gruppen separieren und sich ein Gegeneinander entwickelt. Scrum Master, Product Owner und Entwickler werden aber nicht mehr als Rollen bezeichnet. Die neue Bezeichnung lautet Accountabilities – also Verantwortlichkeiten. Dies verdeutlicht einmal mehr die Verantwortlichkeit, die das Scrum Team trägt.

Das Scrum Team wird jetzt nicht mehr nur als selbstorganisiertes Team bezeichnet, welches eigenständig entscheidet wer etwas macht und wie es gemacht wird, sondern gilt nun auch im Scrum Guide als selbstverwaltend, da es zusätzlich darüber entscheidet, was es tut und woran es arbeitet.

Zitat
Self-Managing over Self-Organizing

Zusammenfassung

Durch den insgesamt überarbeiteten Umfang fokussiert sich der Scrum Guide wieder mehr auf die Eckfeiler des Frameworks. Das Team bekommt einen noch höheren Stellenwert und es wird mehr Transparenz durch die klare Struktur der Artefakte und der zugehörigen Commitments geschaffen. Vor Allem das Abschaffen der Schätzungen ermöglicht einen noch besseren Fokus auf das, worum es eigentlich geht – die Herstellung eines Produkts, welches Mehrwert bietet.
Insgesamt zeigt die Überarbeitung – was viele Scrum Teams ohnehin bereits tun –, dass es wichtig ist, sich als Team kontinuierlich weiterzuentwickeln und Bestehendes immer wieder sinnvoll zu hinterfragen.

WHITEPAPER
So machen Sie Ihre Projektteams fit für die Zukunft