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.