So schätzen Sie den Aufwand von Product Backlog Items in Scrum

In Scrum wird der Aufwand der auszuführenden Arbeit geschätzt, und zwar vor jedem Sprint. Der Scrum Guide schreibt dies zwar nicht explizit vor, ist aber Best-Practice. Warum Sie den Aufwand der Backlog Items schätzen sollten und wie Sie das Estimation Meeting durchführen, erfahren Sie in diesem Artikel. Sie erfahren aber auch, dass nicht nur die geschätzte Größe als Resultat einen Mehrwert dieser Aktivität bietet, sondern dass das Estimation Meeting noch einen anderen relevanten Nutzen hat. Lesen Sie weiter und lernen Sie mehr!

Warum Sie den Aufwand schätzen sollten

Sie werden überrascht sein, der Scrum Guide erwähnt das Thema Aufwand schätzen nicht. Das heißt aber nicht, dass Sie die Backlog Items für den geplanten Sprint nicht schätzen sollen.
Die meisten Scrum-Teams machen eine Aufwandschätzung, damit sie wissen, wie viel Arbeit sie in einen Sprint durchführen können, während andere Scrum-Teams nur ihre beste Schätzung basierend auf der empirischen Erfahrung der vorherigen Sprints verwenden – oder überhaupt nicht schätzen.

Ein Product Backlog ohne Schätzungen ist nicht transparent. Es gibt mindestens fünf Gründe, warum Schätzungen deshalb wichtig sind:

• um Abhängigkeiten zu koordinieren
• um Prioritäten zu bestimmen
• um die Option mit dem optimalen Value zu bestimmen
• um Lieferung vorherzusagen
• um ein gemeinsames Verständnis bilden

Oft genügt die einfachste Schätzmethode für diese fünf Bereiche, um die Dinge ziemlich transparent zu machen. Für mich ist ein zusätzlicher Wert der Schätzung die Diskussion zwischen den Teammitgliedern, wenn sie versuchen, sich auf eine Größe zu einigen. Die gründliche und manchmal auch heftige Debatte unter den Beteiligten, die die Arbeit tatsächlich ausführen werden, führt zu gemeinsamer Klarheit.

In diesem Kapitel zeige ich Ihnen, warum es sinnvoll ist auf zwei Ebenen zu schätzen, erkläre Ihnen das Estimation Meeting und zwei bekannte Schätzmethoden, die sich in der Praxis bewährt haben und das Schätzungen sehr effizient machen.

Aufwandschätzung auf zwei Ebenen

Bei Scrum machen Sie Aufwandschätzungen auf zwei Ebenen: Auf der Backlog-Item-Ebene und auf der Task-Ebene. Um dabei gute und zuverlässige Schätzungen zu erhalten, sollte immer das ganze Scrum-Team am Estimation Meeting anwesend sein. Wenn Aktivitäten geschätzt werden, ist der Product Owner nicht unbedingt notwendig.

1. Aufwandschätzung auf der Backlog-Item-Ebene

Vor dem Start des ersten Sprints sollten Sie möglichst viele Backlog Items geschätzt haben, damit Sie einen Releaseplan bzw. die Mittelfristplanung erstellen können. Je mehr Backlog Items Sie geschätzt haben, desto weiter in die Zukunft können Sie Releases planen.

Für diese Schätzung verwenden die meisten Scrum-Teams Story Points. Geschätzt wird im Estimation Meeting. Danach startet der erste Sprint mit dem Sprint Planning.

2. Aufwandschätzung auf der Aktivitäten-Ebene

Sobald im Sprint Planning die Aktivitäten (Tasks) für die Umsetzung jedes Backlog Items bestimmt sind, wird auch deren Aufwand bestimmt. Dieser sollte nicht in Story Points oder Task Points geschätzt werden, sondern in Stunden und ist der Aufwand, der das gesamte Team für die Aktivität benötigt.

Das Estimation Meeting

Das Estimation Meeting (auch Backlog Refinement Meeting genannt) ist das Planungsmeeting mit dem Product Owner, um Klarheit für den nächsten Sprint und die darauf folgenden zu erhalten. Aktivitäten in diesem Meeting sind:

• Details von Backlog Items (meistens User Stories) klären
• Product Backlog Items detaillieren
• Aufwände von Backlog Items schätzen
• Die Priorisierung der Backlog Items überprüfen
• Feedback des Teams zu den Backlog Items erhalten

Das Estimation Meeting soll aber auch den Developern eine gewisse Sicherheit und Perspektive für die zukünftigen Sprints geben.

Das Product Backlog ändert sind während der ganzen Projektdauer. Es kommen neue User Stories hinzu und bestehende werden angepasst oder entfallen. Es gehört deshalb zur Aufgabe des Product Owners, zu jedem Sprint Planning mit einem aktuellen, geschätzten und priorisierten Product Backlog zu erscheinen. Damit er das kann, wird vor jedem Sprint Planning immer ein Estimation Meeting durchgeführt. Die folgende Abbildung zeigt Ihnen, wann das Estimation Meeting zeitlich stattfindet.

Der Zweck des Estimation Meetings

1.  Backlog-Pflege:

• Der Product Owner bespricht mit dem Developern die Backlog Items, die sie im nächsten Sprint oder auch in darauf folgenden Sprints voraussichtlich umsetzen werden.
• Epics und große Backlog Items werden in kleine Backlog Items aufgebrochen, damit diese im Sprint umgesetzt werden können.
• Manche Backlog Items werden ganz aus dem Product Backlog entfernt, wenn Aufwand und Nutzen nicht mehr übereinstimmen oder kein Bedarf mehr da ist.
• Die Developer geben dem Product Owner Feedback bezüglich Machbarkeit, technischen Anforderungen und Abhängigkeiten.

2.  Estimation:

• Für die geänderten und neuen Backlog Items wird der Aufwand bestimmt
• Eventuell zu große Backlog Items werden weiter aufgebrochen.

Das Estimation Meeting dient hauptsächlich zur Vorbereitung auf das Sprint Planning. Damit ist gewährleistet, dass dann bereits alle Aufwandschätzung vorhanden sind und die Developer die umzusetzenden Backlog Item schon kennen. Wenn für neue Backlog Item eine längere Diskussion notwendig ist, dann vertagt der Scrum Master diese in ein eigenes Meeting.
Das Meeting ist aber auch dafür gedacht, die Developer über zukünftige Backlog Items zu Informieren und Feedback einzuholen.

Teilnehmer, Organisation und Ablauf des Estimation Meetings

Am Estimation Meeting nimmt das ganze Scrum-Team teil. Es kann sinnvoll sein auch externe Spezialisten (z. B. Systemarchitekten, Datenbankentwickler oder Mitglieder von Fachabteilung) hinzuzuziehen. Der Scrum Master sorgt als Moderator für einen reibungslosen Ablauf.

Ich empfehle Ihnen das Estimation Meetings etwa zwei Tage vor dem nächsten Sprint Planning durchzuführen. Dann kann der Product Owner bis zum Sprint Planning die Priorisierung und den Releaseplan nochmals überprüfen und falls notwendig anpassen.

Es hat sich bewährt das Estimation Meeting direkt nach einem Daily Scrum durchzuführen, damit der Tagesablauf der Developer nicht wieder durch ein Meeting unterbrochen und gestört wird. Für einen 4-wöchigen Sprint sollte das Meeting nicht mehr als 2-3 Stunden dauern. Es gibt aber auch Scrum-Teams, die das Estimation Meeting zweimal pro Sprint oder wöchentlich durchführen, dafür ist es dann aber viel kürzer. Gemäß Scrum Guide sollte das Estimation Meeting (Refinement) nicht mehr als 10% der Kapazität des Development-Teams beanspruchen.

Wer schätzt Backlog Items?

Ein wichtiger Grundsatz bei Scrum ist: Es schätzen nur die Developer, das heißt, diejenigen, die für die Umsetzung der Backlog Items (z.B. User Stories) verantwortlich sind. Der Scrum Master kann auch mitschätzen, falls er das technische Verständnis hat und die Developer ihn dazu einladen. Beachten Sie, es sollten immer alle Developer beim Schätzen anwesend sein!

Beim Estimation Meeting erklärt der Product Owner die Anforderungen und beantwortet Fragen. Die Developer schätzen und der Scrum Master moderiert und stellt sicher, dass das Meeting pünktlich fertig wird.

Der Nutzen des Estimation Meetings

Neben dem Aufwand schätzen hat Estimation Meeting noch einige weitere wichtige Nutzenelemente:

• Der Product Owner erhält zusätzlich Hilfe, um das Product Backlog zu optimieren
• Wissen wird an alle Projektbeteiligten weitergegeben und vertieft
• Das Product Backlog enthält nur relevante Items
• Fragen und Unklarheiten lassen sich schnell klären (das „Was“ ist geklärt)
• Das Sprint Planning lässt sich vorbereiten (nur noch das „WIE“ ist dann zu klären)
• Risiken werden gemindert, da das Backlog vor dem Sprint Planning diskutiert wird

In diesem Artikel haben Sie erfahren, warum Aufwand schätzen auch bei Scrum sinnvoll ist, und wie Sie ein Estimation Meeting durchführen. Im nachfolgenden Artikel erkläre ich Ihnen, wie man mit Punkten schätzt, und Sie lernen die beiden beliebtesten Schätzungsmethoden im agilen Projektmanagement kennen: Planning Poker und Magic Estimation.

Mehr Infos über die verschiedenen Product Backlog items: Was sind Epics, Features, User Stories und Tasks im agilen Projektmanagement?

Hier gibt es noch mehr Wissen