StoryPoints wegstreichen
Heutiges Thema: StoryPoints wegstreichen. Ja, stand eigentlich nicht auf der Liste und ist Henry Schneider im Coaching begegnet. Erste Reaktion war „Nein, nicht machen.“ und dann erinnerte sich Henry, dass er das auch mal vor Jahren gemacht hatte. Die Frage ist also valide und warum macht Henry das heute nicht mehr?
Diese Folge auf YouTube: https://youtu.be/OCBx8aBLS2g
Die Frage
Wie sieht es denn mit den StoryPoints von angefangenen UserStories beim Sprintübertrag aus? Da sie angefangen sind, mache ich dann aus der 8 eine 3 und nehme diese dann mit in den nächsten Sprint?
Erste Reaktion war „Nein auf keinen Fall“. Und dann dachte ich kurz nach. Cool, dass einer danach fragt! Und klar, habe ich auch gemacht, daraus gelernt und würde es daher heute nicht machen. Doch probier es ruhig aus und sammle Deine eigenen Erfahrungen. Heute geht es darum, warum wir als frische Scrum Masterinnen an diesen Punkt kommen, was wir dann durchaus machen und warum das vielleicht nicht die beste Idee für jedes Team ist.
Was mache ich denn mit meinen Anforderung / Stories beim Übertrag in den nächsten Sprint?
Es liegt doch nahe die Anforderungen / User Stories, welche nicht fertig geworden sind, zu klonen und nur den Rest in den nächsten Sprint zu übertragen. An diesen Punkt kommen die meisten beginnenden Scrum Masterinnen und so auch wir.
Woher kommt das Bedürfnis?
Wir haben halt an einer Anforderung bereits Komplexität in Form von StoryPoints abgearbeitet und wollen dies natürlich korrekt berechnet für den nächsten Sprint haben. Das nächste Planning soll schließlich sauber sein und die getane Arbeit vom Team auch anerkannt werden. Zudem soll die Planung auch sauber sein.
Wahrscheinlich gibt es auch das Bedürfnis, dass am Ende des Sprints etwas fertig sein soll. Es liegt also nahe die Story an der Stelle abzuschneiden und nur den Rest zu übertragen. Diesen verspürten Druck hat Scrum ja auch eingebaut. Getting shit done eben.
Natürlich gibt es auch eng eingebundene Kunden und Stakeholder, die gern Fragen stellen und denen man auch den Fortschritt zeigen möchte, indem Anforderung als fertig markiert sind.
Wenn sehr neu nach Scrum umgestellt wurde, dann ist auch sehr wahrscheinlich, dass die Zyklen sich arg verkürzt haben. Also statt einmal im Jahr zu liefern darf nun alle zwei Wochen geliefert werden. Dies ist eine Gewöhnungssache bei der die Storygröße am Anfang oft noch nicht passt und es so häufiger zu einem Überlauf kommt.
Nachdem wir mit Stories nicht fertig geworden sind steht in einem Sprint direkt Review, Retrospektive und dann das nächste Planning an. Als Entwickler darf ich mich dann eventuell rechtfertigen dafür und da liegt es nahe entsprechende Auswege und Begründungen zu suchen.
Henry hätte gedacht es käme eher von der positiven Seite, dass man ja anerkennen möchte, dass die Entwickler etwas geleistet haben. Genauso hatte Henry das damals ausprobiert um eine möglichst gleichbleibende Velocity und Sprintschätzung für das Planning hinzubekommen. Und damit ging das Chaos erst richtig los, da manche Schätzungen nachkorrigiert waren und andere nicht… Allein der Aufwand das nachzupflegen…
Was passiert denn da?
Beim Übertrag muss nachgeschätzt werden, Dupliziert und die Beschreibung angepasst. Also die Anforderung geht mindestens in ein zusätzliches Refinement. Ganz schön viel Aufwand! Zudem ist es für viele Beteiligte äußert verwirrend und wie belastbar sind dann die Zahlen?
Lässt sich später aus Qualitätssicht noch die Entwicklung eines Features sauber nachvollziehen?
Weiterhin kann es sein, dass sich das Team daran gewöhnt und auf diese Weise immer solchen Rest mit sich rumträgt und gar nicht erledigt. Ich produziere gern ein bisschen Schmerz, damit es auch einen Grund gibt die Dinge fertig zu machen. 😉
Was tun?
Wenn das Bedürfnis und damit verbunden der Druck von außen kommt, dann ist es wichtig mit dem Umfeld darüber zu sprechen. Also was richtet dieser Druck an.
Starte Experimente.
Mittelwerte über die Sprints bilden und als Eingangsgröße verwenden. Wenn es einen kompletten Übertrag von Stories gibt und diese quasi fertig sind, dann werden sie ja im nächsten Sprint auch fertig. Der Mittelwert über beispielsweise drei Sprints sollte dann wieder der realen Kapazität des Teams entsprechen.
Prüf den Schnitt der Anforderungen. Vielleicht ist der Schnitt auch ungünstig und Du kannst für die nächsten Male hierin besser werden.
Janina beantragt ein 13. Agiles Prinzip
Im Podcast stellt Janina den Antrag, dass es gut ist zu Planen und der Plan dann nicht mehr gut ist. Also es ist gut einen Plan zu haben und dem sollte man nicht die ganze Zeit hinterher hecheln.
Also gern planen und damit ein Ziel verfolgen nach bestem Wissen. Wie gut der Plan dann war ist ab dem Zeitpunkt dann irrelevant.
Das Team darf sich überschätzen
Als Scrum Masterin bist Du etwas im Zwiespalt mit Deinem Team. Wenn es immer genau die Planung erreicht unterschätzt sich das Team wahrscheinlich. Das könnte auch am Umfeld liegen. Genauso ist es oft schlecht für die Moral, wenn es nie die Planung erreicht. Es darf zwischen beiden Welten einen guten Mix geben. Und natürlich auch Freiräume wie Slacktime.
If everything is under control, you are going too slow. – Mario Gabriele Andretti
Wenn Du mit Deinem Plan immer richtig liegst bist Du wahrscheinlich auch nicht mehr in einem komplexen Umfeld. Scrum ist dann wahrscheinlich nicht das richtige Framework.
Daran kannst Du auch super ableiten in welchen Teamphasen sich das Team gerade befindet.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
- Scrum
- StoryPoints
- Scrum Masterinnen
- Team
- Getting shit done
- Stakeholder
- Retrospektive
- Komplexität
- Qualitätssicht
- Experimente
Connecte dich gerne hier mit uns:
