Folge 055 Referenz Story

Referenz Story

Heute bearbeiten wir wieder einen Hörerwunsch, die Referenz Story
für das Refinement.


Den ein oder anderen mag das vielleicht irritieren, denn das geht
schon etwas tiefer in die Schätzmethodiken, die wir so tief noch
nicht behandelt haben. Gleichzeitig wird sich Dir als Facilitator
die Frage stellen, wie Du denn nun anfangen sollst mit Schätzen.
Da ist diese Folge genau richtig. Ich empfehle Dir auf jeden Fall
noch einen Blick in die StoryPoints Folge. Vieles baut hier auf
StoryPoints auf. Demnach wäre es toll, wenn Du bereits weißt was
es damit auf sich hat, so können wir diese Folge schön kurzhalten
und nur erklären, wie es zur ersten Anforderung mit 5 oder 8
StoryPoints kommt.
Also große Frage heute:

Wie kommt es zu einer Referenz User Story?


Statt User Story können wir auch Anforderung sagen. Wird diese
erste Referenz Story nun gemeinsam ausgewählt? Wie wird es
gemacht? Wofür kann ich sie verwenden? Wie komme ich zur besten
Referenz? Brauche ich mehr als eine Referenz?
Wofür brauche ich diese Referenz Story?

Diese ist für das relative Schätzen nötig. Da wir im Agilen
relativ schätzen ist eine Referenz nötig, zu der wir sagen können
ist die nun neue Anforderung mehr oder weniger Komplex als diese
Referenz. Diese Schätzung hilft auch dabei festzustellen ob alle
diese Anforderung gleichermaßen verstanden haben.


Wenn diese Referenz von beispielsweise 5 irgendwann umgesetzt
wurde bekommst Du auch ein gutes Gefühl, was diese 5 bedeutet an
Zeit und Ressourcen und im Verhältnis dazu, was die anderen
Anforderungen dann wohl kosten werden.


Der Product Owner bekommt über die Schätzung wahrscheinlich die
meisten und besten Daten. Also wie kann er die jeweiligen
Anforderungen einplanen und was bedeutet das an Umfang und
Komplexität.


Die Referenz ist also ein entscheidendes Mittel im Refinement.


Wir sagen also nicht mehr, diese Anforderung braucht 8 Stunden,
sondern die Fahrt nach Barcelona ist komplexer als die Fahrt nach
Berlin. Konkreter sogar: Die Fahrt nach Barcelona ist 5x so
komplex wie die Fahrt nach Berlin. Berlin wäre in dem Fall unsere
Referenz. Nur wie sind wir auf Berlin gekommen?
Mehrere Wege führen zum Ziel

Wie so üblich, im Agilen, gibt es nicht den einen perfekten Weg.
Es kommt auf das Team und die Situation an. Wir geben Dir daher
mehr Möglichkeiten und als Facilitator wirst Du für Dein Team
schon die beste finden.
1 der schnelle Weg

Nimm irgendeine Anforderung aus dem Backlog und sag das ist jetzt
eine 5 (oder optional eine beliebige andere Zahl, vielleicht eine
8). Zack, fertig.


Alle anderen Anforderungen werden nun in das Verhältnis zu dieser
Anforderung gesetzt.


Das kann mitunter auch guten Gegenwind vom Team geben. Gibt dann
aber nicht so ewig lange Diskussionen. Sie sagen dann schon recht
schnell, was eine bessere 5 wäre.


Dafür braucht etwas Mut und ein gutes Standing, also vielleicht
nicht die beste Methode für einen neuen Scrum Master.
2 Frag das Team

Ein zweiter guter Weg ist einfach das Team zu Fragen. Wo ist die
Mitte? Das kann mitunter auch zu langen Diskussionen führen, vor
allem wenn das Backlog schon sehr groß ist. Behalte das im Auge,
die Diskussion ist es oft nicht wert. Die Referenz muss nicht
perfekt sein und kann sich über die Zeit sowieso ändern.


Im Barcelona Berlin Beispiel: Wenn ich Berlin nicht als Referenz
hätte und Dich frage zu welcher Stadt wäre ein Mittellanger Weg,
was würdest Du dann antworten?
3 Anforderung nehmen die schon umgesetzt wurde

Führst Du das Schätzen erst später ein, dann gibt es schon
umgesetzte Anforderungen. Alle beteiligten haben dann dazu oft
schon ein gutes Gefühl und können genau sagen, was einer
mittleren Komplexität entsprochen hat und Dir die 5 oder 8
StoryPoint Anforderung benennen.


Die Methode geht oft sehr gut durch.
4 Extreme

Was ist das aller einfachste, was sich das Team vorstellen kann?
Was ist also nur eine Fingerübung? Eine typographische Korrektur
zum Beispiel.


Als Gegensatz: Was ist eine Anforderung für die ihr etwa 3 Wochen
benötigt? (Eine Iterationslänge)


Diese beiden legst Du auf 2 und auf 20 fest. Du merkst schon, Du
darfst auch mehrere Referenz Anforderungen im Team haben.
5 Team Estimation Game

Henrys eigene und beliebteste Methode. Vor allem für frische
Teams geeignet, die noch nie geschätzt haben.


Alle Anforderungen werden nacheinander an die Wand (oder wenn Du
magst den Boden) gehängt und relativ zueinander zugeordnet.
Entweder in Zeilen oder Spalten. Einigt euch vorher, welche
Richtung komplexer und was weniger Komplex ist. Erst danach legst
Du Stück für Stück die StoryPoint Einheiten dazu. Danach nimmst
Du dann erst Anforderungen aus dem gewünschten Bereich als
Referenz. So hat das Team während der kompletten Zeit die Chance
Dinge umzusortieren oder zu clustern. Beim Zuordnen beim ersten
Team Estimation Game würde ich mit der Zahl 2 an Story Points
beginnen, falls später noch etwas einfacheres kommt.


Dieses Verfahren ist sehr ähnlich zur Bucket Estimation, welches
mit Eimern arbeitet, an denen bereits die StoryPoints stehen und
die Anforderungen nur in die jeweiligen Eimer geworfen werden.
Die Bucket Estimation hat aber den Nachteil, dass die
Anforderungen dann aus den Augen und dem Sinn sind und, dass
nachträgliche Änderungen und Verschiebungen zu großen
Diskussionen führen.
6 Narrative

What is a piece of cake? Baut Geschichten und Bilder dazu auf,
was eine Referenz ist. Jeder im Team kann erzählen, was er sich
entsprechend unter einer mittleren Größe oder Ähnlichem
vorstellt. So kommt das Team auf einen Mittelwert, der stark
verankert als Geschichte ist. Was passt gerade so nicht in einen
Sprint? Was ist knapp daneben?


Über Zahlen wird ansonsten häufig zu Beginn diskutiert.
7 Referenz Story aus einem anderen Team nehmen

Du kannst eine Referenz Story aus einem anderen Team
präsentieren. Das funktioniert auch, wenn es unterschiedliche
Themen sind. Jeder kann relativ dazu schätzen. Das schöne ist,
die Referenz muss nicht stimmen und gleichzeitig wird es von
vielen einfach so akzeptiert. Der Scrum Master hat ein
entsprechendes Standing und die Teammitglieder nicken oft, wenn
ihnen etwas aus einem anderen Team, was dort schon funktioniert
hat präsentiert wird. Achtung auch hier: Nicht alles was in einem
Team funktioniert, funktioniert auch in einem anderen Team.
StoryPoints nicht mit anderen Teams vergleichen

Du merkst es schon die StoryPoints bezogen auf eine Referenz sind
sehr Team individuell. Unter anderem abhängig zur Referenz. Das
bedeutet, dass eine 5 aus einem Team nicht bedeutet, dass sie
auch in einem anderen Team eine 5 wäre. Auch dafür gibt es einige
Wege, die man gehen könnte in einem skalierten Umfeld, doch das
geht zu weit und ist oft auch nicht nötig. Wir wollen ja gerade
Teams nicht vergleichen und auch die Abarbeitung lässt sich so
nicht rückentschlüsseln.


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