Eine verbreitete Maßnahme um Userstories einen Wert zuzuweisen ist die der Storypoints. Hierbei kann ein Punkt einer Referenz Story entsprechen und die weiteren Aufwände einem Vielfachen der Aufwände der Referenzstory. Im Mittelpunkt steht auch hier der Nutzen für die User.
Mit Hilfe der Story Points wird die Größe einer User Story beschrieben. Das Wort Größe kann hierbei allerdings nicht genau definiert werden, da viele Faktoren Einfluss darauf haben. Ein Team könnte Größe für User Stories und Story Points ggf. so definieren
“Die Größe einer story ergibt sich aus Ihrer Komplexität, welche davon abhängig ist wie viele Schichten in der Software Architektur bei der Umsetzung angepasst werden müssen.” Hier wird schnell ersichtlich, dass anhängig von der jeweiligen Definition und Team Zusammensetzung unterschiedliche Wahrnehmungen und Verständnisse von Größe aufeinander stoßen können.
Meistens werden sogenannte Referenzstorys beschrieben und die jeweiligen User Stories werden in der Größe und Komplexität mit dieser in Verhältnis gebracht. Ist eine User Story umfangreicher, so werden auch mehr Punkte vergeben – hingegen wenn die zu schätzende User Story kleiner ist weniger.
ein Beispiel-Referenzstory zum Verständnis
“Ich als User möchte, wenn ich auf den Button Uhrzeit anzeigen klicke, dass mir die aktuelle Uhrzeit in meiner Zeitzone angezeigt wird”
Dies ist eine recht einfache Referenzstory. Sie enthält sowohl Frontend als auch Backend Funktionalität. Einerseits gibt es die Userinteraktion mit dem Button Klick, andererseits die Abfrage der Zeit auf Basis der Zeitzone. Dies sollte im Backend erfolgen.
Vielfaches der Referenzstory
Bei den Schätzungen im Development Team werden dann die Aufwände im Verhältnis zu der o.g. Story bewertet. Je nachdem worauf sich geeinigt wird, erhält die Story dann entsprechende Story Punkte.
Im Laufe eines Projekts ist es normal, dass die Referenz Story angepasst wird. Auch hier sehen wir wieder, agile Projekte gehen davon aus, dass sich Anforderungen und Definitionen ändern.
Warum Story Points verwenden?
Die erste Diskussion die in den meisten Teams geführt wird lässt sich mit folgender Frage zusammenfassen: “Warum nehmen wir anstatt von Story Points nicht Stunden, die wir meinen für die Umsetzung zu benötigen?”
Eben genau das sollte in einem agilen Projekt überdacht werden. Natürlich kann ein Team auch definieren, in welcher Relation ein Story Point zur benötigten Zeit steht. Wenn wir aber ehrlich zu uns selbst sind, wer kann auf die Stunde genau definieren wie lange für eine User Story benötigt wird?
Der Vorteil von Story Points ist auch zugleich der Nachteil. Es gibt eine Entkopplung von Zeit und Umfang der geliefert wird. dies hat einerseits eine beruhigende Wirkung auf das Entwicklungsteam und sorgt andererseits bei etablierten Projektleitern für Schluckauf. Denn diese können dann nicht mehr genau definieren wann was fertig ist. Sondern bekommen die Möglichkeit selbst (wenn es bspw. der Product Owner ist und kein althergebrachter Projektleiter) zu definieren welchen Nutzen sie für ihre Anwender als nächsten haben wollen. Durch diese Priorisierung gibt es erhebliche Vorteile, es wird zuerst auf den Nutzen für die User geachtet und nicht auf das Zeitbudget.
Eine kurze Definition von Story Points
Ein Story Point ist eine Messeinheit, welche vom Scrum Team definiert und verwendet wird, welche relative Schätzungen des Aufwands zur Erfüllung der Anforderungen bemisst.