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

132

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?

Louis Rhys
quelle
16
warum nimmst du an, dass der Menschentag konkreter ist als der Handlungspunkt, nicht wahr?
Ryathal
4
Ist es einfacher zu erklären, dass Ihre Schätzung von 5 Manntagen 1 Monat in Anspruch nimmt, da Ihre Geschwindigkeit 0,25 Manntage / Kalendertag beträgt?
Patrick
3
@ Izkata, das ist nur wahr, wenn Sie Geschwindigkeit immer genau 1 ist
Patrick
4
@Patrick Wenn Manntage (siehe Mannstunden auf Wikipedia), gibt es kein Konzept der Geschwindigkeit. Das ist eine agile Sache.
Izkata
3
Das Interessante ist, dass, sobald sich die Geschwindigkeit stabilisiert, Story Points in der Regel mit einer bestimmten Anzahl von Stunden oder Tagen identifiziert werden. ZB 1 Story Point = 1 Tag. Wenn ich denke, dass es 2 Tage dauern wird, schätze ich 2 Story-Punkte.
Giorgio

Antworten:

126

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.

Erik Dietrich
quelle
28
+1 für den Fokus auf Komplexität , nicht auf Zeit. Wenn Sie genug Sprints hinter sich haben, können Sie problemlos in rauhe Stunden übersetzen. Ich fand heraus, dass die Variabilität zwischen den Geschichten im Laufe der Zeit verwaschen wird.
Kristo
14
Also wirklich, Komplexität Punkte könnte ein klarer Begriff als Geschichte Punkte sein, und jede Aufgabe mit zu vielen Komplexität Punkte ist zu komplex und wahrscheinlich beinhaltet zu viele Risiken und Unbekannten mit allen auf einmal zu behandeln. Komplexität hat exponentielle Kosten, und der arme Kerl, der mit dieser Aufgabe feststeckt, wird ein Loch graben, das so tief ist, dass er wochen- oder monatelang nicht mehr gesehen wird. Vereinfachen Sie die Aufgabe, indem Sie zuerst die komplexe Aufgabe verstehen und sie in kleinere Aufgaben mit weniger Risiko und besser verständlicher Komplexität aufteilen.
Supr 10.01.13
4
Zeit und Kosten sind Effekte, Komplexität ist die Ursache, und Sie können die Zeit nicht verstehen, ohne die Komplexität zu verstehen.
Supr 10.01.13
8
Handlungspunkte = Komplexitätspunkte - 2 Silben. :-D
Kristo
5
Hat jemand jemals darüber nachgedacht, Story Points "Casting-Kosten" zu nennen? => Sonderling
Aaron Gibralter
59

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.

Kristo
quelle
Wir verwenden dieselbe Methode und unser Planungsdeck hat höhere Zahlen, aber wir haben eine 20 definiert, was bedeutet, dass es aufgeteilt oder besser definiert werden muss. Für uns ist eine 13 unsere größte Aufgabe, und normalerweise dauern diese Aufgaben bis zu einer Woche.
Bill Leeper
"Der andere Nebeneffekt war, dass alles, was mit 13 bewertet wurde, wahrscheinlich unzureichende Informationen hatte und weiter aufgeschlüsselt werden musste." Und ich nehme an, wenn es weiter zerlegt wird, wird es in äquivalente Fibonacci-Teile zerlegt?
Joe Z.
@ JoeZeng, ja, diese wurden oft 8 + 5 oder 5 + 5 + 3. Es ist jedoch eine abstrakte Messung. Wenn die neuen Geschichten nah genug sind, habe ich mir keine großen Sorgen gemacht. Normalerweise konnte das Team aus einer 13 eine Zwei-Acht oder eine Drei-Fünf machen, aber drei Acht bedeuteten, dass ich ein klärendes Gespräch mit den Stakeholdern führen musste. Im Idealfall hatten wir weit genug im Voraus geschätzt, dass sich dies nicht auf den aktuellen Sprint auswirken würde.
Kristo
1
Nicht unbedingt. Wir haben angenommen, dass Geschichten 5 Punkte betragen, und eine detailliertere, aufgeschlüsselte Summe liegt im Bereich von 15 Punkten. Es passiert.
ashes999
24

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.

Carson63000
quelle
13
Das ist nicht mal so zynisch. Es ist das Prinzip "schnell oder billig oder gut". Ich kann Ihnen eine meist stabile, meist funktionierende Version von FizzBuzz geben, die Ihnen innerhalb weniger Minuten das gibt, was Sie im Allgemeinen wollen. Wenn Sie jedoch Benutzerinteraktion wünschen, dauert dies länger und wenn Sie Regressionstests wünschen, dauert dies länger Wenn Sie nicht möchten, dass es beim Drücken von MAX_INT fehlschlägt, dauert dies länger. Sagen Sie mir, dass ich die Geschwindigkeit priorisieren soll, und ich beginne, die Anforderungen zu löschen. Sagen Sie mir, dass ich alles andere priorisieren soll, und ich werde die ganze Zeit verwenden, die mir gegeben wird.
Deworde
17

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.

Bill Leeper
quelle
13

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
vaughandroid
quelle
Zu Punkt 2: Wie löst Story Point das? Sie schätzen eine Geschichte als 4 Geschichtenpunkte. Sie geben es einem schnelleren Programmierer und es dauert 4 Tage. Sie geben es einem langsamen Programmierer und es dauert 8 Tage. Es scheint mir, dass das Problem nicht gelöst ist, sondern nur umgezogen.
Giorgio
In Bezug auf Punkt 1. Die Idee ist, dass wenn das Team mit den für das Projekt benötigten Technologien vertraut wird, ihre Geschwindigkeit zunimmt und die relative Größe der in Story-Punkten gemessenen Storys gleich bleibt. Was aber, wenn zwei User Stories unterschiedliche Kenntnisse erfordern? Sie haben beispielsweise eine Front-End-User-Story in Javascript / HTML und eine Back-End-User-Story in Java. Wenn das Team mehr über Javascript, HTML und Java erfährt, stellt es fest, dass der Front-End-Teil viel einfacher ist als der Back-End-Teil und die relativen Schätzungen der Geschichten erneut falsch sind.
Giorgio
@ Giorgio Re. Punkt 2: Ihr schnellerer Programmierer hat eine Arbeitsrate von 1 Story Point / Tag und Ihr langsamerer Programmierer hat eine Arbeitsrate von 0,5 Story Points / Tag. Wenn Sie es in Stunden tun, wird sich entweder Ihr schnellerer Programmierer selbst zu Tode arbeiten, oder Ihr langsamerer Programmierer muss entlassen werden. Die Antwort von Bill Leeper macht diesen Punkt sehr gut.
Vaughandroid
1
Re. Punkt 1: Für mein Geld haben Sie zwei Teams, wenn Sie über zwei verschiedene Technologien und zwei verschiedene Bereiche des Produkts sprechen.
Vaughandroid
Weitere Re. Punkt 2: User Stories werden vom Team entwickelt , nicht von einzelnen Entwicklern. Es ist die Arbeitsrate des Teams, die den wichtigen Teil ausmacht. Denken Sie daran, dass Sie beim Implementieren von User Stories diese zuerst in Aufgaben aufteilen sollten. Gib dem schnelleren Entwickler mehr Aufgaben!
Vaughandroid
6

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).

PhD
quelle
Die nächste Fibonacci-Nummer ist 21, nicht 20.
Joe Z.
4
21 oder 20 spielen bei der Schätzung keine Rolle. SPs runden die nächste Fibonacci-Zahl ab, um das Gefühl falscher Präzision zu beseitigen. Die nächste Zahl in der Folge ist nicht 34, sondern 40 (Doppelte von 20) und dann 100. Die Zahlen stehen für 'Unsicherheit' in der Komplexität und nicht für Präzision. Es ist nur eine Annäherung.
PhD
1
Das stimmt, ich habe nur Nissen gepflückt (und Spaß gemacht).
Joe Z.
1
@PhD: "SP-Schätzungen verfallen nicht, dh in einigen Monaten wird eine 5-Punkte-Geschichte 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." implizit davon ausgegangen, dass das Team seine Fähigkeiten in allen Bereichen des Projekts einheitlich verbessern wird. Ich verstehe nicht, warum dies immer so sein sollte: Einige Teile eines Projekts (und die dafür erforderlichen Technologien) könnten sich als schwieriger herausstellen als andere, so dass die anfängliche Schätzung der relativen Komplexität von Story Points ungültig wird.
Giorgio
3

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.

Uooo
quelle
3
"Warum? Weil die Leistung Ihres Teams gestiegen ist.": Eine alternative Erklärung ist, dass das Team nach einer Weile beginnt, genauere / realistischere Zeitschätzungen vorzunehmen (da es in früheren Sprints einige Aufgaben zu spät hatte, beginnt es, mehr Zeit zuzuweisen, wenn Geschichten für spätere Sprints schätzen).
Giorgio
2

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.

Tormod
quelle
0

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.

Grumpasaurus
quelle
0

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.

Sklivvz
quelle
0

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 ... "

Scott Barnes
quelle
-1

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.

David M
quelle
1
Dies muss die Frage nicht unbedingt beantworten. Stattdessen wird lediglich eine Buchreferenz bereitgestellt. Sie können Ihre Antwort stärken, indem Sie eine Zusammenfassung der Vor- und Nachteile bereitstellen.
-1

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.

Amp Tanawat
quelle
-1

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.

Vadim
quelle
1
"Wenn Sie in einer nebulösen Zeit wie Story Points oder Shirt Sizes schätzen, vermeiden Sie diese Gefahr.": Nicht wirklich: Wenn mir für einen zweiwöchigen Sprint zwei User Stories für insgesamt 10 Story Points zugewiesen wurden, kann ich die nehmen ganze zwei Wochen und stellen Sie die Geschwindigkeit auf 5 Story Points pro Woche. Ich denke, die Steigerung der Produktivität hat mehr mit der Motivation des Teams und den Arbeitsbedingungen zu tun als mit der Maßeinheit für die Komplexität der Aufgaben.
Giorgio
Ich bezog mich nicht auf die Steigerung der Produktivität, sondern eher auf die Tatsache, dass eine Schätzung für eine Story auf 3 Tage hinausläuft. Es ist viel wahrscheinlicher, dass ein Entwickler 3 oder mehr Tage benötigt, um es fertigzustellen, als unter die Schätzung zu kommen.
Vadim
Gibt es gute Beweise für das Parkinson-Gesetz? Die Wikipedia-Seite scheint keine zu erwähnen.
BDSL
-2

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.

ecoGreen
quelle
1
Wir ordnen Dinge nicht basierend auf der Größe zu, sondern verwenden den Arbeitsspeicher, um diese als "Schemata" zu behandeln, nach denen gearbeitet werden soll. Ein bisschen wie unser Gehirn hat eine kleine Menge an RAM, die, wenn wir kleine erkennbare Muster in (Fibonacci, A000079, T-Shirt-Größen usw.) einspeisen, unsere intrinsischen kognitiven Kräfte ansprechen können, um dann bei der Projektion in diesem Fall zu helfen - eine Antwort. Das ist wirklich ein "relatives Prognosemodell".
Scott Barnes