PP
Scrum-Kurs · Kapitel 3 von 4

Artefakte & Schätzen

Die drei Dinge, die Scrum erzeugt, die drei Commitments, die ihnen Bedeutung geben — und warum Planen im Kern strukturiertes Schätzen ist.

Die drei Artefakte

Jedes Artefakt repräsentiert Arbeit oder Wert und ist mit einem Commitment verbunden, das den Informationsgehalt maximiert.

Product Backlog

Commitment: Product Goal

Eine emergente, geordnete Liste von allem, was im Produkt benötigt werden könnte. Sie ist nie vollständig — sie entwickelt sich mit Produkt und Umfeld weiter. Einträge weiter oben sind klarer und besser ausgearbeitet; der Product Owner ordnet die Liste nach Wert.

Sprint Backlog

Commitment: Sprint Goal

Das Sprint-Ziel, die für den Sprint ausgewählten Product Backlog Items und ein Plan zu deren Umsetzung. Es ist ein Echtzeitbild der Arbeit, die das Developer Team plant — und wird während des Sprints laufend aktualisiert.

Increment

Commitment: Definition of Done

Ein konkreter Schritt in Richtung Product Goal. Jedes Increment ist additiv und muss mit vorherigen Increments funktionieren. Um wertvoll zu sein, muss es die Definition of Done erfüllen — innerhalb eines Sprints können mehrere Increments entstehen.

Die drei Commitments

Sie geben den Artefakten oben einen Zweck und verankern Empirie in etwas Konkretem.

Product Goal

Das langfristige Ziel des Scrum Teams. Es beschreibt einen zukünftigen Zustand des Produkts, der als Zielpunkt dienen kann — und erreicht (oder aufgegeben) werden muss, bevor das nächste Ziel verfolgt wird.

Sprint Goal

Das einzige Ziel des Sprints. Es gibt den Developern Flexibilität, wie genau sie es erreichen, schafft aber gleichzeitig Kohärenz und Fokus.

Definition of Done

Eine formale Beschreibung des Qualitätszustands, den ein Increment erreichen muss, um 'Done' zu sein — z. B. Unit-Tests bestanden, Code reviewed, Akzeptanzkriterien erfüllt. Erfüllt ein Arbeitsergebnis dies nicht, kann es nicht released oder im Sprint Review präsentiert werden.

"Planen ist Schätzen"

Jeder Plan ist eine Prognose auf Basis dessen, was ihr gerade wisst — und das ist immer unvollständig. Ihr könnt den Umfang fixieren, das Datum fixieren, oder keines von beidem — aber ihr könnt nicht Umfang und Datum fixieren und das Ergebnis dann eine Garantie nennen. Sobald man akzeptiert, dass Planen bedeutet, unter Unsicherheit zu schätzen, ändert sich die Frage von "Wie sagen wir perfekt vorher?" zu "Wie bekommen wir schneller bessere Informationen?"

Release-Burnup-Chart

Statt einer einzigen Schätzung im Voraus verfolgen Scrum-Teams die abgeschlossene Arbeit Sprint für Sprint. Der Gesamtumfang wird gegen die kumulierten erledigten Punkte aufgetragen, und es entsteht ein Trend — der zeigt, wann das Team einen bestimmten Umfang bei aktueller Velocity voraussichtlich erreicht. Die Prognose wird mit jedem Sprint genauer, weil sie auf echten Daten basiert statt auf einer Schätzung vom ersten Tag.

Lust auf den tiefen Einblick in relatives Schätzen, Effort Points und warum Teams Fibonacci-Zahlen nutzen?

Artikel lesen: Agile Schätzung mit Fibonacci-Zahlen