Folge 084 StoryPoints wegstreichen

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,


Janina & Henry


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:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post Folge 084 StoryPoints wegstreichen appeared first on
Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan,
Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy.