Warum verwenden wir Story Points anstelle von Manntagen bei der Schätzung von User Stories?

In agilen Methoden (z. B. SCRUM) wird die Komplexität / der Aufwand für User Storys in Story Points gemessen. Story-Punkte werden verwendet, um zu berechnen, wie viele User-Storys ein Team in einer Iteration aufnehmen kann.

Was ist der Vorteil der Einführung eines abstrakten Konzepts (Story Points), bei dem wir nur eine konkrete Messung wie geschätzte Personentage verwenden können? Wir können auch die Geschwindigkeit berechnen, die Abdeckung einer Iteration abschätzen usw., indem wir geschätzte Manntage verwenden.

Im Gegensatz dazu sind Story Points schwieriger zu verwenden (weil das Konzept abstrakt ist) und auch den Stakeholdern schwerer zu erklären. Welchen Vorteil bietet es?

Ich denke, einer der Hauptvorteile ist, dass Menschen und Entwickler tatsächlich ziemlich schlecht darin sind, die Zeit einzuschätzen. Denken Sie auch an die Art der Entwicklung - es ist keine lineare Entwicklung von Anfang bis Ende. Oft heißt es: "Schreiben Sie 90% des Codes in 10 Minuten und reißen Sie sich dann 17 Stunden lang das Debuggen aus." Das ist im Sinne des Timings der Uhr ziemlich schwer abzuschätzen.

Durch die Verwendung einer Abstraktion wird jedoch der Fokus auf die tatsächliche Zeit in Stunden oder Tagen verlagert. Stattdessen wird der Fokus auf die Beschreibung des relativen Aufwands und der Komplexität einer Aufgabe im Vergleich zu anderen Aufgaben gelegt. Menschen / Entwickler sind besser darin. Und wenn Sie erst einmal mit diesen Punktschätzungen und einigen tatsächlichen Fortschritten zufrieden sind, können Sie beginnen, die Zeit empirischer zu betrachten.

Ich vermute, dass es auch einen Beobachter-Effekt gibt, der bei Zeitschätzungen auftritt, der bei Punktschätzungen nicht auftritt. Beispielsweise wird der Anreiz, eine Schätzung vorzunehmen und weit vorzeitig zu liefern, in einem punktbasierten System durch Indirektion stummgeschaltet.

Wenn Sie Fibonacci-Zahlen (oder ähnliches) verwenden, wird die Anzahl der Optionen beim Schätzen einer Geschichte begrenzt. Ich habe mit einer Gruppe zusammengearbeitet, die nur niedrige Zahlen verwendet hat: 1, 2, 3, 5, 8 und 13. Wir hatten eine Referenzgeschichte, die eine 5 war. Auf diese Weise konnten wir bei Planning Poker schnell Entscheidungen über die Komplexität einer Geschichte treffen . Der andere Nebeneffekt war, dass alles, was mit 13 bewertet wurde, wahrscheinlich unzureichende Informationen aufwies und weiter aufgeschlüsselt werden musste. Ich bezweifle ernsthaft, dass es so einfach und unkompliziert gewesen wäre, wenn wir Rohstunden verwendet hätten.

Ihr Product Owner spricht die Sprache Ihrer Stakeholder und sollte in der Lage sein, nach Bedarf zwischen Story Points und Arbeitsstunden (oder anderen Einheiten) zu übersetzen. Während meiner Zeit als PO hatte ich einige harte Daten, die 1 Story Point = 4 Mannstunden waren, aber offensichtlich ist jedes Team anders.

Bearbeiten:

Mit dem Wissen, dass 1 Punkt = 4 Stunden ist, könnten Sie theoretisch Ihr Planning Poker-Deck auf 4, 8, 12, 20, 32 und 52 ändern. Diese Zahlen sind jedoch schwieriger zu handhaben. Ich denke, ich würde die Werte mental auf etwas Einfaches zurückführen, z. B. "weniger als einen Tag", "mehr als eine Woche" usw. Und wenn ich das tun werde, könnte ich genauso gut bei der abstrakten Einheit bleiben -lose Handlungspunkte.

Es soll ermöglichen, dass die Schätzung mit der Zeit besser wird, ohne dass alle Schätzer ihre Schätzung anpassen müssen.

Anstatt dass jeder, der an der Schätzung beteiligt ist, denken muss: "OK ... sieht aus wie 2 Manntage ... aber im letzten Sprint haben wir alles unterschätzt, vielleicht sind es also wirklich 2,5 Manntage. Oder 3?", Machen sie so weiter wie immer. "5 Geschichtenpunkte!"

Anschließend passen Sie Ihre Schätzung an, wie viele Story-Punkte das Team in einem Sprint erreichen kann, basierend auf den tatsächlich gemessenen Erfolgen in früheren Sprints. "Wir haben vorher 90-110 Story Points pro Sprint gemacht!"

Ich würde sagen, die Theorie dahinter ist, dass Entwickler die relative Komplexität verschiedener Entwickleraufgaben besser einschätzen können als die absoluten . Vor allem, wenn mehrere Personen eine Aufgabe schätzen, die von einem von ihnen erledigt werden könnte (und nicht jeder mit der gleichen Geschwindigkeit arbeitet wie alle anderen).

Zynische Alternative: Ich habe gesehen, dass Entwickler nie unter Zeitvorgaben reinkommen. Wenn etwas länger dauert als angenommen, sind Sie durchgegangen. Aber wenn etwas weniger Zeit in Anspruch nimmt als angenommen, können Entwickler damit experimentieren, es vergolden oder einfach nur langsamer machen, da sie einen bequemen Auftrag erhalten haben. Das Herausnehmen der realen Zeiteinheiten aus einer Schätzung kann diese Tendenzen eindämmen. Beende die zynische Alternative.

Manntage oder Mannstunden sind sozusagen konkret. Wenn also eine Aufgabe auf 5 Stunden geschätzt wird und 6 dauert, ist sie jetzt eine späte Aufgabe.

Wenn Sie eine Geschichte haben, die aus 3 Punkten besteht und 6 Stunden dauert, hat sie 6 Stunden gedauert, es ist nicht spät, es hat nur 6 Stunden gedauert. Die Geschwindigkeitsmessung ist eher ein Faktor dafür, wie viele dieser Punkte Sie im Sprint erzielen, und diese Zahl kann schwanken, da sie nicht konkret ist. Sie messen auch nicht jede Aufgabe, sondern die Summe aller Aufgaben. Wenn Sie Stunden für jede Aufgabe haben, ist die Versuchung da, jede Aufgabe zu messen. In diesem Fall hat der Sprint keinen Vorteil, wenn er unter der vorgegebenen Zeit beendet wird. Dies hat zur Folge, dass der Sprint über die Zeit einer bestimmten Aufgabe beendet wird.

Es kann ein Übergang zum Denken in Punkten sein. Ein Ort, an dem ich gearbeitet habe, bevor wir agile T-Shirt-Größen eingeführt haben, nur um eine Vorstellung vom Aufwand zu bekommen. Punkte sind nur eine Erweiterung davon.

Das heißt nicht, dass es keine Kontroversen oder eine willkürliche Zuordnung zu den Punkten gibt. Wir haben Mitglieder unseres Teams, die fast immer die niedrigste Zahl wählen und sich beschweren, wenn sie denken, dass eine Aufgabe eine 1 ist und wir denken, dass es eine 3 ist, die wir unter Punktinflation leiden.

Die Abstraktion ist eine Art Punkt. Die Verwendung des "Manntages" als Maß hat eine Reihe von Gefahren, darunter:

1. Wenn das Team nicht mit der Technologie vertraut ist, die es einsetzen wird, kann es sehr schwierig sein, in Echtzeit Schätzungen darüber abzugeben, wie lange eine Aufgabe dauern könnte. Es ist viel wahrscheinlicher, dass sie gute relative Schätzungen abgeben können - z. B. "Aufgabe A wird wahrscheinlich doppelt so lange dauern wie Aufgabe B".
2. Verschiedene Leute arbeiten mit unterschiedlichen Raten! Wenn Sie "Manntage" verwenden, müssen Sie die geschätzte Zeit ändern, wenn eine Aufgabe von einem Entwickler an einen anderen übergeben wird. Wer definiert eigentlich, wie viel Arbeit ein „Manntag“ ausmacht?

Wenn Sie die Manntage schätzen möchten, ist dies eine einfache Berechnung:

user points in story / average user points per developer per day = estimated man days

Wie bereits erwähnt, sind Story Points ein relatives Maß für die Komplexität. Man kann Potenzen von 2 Reihen (1,2,4,8,16 ...) oder eine Fibonacci-Skala (1,2,3,5,8,13,20 ...) zur Abschätzung verwenden. Als engagierte Entwickler sind sie ziemlich geschickt darin, so etwas zu sagen:

Feature A ist fast doppelt so hart wie Feature B

Es ist jedoch sehr schwer zu sagen, wie lange diese Funktion für die Implementierung benötigt. Sie lassen dies durch die Geschwindigkeit ausbalancieren. Wenn also etwas als 5 geschätzt wurde, sich aber als 13 herausstellte, würde eine langsamere Geschwindigkeit das für die Iteration normalisieren (oder Sie könnten es erneut schätzen).

Jetzt gibt es eine andere Alternative: Es heißt "ideale Tage" (manche sind ähnlich wie Manntage, aber ich bin mir nicht sicher, ob Sie das gemeint haben) und ich kenne einige Teams, die das vorziehen. Ideale Tage sind zu interpretieren als:

Wenn das alles ist, was ich nach meinem Amtsantritt mache und nur die notwendigen Pausen einlege, keine Unterbrechungen habe und alles habe, was ich brauche, um die Story umzusetzen, dh keine peripheren Aktivitäten wie Besprechungen, Antworten auf Mails usw.,

Mike Cohn, einer der vielen bekannten agilen Evangelisten, bietet den folgenden Vergleich zwischen Story-Punkten und idealen Tagen

Story-Punkte

• Hilft dabei, funktionsübergreifendes Verhalten voranzutreiben, dh Teams schätzen die gesamte Komplexität der Implementierung von der Benutzeroberfläche bis zur Datenbank und zurück.
• SP-Schätzungen verfallen nicht, dh in einigen Monaten wird eine 5-Punkte-Story wahrscheinlich immer noch 5 Punkte enthalten, aber eine ideale Tagesschätzung kann sich in Abhängigkeit von den erworbenen Entwicklungsfähigkeiten / -geschwindigkeiten des jeweiligen Programmierers ändern
• SP sind ein reines Maß für die Größe, dh sie geben nur die Größe für die Komplexität wieder. Zeitraum. Keine Dauer usw., es geworfen. Das ist die Aufgabe der Geschwindigkeit. Nicht so bei idealen Tagen. Tatsächlich besteht bei idealen Tagen die Tendenz, sie mit Kalendertagen zu verwechseln. Halten Sie es abstrakt, während SPs die Versuchung bekämpft, sich mit der Realität zu vergleichen. Nur ein Maß für die Größe. Kein Unsinn.
• Ist in der Regel schneller als ideale Tage. Für die ersten paar Geschichten mag es schwierig sein, aber sobald Sie den Dreh raus haben, ist es schneller.
• Verschiedene Entwickler können ihre ideale Tagesschätzung für die Fertigstellung einer Story unterschiedlich interpretieren. Ich könnte dasselbe in 3 und Sie könnten in 5. SPs sind mehr oder weniger einheitlich auf der ganzen Linie. Sie gleichen das Spielfeld sozusagen aus.

Ideale Tage

• Einfacher zu erklären außerhalb des Teams; aus offensichtlichen Gründen :)
• Einfacher zu schätzen, zuerst wie oben erwähnt. Aber sobald Sie den Dreh raus haben, wird es natürlich

Nun liegt es an der Mannschaft, welche zu wählen ist. Wie die meisten Antworten hier und meine persönlichen Erfahrungen zeigen, bevorzuge ich Story Points. Ideale Tage haben nicht wirklich einen großen Vorteil gegenüber SPs (und Mike Cohn befürwortet SP zusammen mit vielen anderen agilen Evangelisten).

Story Points helfen Ihnen auch dabei, die Leistungssteigerung des Teams im Laufe der Zeit zu messen. Darüber hinaus müssen Sie nicht alles neu einschätzen, wenn sich die Leistung verbessert.

Nehmen Sie dieses Beispiel, das Manntage verwendet:

Das Team schätzt verschiedene Aufgaben mit Manntagen. Es funktioniert eine Weile, aber nach einiger Zeit sieht man, dass das Team mit vielen Aufgaben schneller fertig ist als ursprünglich gedacht. Also schätzt das Team die Aufgaben neu. Es funktioniert eine Weile und nach einiger Zeit sieht man wieder dasselbe: Das Team ist mit vielen Aufgaben wieder schneller fertig. Also schätzt du noch einmal und diese Geschichte wiederholt sich noch einmal und noch einmal und noch einmal ...

Warum? Weil die Leistung Ihres Teams gestiegen ist. Aber du weißt es nicht.

Das gleiche Beispiel mit Handlungspunkten:

Das Team schätzt die Größe der User Stories. Nach einigen Sprints sieht man, dass das Team ungefähr 60 Story Points pro Sprint schaffen kann. Später sehen Sie, dass das Team mehr als 60 Story-Punkte erreicht hat, vielleicht 70. Und das Team macht so weiter und zieht weitere User-Storys für die nächsten Sprints und liefert sie.

Warum? Weil die Leistung gestiegen ist. Und du kannst es messen. Und Sie müssen nicht alles neu einschätzen, nachdem die Leistung Ihres Teams gestiegen ist.

Erstens sind die Menschen bei relativen Schätzungen besser als bei absoluten Schätzungen. Die Babylonier, die die relative Helligkeit von Sternen abbilden und bewerten, sind ein gutes Beispiel. Sie haben die absoluten Zahlen nicht richtig verstanden, aber die Reihenfolge war auch bei sehr ähnlichen Intensitäten meist genau richtig.

Der zweite Vorteil ist, dass ein Hauptgrund für diese Übung darin besteht, die Konversation voranzutreiben. Wenn Sie an bestimmten Tagen mit der Diskussion beginnen, kann die Konversation schnell zum Erliegen kommen.

Wie Napoleon sagte: Der Plan ist wertlos, Planung ist von unschätzbarem Wert.

Drittens muss der Projektmanager nicht alle Schätzungen bearbeiten, nur weil sich herausstellt, dass die Schätzungen um einen Faktor von z. B. 130% gesunken sind.

Story Points spiegeln die Komplexität des Problems wider und spiegeln daher das Vertrauen (oder Risiko) in die Genauigkeit der Schätzung wider.

Eine Story mit einem hohen Story Point sagt mir, dass mit der User Story viel los ist, was nicht konkret ist.

Die Idee ist zu sehen, was eine gute Balance zwischen verschiedenen Story-Punkten ist. Wenn mir ein Iterationsplan mit Storys mit allen hohen Story-Punkten angezeigt wird, kann ich nicht sicher sein, dass die Iteration wie erwartet ausgeführt wird und dass wir andere Storys für die Iteration untersuchen oder anfangen müssen, Storys aufzuschlüsseln.

Bei der Kommunikation mit einem Manager oder Product Owner bedeuten hohe Story Points, dass es äußerst unklar ist, wann sie eine bestimmte Funktion erhalten. Eine der Lösungen besteht darin, die Story aufzuschlüsseln, und hoffentlich haben Sie eine Kombination aus niedrigen und hohen Story-Punkten, mit denen Sie dem Product Owner iterativ den Fortschritt demonstrieren können.

Manntage schätzen die Zeit, die benötigt wird, um etwas zu tun. Sie werden am besten verwendet, wenn die von Ihnen geschätzten Elemente sehr genau und messbar sind. Bestimmte, bekannte, wiederholbare Aufgaben sind in Manntagen abschätzbar.

Wenn beispielsweise ein Verkäufer durchschnittlich 20 Kundenanrufe pro Tag tätigen kann, können wir berechnen, wie viel Zeit jeder Anruf benötigt, und daraus ableiten, wie viele Manntage für 1000 Anrufe erforderlich sind.

In diesem Beispiel kann man statistisch konkret über die Medianlänge eines Anrufs nachdenken, da angenommen werden kann, dass alle Anrufe effektiv dasselbe sind.

Story-Punkte bestimmen, welche Kombination von Storys in einer Iteration erstellt werden kann. Sie werden verwendet, um heterogene Ziele mit unscharfen Grenzen zu kombinieren und zu messen, wie viele Ziele in einem festgelegten Zeitrahmen erreicht werden können. Sie schätzen die Komplexität von Arbeitsblöcken im Vergleich zueinander ein , um sie zu addieren.

Zum Beispiel hat Ihr Team 5 Storys für insgesamt 23 Punkte in Iteration 1 und 8 Storys für 20 Punkte in Iteration 2 entwickelt. Daraus können Sie abschätzen, dass Ihr Team in Iteration 2 einige Storys mit insgesamt etwa 20 Punkten erstellt in Iteration 3.

Beachten Sie, dass wir nicht die Größe eines Punktes bestimmen müssen und insbesondere nicht davon auszugehen ist, dass jede Geschichte derselben Größe die gleiche Zeit in Anspruch nimmt, um entwickelt zu werden! Wir arbeiten nur an Summen und Punkten pro Iteration. Ich habe nicht einmal erwähnt, wie lange die Iteration dauert.

Wenn Sie zu einem Menschen auf der Straße gehen und fragen: "Wie groß war ein T-Rex?" Die Antworten würden schwanken, obwohl die Mehrheit der Menschen weiß, was ein T-Rex ist, wie groß er war, aber niemand weiß es wirklich genau - denn wir haben KEINE relative Skala zur Basislinie.

Das ist das kognitive Verhalten, das Sie mit Prognosen und vielen Methoden herausfinden möchten. Drehen Sie die Zyklen mit " Ich habe es! .. Ich habe das Geheimnis einer genauen Prognose! ". Schlangenöl für die Massen. Wenn Sie tatsächlich eine Prognose abgeben, sagen Sie laut: " Ich ERLAUBE x Tage / Stunden / Punkte, damit diese abgeschlossen werden " - in gewissem Sinne wird eine "Zeitbox" für die Durchführung dieses Ereignisses erstellt.

Für mich verschiebt Points nur die Grenzen, am Ende des Tages, es sei denn, Sie gehören zu einem Team, das gerne sagt: " * Wir haben 3 Wochen pro Sprint und Daumenlutschen ... ich denke, wir sollten schießen In diesem Zyklus sind noch 30 Punkte zu erledigen ! Wer ist bei mir ? ..als realistisch Sie nur ein Budget festlegen und das ist es. Du siehst dir dann auch rückblickend die Arbeit an, die mit einem Gefühl von "heiligem Mist" abgeschlossen wurde. Wir haben 33 Punkte in diesem Sprint gemacht, das war ziemlich cool. Daran kann man nicht viel ändern. Sie können die Geschwindigkeit verwenden, um während des Sprints zu bestimmen, wie viel Sie für Ihr Budget ausgeben, indem Sie laut fragen: " Haben wir schon 15 Punkte erreicht? Werden wir?""aber hier besteht die Gefahr, dass Sie jetzt Velocity verwenden, um die Produktivität zu messen, nicht die Kapazität, die nach meinem Verständnis das Reactive Release Management (Story Points) in den Kopf stößt.

Das Punktesystem ist fast zu clever, um nicht zu bemerken, dass Sie immer noch relative Zeit mit der Gleichung verknüpfen, von Ihren vereinbarten "Sprint-Zyklen" bis zu Ihren täglichen Stand-ups, in denen Sie eine verborgene Regel in Bezug auf Dauer + Komplexität anwenden = " Max dauert zu lange bei dieser aufgabe "angeborenes gut gefühl team code rot moment?

Das menschliche Gehirn kann nichts vorhersagen, weil es eine Menge Arbeitsgedächtnis mit lang- / kurzfristigem Rückruf einschließt. Es ist also so, als würde man einen angehenden Mathematikstudenten bitten, Bruchteile in seinem Kopf zu machen, nicht auf dem Papier Überprüfen Sie Prognosen ständig in relativer Zeit (z. B. hört der Geologe niemals mit der Prognosemodellierung auf, bis dieser Kubikmeter aus dem Boden gegraben und dann "fertig" ist).

Ich würde sagen, das Punktesystem funktioniert, wenn Sie keine Prognose abgeben . Sie stimmen einem Teil der Arbeit zu, der auf einem Sub-Chunking-Algorithmus basiert, aber das ist wirklich Ihr bestmöglicher Ansatz für Prognosen. Tatsächlich würde Ihr Release-Management nach natürlichen Brüchen in der "Backlog" -Warteschlange suchen, die zu den Themen passen (dh in Silverlight würden wir Produktmanager warten, bis sie ihren Backlog vervollständigt und die von uns ursprünglich festgelegten Themen zusammengesetzt haben. Wir Ich wusste nie, was das Engineering-Team speziell tat. Wir hatten nur einen Grundriss. Dann nahmen wir diese Arbeit und bauten unser Marketing-Event darauf auf (Microsoft Mix).

Wenn Sie anfangen, Geschwindigkeitserwartungen in Sprint-Zyklen, die auf Geschwindigkeit + Zeit beruhen, zu blockieren, können Sie wieder Schätzungen vorhersagen, nur diesmal sind Sie schlechter dran, weil Sie das "es hängt vom Spiel ab" spielen ... was noch wichtiger ist, Sie töten auch Potenzial für Teamwachstum / Karrierewachstum.

Die Steuer, die Sie für Points vs Time zahlen, setzt sich aus Punkten zusammen, die Sie benötigen, um nach alternativen Messformeln zu suchen, mit denen Sie die Entwicklung / das Mentoring von Onjob-Fähigkeiten oder das Verhalten von Entwicklern verfolgen können.

Da Sie immer noch einen "Median-Entwickler" als Ihre ideale Person betrachten müssen, mit der Sie Fähigkeiten / Anstrengungen verbinden können, können Sie andere Entwickler mit dieser Person als Grundlage nehmen, um zu bestimmen, wie sie an ihrem kontinuierlichen Wachstum in Ihrem Team gemessen werden. Es werden auch Situationen hervorgehoben, in denen die "schnellen" Entwickler den größten Teil des Wassers transportieren, sich jedoch langweilen oder sogar länger arbeiten und keine Anerkennung / Belohnung aufgrund konkurrierender Fristen usw. erhalten um schlechte Gerüche im Team zu entdecken, wie in "diese Person kämpft, lässt uns helfen"

Als nächstes folgen die "Übertrag" -Geschichten, Geschichten, die nicht in diesen Sprintzyklus zerlegt werden, sondern dann in den nächsten Sprintzyklus übergehen. Was dann leicht zu einem Anstoßeffekt führen kann, wenn Sie die Zeit berücksichtigen, aber in dem Moment, in dem Sie die relative Zeit berücksichtigen, sind Sie wieder auf "zeitbasierte Vorhersage / Schätzung" zurückgegangen, und wieder ist das Punktesystem gerecht das Wasser trüben.

Wenn du Punkte gehst, ignorierst du die Zeit komplett und ich meine, genau in dem Moment, in dem du die Zeit einschleichen lässt, spielst du die Idee / Methodik.

Nachdem auf der ganzen Welt als Evangelist reiste, sah ich viele Teams ihre Hand schwören auf , was sie lieb und teuer ist, dass sie die Agile Forecast Code geknackt haben ... aber ich meine Zunge immer geklickt haben, lächelte und ging mit dem Gedanken " ja ... das hättest du beinahe getan, aber diese Herrin nennen wir "Zeit" ... sie ist nur grausam ... "

Mike Cohns Buch "Agiles Schätzen und Planen" beschreibt die Vor- und Nachteile des Schätzens mit "idealen Tagen" oder Story Points. Die schnelle Antwort auf Ihre Frage lautet also, dass Sie nicht mit Story Points schätzen müssen. Wenn es natürlicher ist, in idealen Tagen zu schätzen, fahren Sie fort.

Ich denke, die Story Point-Methode hat mindestens zwei wichtige Vorteile gegenüber der Man-Day-Methode: Erstens ist es in SP einfacher zu schätzen. SP ist relativ und menschlich wie wir ist besser in relativer als in absoluter Schätzung wie Man-Day-Methode.

Zweitens, wenn Sie in SP schätzen, erhalten Sie "Team SP" und nicht "Individual Manday". Wenn Sie "Wie lange wird diese Aufgabe dauern?" Fragen, kann Ihnen der Senior-Entwickler 1 Tag, aber 5 Tage für einen Junior geben. Das ist der Menschentag, bis zu dem diese Aufgabe erledigt ist. Wenn der Eigentümer gezwungen ist, zu wechseln (und das wird es!), Müssen Sie alles neu planen. Mit SP ist es immer noch derselbe, der die Aufgabe übernimmt.

Ich bin überrascht, dass noch niemand das Parkinson-Gesetz erwähnt hat.

Die Arbeiten werden erweitert, um die für ihre Fertigstellung zur Verfügung stehende Zeit auszufüllen.

Grundsätzlich nehmen sich Entwickler bei der Schätzung einer Zeiteinheit für große Aufgaben in der Regel die Zeit, die sie für die Fertigstellung oder Überprüfung veranschlagt haben. Wenn Sie in einer nebulösen Zeit wie Story Points oder Shirt Sizes schätzen, vermeiden Sie diese Gefahr.

Die Geschichtspunktschätzung folgt der Fibonacci-Reihe 1,2,3,5,8,13,21 ...

Ein menschliches Gehirn kann Dinge leicht anhand ihrer Größe abbilden. Beispiel: Wir haben eine Post-It-Karte und weisen ihr einen Story-Punkt 2 zu. Die Größe von drei Post-It-Karten würde 2 * 3 = 6 Story-Punkte bedeuten.

Story Point 6 liegt zwischen den Fibonacci-Serien 5 und 8, wobei 5 die engere Nummer ist und daher der Storypoint 5 wäre.