Referenzstory
Eine Referenzstory dient in der Agilen Produktentwicklung einem Team als Hilfestellung, den Aufwand der Arbeit einer tatsächlich zu bearbeitenden User Story zu schätzen. Bei der Referenzstory handelt es sich um eine User Story, deren Anforderungen, Komplexität und Umsetzung für alle Team-Mitglieder nachvollziehbar ist. Auf diese Weise wird sie zur relativen Schätzung genutzt.
Wie werden im Scrum Referenzstorys genutzt?
Das Team betrachtet zunächst den Aufwand der Story, die als Referenz dient, und bewertet sie anschließend mit den dementsprechenden Story-Punkten. Neue Anforderungen in Form von User Storys werden nun in Relation bzw. Referenz mit dem Aufwand dieser Referenzstory bewertet. Schätzt das Scrum Team den Aufwand für die Umsetzung der neuen User Story zum Beispiel höher ein, wird diese mit höheren Story Points bewertet.
Warum sind Referenzstorys für dein Team sinnvoll?
Scrum und andere agile Methoden bemessen den Aufwand für die Umsetzung von Aufgaben nicht in "Personentagen" oder generell Zeit, sondern in abstrakten Story Points. Der Grund ist, dass allen Teammitgliedern und anderen Mitarbeitern im Unternehmen bewusst sein soll, dass es sich bei den Angaben zum Aufwand um relative Aufwandsschätzungen und keine konkreten Zeitangaben handelt. Genaue Zeitangaben und Zeitschätzungen sind in vielen Fällen viel zu ungenau um hiermit sinnvolle Ergebnisse erzielen zu können. Mit Hilfe der Referenzstories und der Summe an Punkten in einem Sprint kann sich allerdings mit etwas Erfahrung eine passende Schätzung des zu schaffenden Aufwands pro Team abgeben.
Wie läuft die Schätzung einer User Story in Relation zur Referenzstory ab?
Für die Schätzung einer Story als Product Backlog-Item werden im Scrum besondere Poker Karten für das sogenannte Estimation Poker (auch Scrum-Poker oder Planning Poker genannt) genutzt. Diese Schätzung findet je nach Team in der Regel im Refinement oder beim Sprint Planning statt.
Beim Estimation Poker erhält jedes Team-Mitglied ein eigenes Deck an Karten. Die Mitglieder ziehen nun jeder für sich gleichzeitig die Poker Karte mit der Anzahl an Story Points, die sie für die Umsetzung der Story als realistisch schätzen. Bei dieser Schätzung orientieren sie sich am zuvor in der Gruppe festgesetzten Aufwand der Referenzstory.
Nach Aufdecken der Karten und einer Diskussion über eventuelle Unterschiede in den Schätzungen und Ideen zur Umsetzung seitens der Developer zeigt sich, ob das Team noch einmal den Product Owner für weitere Klärung der Anforderungen innerhalb der Story zu Rate ziehen möchte.
Tipp:
Sehr hohe Aufwandsschätzungen von zum Beispiel 40 oder 100 Story Points deuten darauf hin, dass die User Story in mehrere Storys gesplittet werden kann.
Ist die Schätzung für die User Story nach einer weiteren Runde Planning Poker abgeschlossen, werden die geschätzten Story Points auf dem Product Backlog-Item vermerkt als Vorbereitung für das Sprint Planning.
Fazit zu Referenzstorys im Agilen Schätzen
Wird eine gut schätzbare Story als Referenz eingesetzt, erfolgt die Schätzung neuer Storys durch das Team auf gemeinsamer Basis. Nur auf diese Weise können sich die Mitglieder einem gemeinsam geschätzten Aufwand nähern und sich später im Sprint auf diese Storys committen.
Die in einem Sprint erledigten Storys dienen wiederum zur Berechnung der Velocity (Arbeitsgeschwindigkeit des Teams), auf Basis derer sich zukünftige Sprints einfachererst sinnvoll planen lassen.