Falls ihr euch in Zukunft in der Diskussion “Story Points vs Personentage” wiederfinden solltet, zeige ich euch wie ihr euren Kollegen den Nutzen von Story Points erklären und sie davon überzeugen könnt.
Schätzen in Personentagen
Die Schätzung in Personentagen ist einer der am weitesten verbreiteten Ansätze zur Messung der Teamarbeit. Sie stützt sich auf eine Schätzung des Arbeitsaufwands, die eine Person innerhalb eines Tages erledigt. Während Personentage leicht zu verstehen sind, gibt es einige große Nachteile dieser Technik:
Zunächst entsteht die Erwartungshaltung, dass Entwickler die genaue Anzahl der geschätzten Stunden pro Sprint protokollieren. Das ist jedoch ein zweischneidiges Schwert. Wenn sie die Anzahl der Stunden überschreiten, bedeutet das automatisch, dass nicht genug Leistung erbracht wurde. Allerdings wenn sie den Sprint unter der geschätzten Anzahl von Personentagen beenden, dann stimmt etwas mit der Schätzung nicht. Wenn ein Entwickler ein Item schätzt, aber ein anderer die Aufgabe erledigt, wird die Schätzung ungültig. Die Zeit, die man benötigt, um eine Aufgabe zu erledigen, hängt vom Erfahrungsgrad und Fähigkeiten der Entwickler ab. Es entstehen unweigerlich Abstimmungsschwierigkeiten und es werden automatisch Silos aufgebaut. Je näher man die vorhandene Kapazität an die Aufwände in Personentagen angleicht, desto stabiler scheint eine Planung zu sein. Es entsteht ein Gefühl von (falscher) Sicherheit und Kontrolle. Teams unterschätzen im Allgemeinen Hindernisse, auf die sie stoßen könnten. Sie orientieren sich meist am Best-Case und planen ihre volle Kapazität aus.
Was sind denn nun Story Points?
Beginnen wir mit der Definition eines Story Points. Ein Story Point ist einfach eine willkürliche Größe, die Scrum Teams verwenden. Jedes Scrum Team kann seinen eigenen Story Point Bereich verwenden. Häufig schätzt man hierzu in einer Abwandlung der Fibonacci Reihenfolge (0,1,2,3,5,8,13,20,40,100). Um zu wissen, welche Story mit wie vielen Story Points bewertet wird, startet jedes Team mit einer oder mehreren Basis Stories. Story Points stellen den Aufwand dar, der erforderlich ist, um ein Product Backlog Item live zu schalten. Jeder Story Point repräsentiert eine normale Zeitverteilung.
Zum Beispiel: 1 Story Point könnte einen Bereich von 4-12 Stunden darstellen, 2 Story Points 10-20 Stunden und so weiter. Diese Zeitverteilung ist bei der Schätzung unbekannt. Durch die Verwendung von Basis Stories im Verhältnis zu dem, was zu schätzen ist, ist es nicht notwendig zu wissen, wie viel Zeit es tatsächliche braucht.
Schätzen mit Story Points
Zunächst muss man festhalten: Schätzen ist Zeitverschwendung. Teammitglieder verbringen Stunden damit, über Details und Kleinigkeiten zu debattieren. Selbst das Schätzen in Story Points ist eine Verschwendung. Um den Fortschritt von Projekten jedoch vorhersehbar und transparent zu machen, sollten User Stories jedoch ungefähr die gleiche Größe +/- ein Delta haben. Die Verwendung von Story Points ist eine Version dessen, was man oft als „Relative Sizing“ bezeichnet. Story-Punkte berücksichtigen bei der Schätzung oft drei verschiedene Aspekte: Komplexität, Aufwand und Zweifel.
Komplexität
ist das, was Teams „herausfinden müssen“. Sie wissen, dass sie ein Problem lösen können und haben wahrscheinlich ein gutes Gefühl dafür, wie man es angeht.
Aufwand
beschreibt Aufgaben, bei denen bekannt ist wie man sie löst.
Zweifel
entsteht bei Aufgaben, bei denen unbekannt ist, ob sie machbar sind. Teams vermuten, dass sie auf einem falschen Weg sind oder dass Technologien nicht in der Lage sind Aufgaben zu lösen.
Die meisten Stories enthalten eine Kombination aus allen drei Eigenschaften. Deshalb ist es nützlich, eine gemeinsame Sprache zu sprechen. Die endgültige Punkteschätzung ist nur eine Möglichkeit zu sagen: Wenn man all diese Faktoren berücksichtigt, denken wir, dass diese Story größer ist als die meisten der Stories, die kleiner bewertet wurden und kleiner als die Stories die größer bewertet wurden.
Warum gibt es keinen Umrechnungsfaktor zwischen Story Points und Stunden?
Story Points erlauben es dem gesamten Team eine User Story zu schätzen, auch wenn ihre individuellen Schätzungen der tatsächlichen Zeit für die Erledigung der Aufgabe unterschiedlich sind. Ausgehend von dieser Schätzung können sie sich dann darauf einigen, etwas als zwei Punkte zu schätzen, wenn jeder zustimmt, dass es doppelt so lange dauert wie die erste Geschichte. Wenn man Story Points mit Stunden gleichsetzt, können Teammitglieder dies nicht mehr tun. Wenn jemand Teammitglieder anweist, dass ein Story Point einer beliebigen Anzahl von Stunden entspricht, gehen die Vorteile der Schätzung in einer abstrakten, aber relativ sinnvollen Einheit wie Story Points verloren.
Der Vorteil einer relativen Schätzung ist, dass Teams sich schneller auf einen Wert einigen können, auch wenn verschiedene Teammitglieder den tatsächlichen zeitlichen Aufwand unterschiedlich bewerten. Auf diese Weise handelt es sich bei den Story Points immer noch um Zeit (Aufwand), aber die Zeit pro Punkt ist nicht für alle Teammitglieder gleich hoch.
Durch die Übersetzung von Story Points in Stunden profitieren Teams nicht mehr von der Geschwindigkeit der relativen Schätzung. Sie beginnen in Stunden zu arbeiten und riskieren, Verpflichtungen einzugehen. Es bietet ein falsches Gefühl der Genauigkeit, wenn Story Points einem Zeitbereich von 10-20 Stunden auf z.B. 15 Stunden reduziert werden. Es ist schwieriger, eine Einigung zu erzielen, wenn man mit Personentagen oder Stunden arbeitet.
Mehr zu Scrum findet ihr in der Serie Scrum Basics, ein Übersicht der Themen findet ihr im Artikel Scrum Basics: Alles auf einen Blick [link]