.st0{fill:#FFFFFF;}

Scrum Toolbox

Nicht fertiggestellte User Stories neu schätzen?

 November 18, 2021

von  Sebastian

Du kennst es bestimmt von deinem Scrum Team auch. Egal, wie gut ihr seid, irgendwann passiert es: Am Ende des Sprints sind noch User Stories oder Teile davon über. Doch was machst du nun genau damit? Neu schätzen? Ignorieren? Oder gar das Erreichte als Punkte anrechnen? Antworten findest du hier!

Warum das teilweise Anrechnen von User Stories gefährlich ist

Manchmal können Entwickler schon knuffig sein - geht es darum etwas in Punkten anzurechnen, kommen sie oft auf kreative Ideen. Eine ganz typische Idee, die du garantiert kennst, ist die Teilanrechnung von Story Points einer User Story.

Diese Teilanrechnung von Story Points ist irgendwie sogar menschlich und nachvollziehbar, sie ist aber keine gute Idee und du solltest als Scrum Master oder Agile Coach sehr genau dahinter schauen, was das wirkliche Bedürfnis ist.

Werfen wir doch einen Blick auf die Situation, was genau passiert, wenn User Stories nicht genau fertig sind und dann auf den Wunsch der Teilanrechnung. Später berücksichtigen wir dann noch den Aspekt, ob wir User Stories neu schätzen sollten.

Was bedeutet es teilweise Story Points anzurechnen?

Durch ein agiles Schätzen kommst du zum Beispiel auf eine gewisse Anzahl von Story Points in deiner User Story.

Teilanrechnungen von Story Points

Jetzt fehlt an der Stelle die komplett abgeschlossene User Story am Ende des Sprints. Die Entwickler (gerne auch mal das Management) argumentieren nun aber, es sei doch nur fair, dass die bereits geleistete Arbeit doch auch dargestellt wird.

Konkret sieht das dann so aus, dass man von beispielsweisen 8 Story Points nun gerne doch 4 Punkte als "fertig" hätte. Der nächste Schluss ist dann ebenso oft dieser, dass gerne argumentiert wird, dann man die andere Hälfte doch einfach in dem nächsten Sprint leisten könne.

Teilanrechnungen von Story Points

Vier ist nicht die Hälfte von Acht

Meine erste Hypothese bei dieser Argumentation wäre, dass das Team die Story Points nicht als Komlexitätsmaß nutzt, sondern als Substitution für Stunden. Es steckt eine Art linearer Bezug dahinter. Das ist erstmal nicht schlimm, ist grundsätzlich aber nicht der Gedanke der Story Points.

Schwierigkeit der genauen Bestimmung

Auch wenn wir die Komplexität einmal rauslassen, ist die Bestimmung dieser "Hälfte" doch nicht immer leicht. Was heißt das konkret? Sind es 50%? Doch nur 47% oder gar 69%? Wir Menschen sind darin doch sehr schlecht im genauen, absoluten Schätzen und diese Angabe wird in der Regel immer viel zu positiv bewertet. Wie viele Projektampeln kennst du, die ganz lange auf grün stehen und dann kurz vor Ende auf rot springen?

Nicht fertig ist eben nicht fertig

Ist die Aufgabe, mir die Haare zu schneiden, dann möchte ich am Ende meines Besuches im Frisörsalon ja auch nicht mit 3/4 geschnittenen Haaren, ungeföhnt und dem nicht entfernten Umhang den Laden verlassen, sondern eben "fertig". Es ist zwar schön zu wissen, dass ich zu "3/4" fertig bin, aber es ist eben nicht tatsächlich fertig.

Auf Scrum bezogen bedeutet das, dass deine Definition of Done eben noch nicht erreicht ist und du damit eine User Story auch nicht abschließen kannst.

Falsche Außenwirkung

Wenn du so eine Teilanrechnung von Story Points einführst, dann erscheint dein Team meist schneller, als es eigentlich ist. Das weckt nicht nur Begehrlichkeiten bei Stakeholdern oder der Organisation, sondern es führt auch zu einem Druck im Scrum Team selbst. Und das ist absolut nicht gut.

Vorteile durch das Vermeiden von Teilanrechnung von Story Points

Wenn du Teams ohne Teilanrechnung beobachtest, stellst du meistens diese beiden Muster fest, die wir natürlich aus der Sicht von Scrum auch wollen.

Da Teilanrechnungen von User Stories oft bei größeren Product Backlog Items auftreten, entsteht grundsätzlich die Tendenz kleinere Einträge zu formulieren und diese umzusetzen. Wenn diese noch genug Wert liefern, ist das optimal.

Der Fokus auf die einzelnen Aufgaben steigt, da sie abgeschlossen werden sollen. Meistens reduziert sich dadurch auch die parallel in Arbeit befindliche Aufgaben.

Warum du deine Arbeit nicht neu schätzen musst

Nachdem wir nun mit einem Mythos aufgeräumt haben und die User Stories bitte nicht mit einer Teilanrechnung von Story Points justieren, wollen wir uns auch dem zweiten Thema gleich widmet. Solltest du die Arbeit neu schätzen, wenn du etwas nicht schaffst? Kannst du machen, ist verständlich - aber auch hier: Lass es besser!

Schauen wir uns das Beispiel an. Du hast eine User Story und am Ende des Sprints ist diese immer noch offen, du hast es also nicht geschafft diese zu fertig zustellen. Du hast dann die folgenden Optionen:

Wenn die Teams mit einer Teilanrechnung von Story Points arbeiten, dann kommt natürlich immer der Wunsch auf die User Story neu zu schätzen, denn die restliche "unfertige" Arbeit muss ja irgendwie in den nächsten Sprint untergebracht werden.

Doch auch wenn du nicht mit einer Teilanrechnung von Story Points arbeitest, kannst du hier immer argumentieren, dass sich die Story Points über die Sprintlänge geändert haben.

Die Velocity ist nur ein Hilfsmittel

Die Velocity wird meist schnell heraus gezogen, wenn es darum geht, ob ein Product Backlog Item in den Sprint gezogen werden kann oder nicht.

Wenn du jetzt die Velocity nutzt, um deine Planung für den nächsten Sprint festzulegen, dann wirst du oder dein Team jetzt vielleicht argumentieren, dass du dafür die neue Planung der User Story benötigst.

Das stimmt zwar, grundsätzlich solltest du dich hier aber nicht verleiten lassen. Es erhöht nicht die Wahrscheinlichkeit der Fertigstellung, wenn du den Eintrag neu bestimmst.

Wenn das Team entscheidet, dass Product Backlog Item passt noch in den Sprint und kann umgesetzt werden, dann ist das so. Ob du den Eintrag neu schätzt oder nicht. Da die Anzahl dieser Einträge auch nicht zu hoch sein sollte, wird es also auch noch eher die Ausnahme sein.

Warum du deine Arbeit nicht neu schätzen musst

Kurz ausgedrückt, musst du deine Arbeit also nicht neu schätzen. Die Entwickler sind in der Lage zu entscheiden, ob es in den Sprint passt oder nicht. Fertig. Einfach. Und gut.

Je mehr du argumentierst, dass du eine solche Neuschätzung benötigst, desto mehr könnte ich mir vorstellen, dass es anderen Bedingungen liegt, dass du das benötigst. Am wenigstens aber, weil es die Sache selbst verlangt.

Wenn es aus deiner Sicht Probleme mit der aktuellen Velocity gibt, dann schaue dir immer auch die durchschnittliche Velocity an. Und auch hier: die Entwickler können das Thema, welches sie kennen auch einschätzen. Versuche weniger zu formalisieren und mehr gesunden Menschenverstand walten zu lassen.

Fazit

Wir haben gesehen, machbar ist - wie so oft - vieles. Wer eine schlanke, reife und schnelle Scrum Implementierung möchte, macht sich wenig Gedanken um das erneute Schätzen von User Stories oder die Teilanrechnungen von Story Points. Wer die (scheinbare) Sicherheit wünscht, kann mit einer Teilanrechnung von Story Points oder dem erneuten Schätzen erste Schritte identifizieren, die auf einem Weg zu einem Ziel eine Möglichkeit sein können.

Sebastian

Ein paar Worte über den Autor

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

Sebastian Schneider CSP-PO
Sebastian Schneider CSP
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hole dir auch den kostenlosen Online Scrum Kurs

>