Ein Grundpfeiler von Agilität im Allgemeinen und Scrum im Speziellen ist Inspektion. In diesem Beitrag setze ich mich deshalb mit Story Points und damit einhergehend wieder mit Schätzung auseinander.
Fangen wir direkt an: Der Scrum Guide kennt weder Schätzung noch Story Points. Der einzige Hinweis auf diese Themen findet sich im Abschnitt über das Product Backlog:
[Product Backlog refinement] is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Der springende Punkt hier ist "such as [...] size". Das ist ein Beispiel oder Vorschlag und kein Muss. Der Scrum Guide lässt auch an dieser Stelle wieder mit Absicht große Lücken und viel Freiraum. Er geht weder darauf ein, was "size" bedeutet, noch wie das Team zu dieser kommt.
Die weitverbreitete Nutzung von Story Points ist somit ein möglicher Weg, um diese Lücke zu füllen.
Werfen wir zunächst einen Blick auf die Geschichte.
Ihren Ursprung haben Story Points wahrscheinlich in Extreme Programming (XP). Ron Jeffries schreibt dazu:
In XP, stories were originally estimated in time: the time it would take to implement the story. We quickly went to what we called “Ideal Days”, which was informally described as how long it would take a pair to do it if the bastards would just leave you alone. We multiplied Ideal Days by a “load factor” to convert to actual implementation time. Load factor tended to be about three: three real days to get an Ideal Day’s work done.
We spoke of our estimates in days, usually leaving “ideal” out. The result was that our stakeholders were often confused by how it could keep taking three days to get a day’s work done, or, looking at the other side of the coin, why we couldn’t do 50 “days” of work in three weeks.
So, as I recall it, we started calling our “ideal days” just “points”. So a story would be estimated at three points, which meant it would take about nine days to complete. And we really only used the points to decide how much work to take into an iteration anyway, so if we said it was about 20 points, no one really objected.
Diese Abstraktion mittels "Punkten" fand anschließend ihren Weg in die Scrum-Welt und wurde in dieser wiederum weiterentwickelt als ein zusätzliches Werkzeug von vielen.
Doch was sind sie nun genau?
Genau hier liegt ein Problem: Es gibt keine einheitliche Definition.
Eine mögliche Auslegung unter vielen ist diese:
A story point is an abstract measure of effort required to implement a user story. In simple terms, it is a number that tells the team about the difficulty level of the story. The difficulty could be related to complexities, risks, and efforts involved.
Konkret folgt diese Zahl in den meisten Fällen der modifizierten Fibonacci-Skala (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100). Das Team schätzt die Product Backlog Items relativ zueinander mithilfe dieser Zahlenfolge. Dies kann seriell geschehen, unter Zuhilfenahme von Planning Poker. Oder parallel mit Magic Estimation.
Hier halte ich mich mit Absicht sehr kurz. Zum einen gibt es mehr als genug Anleitungen im Netz zu finden. Zum anderen soll dieser Artikel das Werkzeug im Allgemeinen hinterfragen und beleuchten.
Zunächst zu den Vorteilen von relativer Schätzung mit Story Points.
In ihrer reinen theoretischen Form haben Story Points u. a. diese positiven Aspekte:
Diese Vorteile können jedoch nach eigener Erfahrung in der Realität nicht ihre volle Wirkung entfalten.
Im Folgenden gebe ich Beobachtungen wieder. Versteht das bitte nicht als absolute Aussagen. Es ist wie immer nicht alles 0 oder 1. Und ihr könnt bestimmt genauso viele gleichlautende Geschichten erzählen, wie Gegenbeispiele aufzählen.
Problem 1 mit Story Points ist in meinen Augen die fehlende, klare und von allen verstandene Definition. Treffen Devs in neuen Teams aufeinander, bringen sie ihr verschiedenen Erfahrungen und Einblicke aus anderen Umsetzungen von Scrum mit. (Was übrigens eine gute Sache ist.) Und genauso haben Scrum Master und Product Owner ihre eigene Sicht auf die Dinge. Dies erfordert dringend eine frühestmögliche Klärung gemeinsamer Grundlagen.
Auf die Frage "was schätzt ihr denn?", bekomme ich z. B. in Teams, zu denen ich neu stoße, gerne die Reflex-Antwort "Komplexität". Hier hake ich gerne nach mit der Sache mit dem Telefonbuch. Relativ zur Implementierung einer Geschäftslogik ist das Abschreiben eines Telefonbuchs weniger komplex, richtig? Dann kann das Team sehr viele Telefonbücher abschreiben, oder?
Auf eine weitere Folgefrage, wie denn das Referenz-Item aussieht, wird es dann ebenfalls still. Wie also hat ein solches Team bisher eine relative Schätzung vorgenommen, wenn es keinen Ankerpunkt gab?
Dies wird klarer, wenn man einer Schätzrunde als Beobachter beiwohnt. Die Diskussionen lassen erkennen, dass eigentlich nichts auf einer abstrakten Ebene relativ zueinander geschätzt wird, sondern mehr oder weniger offensichtlich Zeit. Was uns direkt zum nächsten Punkt bringt.
Problem 2 sind Zahlen. Sobald irgendwo ein Wert steht, werden die meisten Menschen beginnen, diesen umzuformen. Bei Ingenieur:innen, Informatiker:innen, Mathematiker:innen, Physiker:innen, Controlling, Management und Projekleiter:innen ist dies professionsbedingt sehr oft zu beobachten. Die Schätzung ist eine Zahl und mit Zahlen kann gerechnet werden, oder?
Nun ja, nein. Eigentlich sind Story Points als Ordinalskala zu verstehen. Das bedeutet, dass die Reihenfolge wichtig ist. Genauer die relative Rangordnung. Eine Story mit 3 Punkten ist größer als eine mit 2. Eine Story mit 13 Punkten ist sehr viel größer als eine mit 5 usw. Mehr Aussage steckt nicht darin.
Da jedoch eine Zahl im Raum steht, wird diese als Wert auf einer Kardinalskala betrachtet. Eine solche Skala misst quantitative Merkmale und lässt statistische Berechnungen und Vergleiche zu. Nur erfüllen weder Story Points noch Schätzungen die Voraussetzungen für solche Bedingungen.
Ich könnte jetzt sehr viel über die Herleitung dieser letzten Aussage schreiben. Das hat schon jemand für mich gemacht 😉 Ich lege euch entsprechend wärmstens die Lektüre von The conundrum about Story Points — pointless or not? ans Herz. Dieser Artikel ist jede Minute Lesezeit wert und die Literaturliste am Ende ist pures Gold.
Welche Empfehlungen und Ideen kommen nun in den Sinn?
Unter Abwägung der oben aufgeführten Vor- und Nachteile in Kombination mit meiner bisherigen Erfahrung schlage ich diese Punkte vor:
Eine Möglichkeit für die Schätzung in Buckets ist z. B. die Schätzeinheit Aufwand (nicht Zeit!) in Personentagen. Und dies auf der oben erwähnten modifizierten Fibonacci-Skala. Die Buckets beziehen sich dabei auf die Spannweite der Schätzung. Eine 5 bedeutet, dass die Umsetzung zwischen ]3 und 5] Tagen Aufwand bedeuten kann. Eine 13 steht für eine Indikation zwischen ]8 und 13] Tagen Aufwand.
Dieses Vorgehen hat den Vorteil, dass Entwicklung eingebettet ist in eine unternehmerische Realität, in der Zeit und Geld maßgeblich sind. Die Schätzung in Buckets trägt dem Rechnung, in dem es eine verständliche Einheit (Personentage) nutzt. Zudem beinhaltet die Methode durch die wachsende Größe der Buckets eine Behandlung von Komplexität, Risiko und Unsicherheit.
Die Ergebnisse sind natürlich immer noch Schätzungen und entsprechend keine festen Planungsgrößen. Auch muss dieses Vorgehen nicht überall funktionieren. Es ist ein Vorschlag und jedes Team ist anders.
Macht euch, wie bei jedem anderen Werkzeug auch, bei Story Points zunächst Gedanken darüber, ob und wofür ihr sie eigentlich braucht.
Welchen Zweck sollen sie und Schätzungen generell erfüllen? Welche Ziele verfolgen und welche Informationen brauchen Kunden, Devs, Product Owner, Projektmanager, Produktmanager, Management etc.?
Vielleicht sind Story Points darauf die richtige Antwort. Vielleicht sind sie für euch eine Behinderung und eure Aufgabe z. B. als Scrum Master ist es, für die Beseitigung von Hindernissen zu sorgen. Hinterfragt bitte stets eure Handlungen, seid ehrlich mit euch, nutzt nur sinnvolles und glaubt nicht blind irgendwelchen Mythen.
Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.