Die Schätzung der Stories in deinem Backlog hilft dir dabei, vorherzusagen, wie lange du brauchen würdest, um bestimmte Teile des Backlogs zu liefern. Beachte, dass sich diese Diskussion auf die Best Practices bezieht, die wir als Hauptpfad in Jira Software implementiert haben. Du kannst dich gegen diesen Schritt entscheiden, wenn du meinst, dass er für dein Team nicht geeignet ist.

Bevor ein Sprint beginnt, musst du Schätzungen für deine Vorgänge eingeben.

So gibst du eine Schätzung ein:

1. Gehe zum Backlog deines Scrum-Projekts.
2. Wähle einen Vorgang aus und gib eine Schätzung in das Feld Story Points oder Ursprüngliche Schätzung ein (je nachdem, welche Schätzungsstatistik du eingestellt hast).

Zeit protokollieren und die verbleibende Schätzung anpassen

Wenn du während des Sprints an Vorgängen arbeitest, kannst du die Zeit protokollieren und die Schätzung der verbleibenden Zeit bei Bedarf anpassen. Die Zeiterfassung liefert wertvolle Informationen, die du für Berichte in Jira nutzen kannst.

1. Gehe zu den Aktiven Sprints in deinem Scrum Board.
2. Wähle einen Vorgang aus und klicke auf > Arbeit protokollieren (oder klicke auf das Zeiterfassungsfeld).
3. Gib deine Arbeitszeit und die verbleibende Zeit ein und klicke dann auf Speichern.

Wenn du das Burndown-Diagramm verwendest, beachte, dass sich die Subtasks unterschiedlich verhalten können, je nachdem, ob die Restschätzung und verbrauchte Zeit für dein Board aktiviert ist oder nicht.

Weitere Informationen findest du unter Burndown-Diagramm.

Hier sind einige Konzepte, die du bei der Schätzung von Vorgängen in Jira Software beachten solltest.

Schätzung ist etwas anderes als Zeiterfassung

In Scrum gibt es einen Unterschied zwischen Schätzung und Zeiterfassung. Die Schätzung erfolgt in der Regel anhand von Primary Backlog Items (PBIs, in der Regel Stories) und dient dazu, herauszufinden, wie lange es dauern könnte, bis Teile des Backlogs geliefert werden. Bei der Zeiterfassung geht es darum, den Fortschritt eines Sprints zu überwachen, um sicherzustellen, dass alle im Sprint enthaltenen Stories geliefert werden.

Die Zeiterfassung erfolgt oft, indem die Stories in Aufgaben unterteilt und während der Sprintplanung mit Stundenschätzungen versehen werden, um dann während des Sprints die verbleibende Zeit in einem Burndown zu überwachen.

Wie werden Schätzungen in traditionellen Entwicklungsumgebungen durchgeführt?

In traditionellen Entwicklungsumgebungen wird die Schätzung auf diese Weise fertiggestellt:

1. Ein Team schätzt die Aufgaben in "Arbeitsstunden" - und diese Schätzungen werden als präzise angesehen.
2. Das Team errechnet dann die Gesamtzahl der Arbeitsstunden für das Backlog eines Projekts.
3. Das Team teilt dann die Gesamtzahl der Arbeitsstunden durch die Anzahl der Personen im Team und die Arbeitsstunden in einer Woche. Daraus ergibt sich das prognostizierte Datum für das Projekt.

Diese Schätzungen sind oft ungenau, weil sie Folgendes nicht berücksichtigen:

• Die natürlichen Schätzungseigenschaften des Teams - das heißt, Über- und Unterschätzungen werden nicht berücksichtigt.
• Unerwartete Unterbrechungen während der Arbeitsstunden, die für die Aufgaben vorgesehen sind
• Die Leistung der Teammitglieder selbst im Laufe der Zeit.

Wenn die Schätzungen ungenau werden, muss das Team Zeit und Mühe aufwenden, um die Genauigkeit der Schätzungen zu "erzwingen". Das macht den Ansatz der Arbeitsstunden schwierig, wenn nicht sogar unmöglich.

Bei der Schätzung in der Scrum-Welt dreht sich alles um Velocity

In der Scrum-Welt versuchen die Teams nicht, eine exakte Schätzung zu erreichen. Stattdessen streben sie eine "zuverlässige Velocity" an.

Die Velocity ist ein Maß für die Anzahl der Schätzungseinheiten, die ein Team von Sprint zu Sprint fertigstellt. Nach den ersten paar Sprints erreichen die meisten Teams eine einigermaßen konstante Velocity. Mit der Velocity und den Schätzungen für die PBIs im Backlog können die Teams genauer vorhersagen, wie lange die Fertigstellung von Teilen des Backlogs dauern wird.

Der Schlüssel ist, dass die Schätzungseinheit keine Rolle spielt - solange sie von Sprint zu Sprint einigermaßen vorhersehbar ist. Teams können zum Beispiel "Idealstunden"-Schätzungen verwenden, aber es ist weder notwendig noch zu erwarten, dass diese Stunden in irgendeiner Beziehung zur verstrichenen Zeit stehen. Wenn ein Team in jedem Sprint eine "Arbeitsstunden"-Kapazität von 120 Stunden, aber eine Velocity von 60 Stunden hat, macht das keinen Unterschied, denn du kannst die Velocity von 60 Stunden immer noch nutzen, um die Anzahl der Sprints abzuschätzen, die Teile des Backlogs zur Fertigstellung benötigen - und damit auch die verstrichene Zeit.

Viele Leute fragen sich dann, wo "die anderen 60 Stunden" geblieben sind, und unterstellen damit, dass mit der Produktivität des Teams etwas nicht stimmt. Aber das hat in der Regel nichts damit zu tun: Die Schätzungen eines Teams spiegeln lediglich die Ansicht des Teams wider, wie schwer die Aufgaben sein werden, wobei das natürliche Verhalten des Teams (z. B. Über- und Unterschätzung) sowie der organisatorische Zusatzaufwand usw. berücksichtigt werden. Die Velocity ist das Einzige, was aus Sicht der Planung zählt. 

Da die Einheiten keinen Bezug zur Zeit haben, entscheiden sich die meisten Teams heute für Story Points als Schätzungseinheit. Ein Story Point ist eine willkürliche Zahl, die die Komplexität einer Story im Vergleich zu anderen misst. Mit Story Points wird die mentale Verbindung zur Zeit aufgehoben.

Ungenaue Schätzungen sind gut, solange sie gleichermaßen ungenau sind

Damit die Velocity eines Teams einen stabilen Zustand erreicht, muss das Team jedes Backlog-Element mit der gleichen Präzision schätzen. Auch auf die Gefahr hin, das Offensichtliche zu wiederholen: Das Ziel der Velocity ist es, ein Backlog mit nicht besonders gut verstandenen Stories zu betrachten und zu verstehen, wie viele Sprints es zur Fertigstellung braucht. Dies erfordert ein ähnliches Maß an Ungewissheit für alle Schätzungen im Backlog.

Das bedeutet, dass die Teams jeden Posten nur einmal schätzen sollten und diese Schätzung auch dann nicht ändern sollten, wenn sie neue Informationen über den Posten entdecken, die sie zu dem Schluss kommen lassen, dass ihre Ursprüngliche Schätzung falsch war. Wenn das Team fortfährt und die Schätzungen aktualisiert, wird diese "Entdeckung neuer Informationen" regelmäßig passieren. Das führt dazu, dass im Backlog einige Posten eine höhere Genauigkeit haben, die meisten aber nicht. Dies würde die Velocity beeinträchtigen, da Sprints mit einem höheren Prozentsatz an hochgenauen Schätzungen eine andere Anzahl von Einheiten abschließen als Sprints mit einem geringeren Prozentsatz an hochgenauen Schätzungen. Infolgedessen könnte die Velocity nicht für ihren eigentlichen Zweck verwendet werden - nämlich für die Schätzung der Anzahl von Sprints, die ein Team benötigt, um eine Reihe von nicht gut verstandenen Stories im Backlog abzuschließen. Deshalb ist es wichtig, die ersten Schätzungen so zu verwenden, dass die Velocity des Teams realistisch die Fähigkeit widerspiegelt, eine bestimmte Anzahl von Einheiten nicht gut verstandener Arbeit weit in der Zukunft abzuschließen.

Was ist, wenn Teams merken, dass sie sich geirrt haben?

Betrachte das folgende Szenario:

• Vorgang X hat eine Ursprüngliche Schätzung von 5 Tagen.
• Bevor der nächste Sprint geplant wird, stellt das Team fest, dass die Ursprüngliche Schätzung zu optimistisch war und der Vorgang tatsächlich 15 Tage in Anspruch nimmt. 

Manche würden argumentieren, dass die Ursprüngliche Schätzung den Erfolg des Sprints gefährdet, weil das Team 5 Tage Arbeit in den nächsten Sprint mitnimmt, obwohl es in Wirklichkeit 15 Tage Arbeit sind.

Es ist jedoch unwahrscheinlich, dass die ungenaue Schätzung von 5 Tagen ein Einzelfall ist. Tatsächlich werden die Schätzungen immer falsch sein (manche sehr wenig, manche sehr stark). Das wird oft erst nach dem Start des Sprints festgestellt und nicht schon vorher. Solange das Team seine Schätzungen für das gesamte Backlog auf die gleiche Weise vornimmt, wird sich das mit der Zeit von selbst erledigen. Wenn sie zum Beispiel immer zu niedrig schätzen, kann es sein, dass sie sich bei einem 10-Tage-Sprint mit 4 Teammitgliedern nur auf 20 Tage ihrer Schätzungseinheit festlegen können. Wenn sie eine stabile Velocity erreicht haben, hat dies keine Auswirkungen. Aus der Planungsperspektive können wir immer noch zuverlässig abschätzen, wie viel Arbeit wir in den kommenden Sprints fertigstellen werden.

Bricht das nicht die Sprint-Commitment?

Wenn das Team kurz vor einem Sprint steht, kann es die Velocity als Anhaltspunkt für die Aufgaben aus dem Backlog nutzen, die es realistischerweise erledigen kann. Die Velocity basiert dabei auf der Anzahl der Aufgaben, die das Team in der Vergangenheit erfolgreich abgeschlossen hat. Manche fragen sich jedoch, wie das richtig sein kann, wenn die Ursprünglichen Schätzungen keine Informationen über die bereits erledigte Arbeit oder darüber enthalten, wie aufwändig ein bestimmtes Element der Arbeit ist.

Betrachte zum Beispiel das folgende Szenario: 

• Ein Vorgang hat eine Ursprüngliche Schätzung von 10 Tagen.
• Das Team arbeitet im aktuellen Sprint 5 Tage an dem Vorgang.
• Das Team entdeckt irgendwo im Projekt einen schwerwiegenden Bug und beschließt, dass die Behebung dieses Bugs im aktuellen Sprint viel wichtiger ist als der planmäßige Abschluss des Vorgangs X.
• Der Sprint wird beendet, und der Vorgang kehrt ins Backlog zurück.

Im nächsten Sprint wäre das Team versucht, die Schätzung für den Vorgang auf 5 Tage zu aktualisieren und auf dieser Grundlage zu entscheiden, ob der Vorgang in den Sprint aufgenommen werden soll oder nicht. Wenn sie die Ursprüngliche Schätzung von 10 Tagen für den Vorgang verwenden würden, könnten sie im nächsten Sprint nicht genug Arbeit einplanen. Der Grund dafür, dass die Aufgabe bisher nicht erledigt wurde, ist jedoch ungeplante Arbeit - und es ist unrealistisch anzunehmen, dass dies in Zukunft, vielleicht sogar im nächsten Sprint, nicht wieder passieren wird. Daher ist die 10-Tage-Schätzung eine realistische Zahl, die man verwenden kann, wenn man keine Gewissheit hat. Daher werden die Kosten für die ungeplanten Arbeiten in der Ursprünglichen Schätzung berücksichtigt. Selbst wenn sich herausstellt, dass die Arbeit für den nächsten Sprint nicht ausreicht, wird das Team dies korrigieren, indem es mehr Arbeit in den Sprint zieht.

Nehmen wir an, dass dies der einzige Vorgang in diesem Sprint war und auch im nächsten Sprint der einzige Vorgang sein wird. Wenn der Vorgang im zweiten Sprint abgeschlossen wird und wir die verbleibende Schätzung verwenden, dann beträgt die Velocity (0d + 5d) / 2 = 2,5d. Allerdings kann das Team in zukünftigen Sprints deutlich mehr Arbeit erledigen als das. Wenn wir die Ursprüngliche Schätzung verwenden, beträgt die Velocity (0d + 10d) / 2 = 5d. Die Ursprüngliche Schätzung trägt der Tatsache Rechnung, dass sich das Team nicht in jedem Sprint auf 10d festlegen kann, weil ungeplante Arbeiten dies wahrscheinlich unmöglich machen werden. Sie berücksichtigt auch die Tatsache, dass ungeplante Arbeiten nicht in jedem Sprint anfallen werden.

Warum nicht auf Subtasks schätzen und diese für Velocity und Commitment verwenden?

Viele Teams unterteilen die Stories kurz vor Beginn des Sprints in Subtasks, damit sie die Stories für das Tracking nutzen können. Dadurch ergibt sich die Möglichkeit, die Summe der Schätzungen für die Subtasks zu nutzen, um zu entscheiden, für welche Vorgänge im Sprint eine Zusage gemacht werden soll (und möglicherweise für die Velocity). 

Wie oben beschrieben, ist die Zeiterfassung ein von der Schätzung und Velocity getrennter Prozess. Die Schätzungen, die auf die Subtasks angewendet werden, haben eindeutig eine höhere Genauigkeit als die, die ursprünglich auf die Story angewendet wurden. Wenn du sie für die Velocity verwendest, würde die Velocity sowohl hohe als auch niedrige Genauigkeitsschätzungen enthalten, was sie unbrauchbar macht, wenn du weiter draußen im Backlog suchst, wo die Stories nur niedrige Genauigkeitsschätzungen haben.

Außerdem ist es wahrscheinlich, dass nur die Punkte am Anfang des Backlogs in Aufgaben unterteilt wurden. Die Verwendung von Aufgabenschätzungen für die Velocity bedeutet, dass der Velocity-Wert nur die Zeit für die Fertigstellung des Backlogs bis zur letzten Story, die in Aufgaben unterteilt wurde, vorhersagen kann.

Schließlich ist die Verwendung des Subtask-Roll-ups zur Entscheidung über das Sprint Commitment riskant, da er im Gegensatz zum Velocity-Wert den Mehraufwand durch ungeplante Arbeit und Unterbrechungen nicht berücksichtigt.

Story Points sind sehr empfehlenswert - aber wähle das, was für dein Team am besten geeignet ist

Immer mehr Branchenführer rücken von Stundenschätzungen ab und verwenden jetzt den Story Point-Ansatz. Das macht Sinn, denn die wichtigsten Fragen, die in einem Sprint beantwortet werden müssen, sind:

• Wie viel Arbeit können wir realistischerweise in diesem Sprint erledigen?
• Wie lange wird es dauern, bis dieser Teil des Backlogs fertig ist?

Der Story Point-Ansatz, der auf ursprünglichen Schätzungen basiert, kann die Antworten auf diese Fragen liefern, ohne dass die Teams Angst vor der "Genauigkeit" haben, die sie empfinden, wenn sie aufgefordert werden, in Stunden zu schätzen.

Das Jira Software-Team selbst verwendet den in diesem Artikel beschriebenen Ansatz und hat eine verlässliche Velocity festgelegt, mit der wir die Arbeit Monate im Voraus planen - auch wenn in diesen Monaten neue Arbeit entstanden ist. Wir empfehlen diesen Ansatz, weil er zwar manchmal kontraintuitiv ist, aber auch leistungsfähig, schnell und einfach ist. 

Einer der wichtigsten Grundsätze von Agile ist es, den Weg zu finden, der für dich funktioniert. Daher unterstützt Jira Software die oben beschriebenen Alternativen, einschließlich der Verwendung von Restschätzungen für die Sprintverpflichtung, Stunden für die Schätzung und Stundenschätzungen für Sub-Tasks.