Ändern sich die Story Point-Größen für sich wiederholende Aufgaben, nachdem Sie die Aufgabe automatisiert haben?

Hier ist die Scrum-Situation:

1. Eine bestimmte Aufgabe (Implementieren einer mit Back-End-Daten gefüllten Datentabelle) ist eine häufige Geschichte
2. Die Tabellen haben häufig ähnliche, aber benutzerdefinierte Funktionen
3. Die Implementierung jeder Tabelle dauert ungefähr eine Woche (8 Story-Punkte).
4. Schließlich investiert das Team 4 Wochen, um eine wiederverwendbare Komponente zu erstellen
5. Jetzt ist das Erstellen einer neuen Tabelle fast augenblicklich

Meine Frage: Ist eine neue Tabellengeschichte immer noch eine 8, weil sich Ausgabe / Komplexität nicht geändert hat? Oder ist es eine 1, weil der Aufwand minimal ist?

Meine Forschung: Als ich ein Scrum-Training bei Jeff Sutherland absolvierte, ging ich mit dem Verständnis davon aus, dass die Geschichte immer noch eine 8 ist, weil Story-Punkte die Ausgabe messen. Die PM erhält immer noch die gleichen Tabellen, sie werden nur 5x schneller geliefert. Es ist eine echte Geschwindigkeitsverbesserung (macht die gleiche Arbeit, aber schneller)

Aber ich möchte überprüfen, ob mein Verständnis richtig ist. Hilfe da draußen? Wir suchen übrigens nach der formalen Scrum-Definition. Ich habe die Website von scrum inc recherchiert und "Die Kunst, zweimal die Arbeit in der Hälfte der Zeit zu erledigen" durchgearbeitet und kann keine Dokumentation finden, die mein Verständnis richtig oder falsch macht.

Vielen Dank!

Update Ich habe wirklich nach Links zur Dokumentation durch formelle Scrum-Behörden gesucht. Ich denke, diese Frage ist jetzt irreführend, da viele der folgenden Antworten nur die Meinung der Menschen sind.

UPDATE 1/22: SCRUM INC-ANTWORT

"Es bleibt gleich, um eine gleichwertige Lieferung darzustellen. Die Geschwindigkeit des Teams ist ein Schlüsselmaß. Ihre Prozessverbesserung sollte zu einer erhöhten Geschwindigkeit führen: https://www.scruminc.com/velocity/ " --- Scrum Inc. Antwort über Twitter

MEINE KURZE ANTWORT:

Dr. Jeff Sutherland, der Erfinder von Scrum, beantwortet diese Frage direkt in seinem Webinar "Punkte vs. Stunden" auf Folie 6

Was sind Punkte? Punkte sind ein Maß für die Teamleistung. Korreliert mit, aber nicht unbedingt gleichbedeutend mit Aufwand.

JJ Sutherland, CEO von Scrum Inc., antwortet in seiner Lektion über die richtige Geschwindigkeit noch direkter

Nur weil das Team eine bestimmte Geschichte besser umgesetzt hat, sollte der Punktwert gleich bleiben.

MEINE LANGE ANTWORT:

Zusätzliche Quellen. Da diese Frage umstritten ist, gibt es hier Untersuchungen, die einige der in anderen Antworten geäußerten Bedenken beantworten:

Ja. Scrums Ziel ist es, die Geschwindigkeit zu erhöhen

Quelle 1

Obwohl die Geschwindigkeit im Laufe der Zeit tendenziell schwankt, sollte sie in der Regel pro Sprint um etwa 10% nach oben tendieren. - JJ Sutherland

Quelle 2

Folie 5 der Scrum Inc- Lektion zur Geschwindigkeit zeigt ein Geschwindigkeitsdiagramm mit einer 12-fachen Verbesserung im Zeitverlauf UND nennt das Diagramm "Ausgabeverbesserung" mit "Punkten" als y-Achse:

Quelle 3

Gehen Sie zu ScrumLab.scruminc.com und sehen Sie sich die Metrics-Webinare an. Es zeigt, wie wir die Unternehmensleistung anhand der Verbesserung der Geschwindigkeit, der Zufriedenheitsmetrik und des Umsatzes pro Punkt messen. Ich höre so viele langsame Teams, die sich beschweren, dass ein schnelleres Fahren einfach mehr Mist erzeugt. Dies liegt daran, dass Product Owners nicht für die Verdoppelung des Umsatzes pro Punkt verantwortlich gemacht werden. Wenn Sie die Geschwindigkeit und den Umsatz pro Punkt verdoppeln, generiert das Unternehmen viermal mehr Geld. Das wird alle glücklich machen. Deshalb benötigen Sie die drei Metriken. - Jeff Sutherland

Ja. Story Points messen Output / Produktion

Quelle 1

Die Managementmetrik für die Projektabwicklung muss eine Produktionseinheit sein, die Jeff Sutherland in seinem endgültigen Artikel Warum Story Points besser sind als Stunden

Quelle 2

Wenn das Team anfängt, Geschichten mit niedrigeren Werten zu schätzen, weil sie wesentlich mehr Erfahrung gesammelt haben und die Geschichten einfacher erscheinen, wird sich die Geschwindigkeit niemals verbessern. Dies ist ein wichtiger Grund, warum das Schätzen in Stunden nicht funktioniert. - CEO von Scrum Inc, JJ Sutherland

NEIN. Eine Erhöhung der Geschwindigkeit beeinträchtigt nicht die Vorhersagbarkeit

Zuallererst ist die Vorhersehbarkeit eines PO oder einer Führungskraft sehr wichtig, aber die Produktivität ist noch wichtiger. Die meisten POs würden die erhöhte Produktivität wählen, wenn sie die Wahl hätten, das Produktionsniveau beizubehalten oder die Produktivität auf Kosten einer geringen Vorhersehbarkeit signifikant zu verbessern. Abgesehen davon ist der Kompromiss eine falsche Wahl, wenn ein Team das empfohlene Wetter- Scrum-Muster von gestern für die Sprint-Planung verwendet.

Mit gesundem Menschenverstand ... Wenn ein Team 10 Widgets pro Woche produziert, findet es einen Weg, 40 Widgets pro Woche zu produzieren. ihre Geschwindigkeit hat sich 4x verbessert. Die Bestellung erhält in der gleichen Zeit viermal so viele Widgets. Diese flache Geschwindigkeit zu nennen, widerspricht der Definition des Wortes.

JA. Das Spielen des Systems ist möglich, wenn das gesamte Team betrügt

Schließlich ist es möglich, das System zu spielen, aber es ist möglich, jedes System zu spielen. Scrum minimiert die Kirschpflückgeschichten der einzelnen Entwickler, indem es aus einem geordneten Rückstand zieht und die Geschwindigkeit auf Teambasis und nicht auf Einzelentwicklerbasis misst. Wenn Sie dev anhand der dev-Geschwindigkeit messen, machen Sie kein Scrum. Und es verringert das Spielen des Systems durch Schätzungen, indem Geschichten als Gruppe gepflegt werden. Um Ihre Schätzungen zu verpacken, müssen Sie dies vor der Gruppe tun und die Gruppe muss mit Ihnen zusammenarbeiten. Aber wenn Sie das System spielen möchten, spielt es keine Rolle, welchen Prozess Sie verwenden. Scrum ist auf ein Team von 4-6 motivierten, fähigen Mitarbeitern angewiesen, die daran interessiert sind, gemeinsam Ziele zu erreichen. Aber wenn Sie Mitarbeiter haben, die die Arbeit betrügen, um das System zu spielen, ist Ihr Prozess nicht das Problem.

Ihre Back-End-Tabellengeschichten erfordern keine acht Punkte mehr.

„Ein Story Point ist eine relative Maßeinheit, die von einzelnen Scrum-Teams festgelegt und verwendet wird, um relative Schätzungen des Aufwands für die Erfüllung der Anforderungen bereitzustellen. “

scrum.org

Wenn Sie weiterhin Back-End-Tabellengeschichten an acht Punkten schätzen, verzerren Sie Ihre Geschwindigkeit als Maß für den Aufwand pro Sprint.

Es wäre auch unaufrichtig, weiterhin acht Punkte für Arbeiten zuzuweisen, von denen Sie wissen, dass sie nur einen Punkt erfordern.

Geschwindigkeitssteigerung ist kein Ziel. Das Ziel ist eine zuverlässige Planung.

Story Points sind ein Werkzeug in einer Rückkopplungsschleife, das Ihnen im Laufe der Zeit die typische Geschwindigkeit anzeigt. Dies zeigt Ihnen dann, wie viele Punkte Sie in einem Sprint realistisch übernehmen können. Die Geschwindigkeit kann mit der Zeit etwas driften, aber wenn sie sich zu schnell ändert, ist sie nutzlos. Ein plötzlicher Geschwindigkeitsanstieg würde Ihnen nur sagen, dass Sie immer noch nicht wissen, was Sie tun. Sie möchten also Ihre Geschwindigkeit konstant halten, was Ihnen sagt, dass Ihre Schätzungen gut waren und wahrscheinlich für den nächsten Sprint gut sein werden.

Sie wissen, dass Ihre Ausgabe nicht konstant ist. Sie sind sich der Tatsache bewusst, dass Sie Tabellen jetzt viel schneller erstellen können. Es würde also den Zweck Ihres Planungszyklus völlig zunichte machen, wenn Sie darauf bestehen, Story Points mit Ergebnissen zu verknüpfen.

Auch hier hängt die Geschwindigkeit nicht mit der Produktivität zusammen, und eine erhöhte Geschwindigkeit ist kein Grund zum Feiern. Ein Story Point ist letztendlich ein Teil Ihres Sprints. Um es realer zu machen, definieren einige Teams eine bekannte Aufgabe, die jeder versteht, und nennen sie die Standard-Story-Point-Aufgabe, sodass jede Arbeit in Bezug auf Komplexität und Zeitaufwand mit der Standardaufgabe in Beziehung gesetzt werden kann. Unnötig zu sagen, wenn die Standardaufgabe einfacher wird, wird sich alles verschieben und jeder muss sich an die neue Bedeutung eines Story Points anpassen, was scheiße ist. Der richtige und bequeme Weg wäre, eine neue Standardaufgabe zu definieren, die für das Team gleichermaßen herausfordernd ist.

Story-Punkte geben an, wie viel Aufwand für die Implementierung der Story erforderlich ist. Sie sind eine Vorhersage der Anstrengung. Wenn der Aufwand sinkt, sinkt auch die Anzahl der Punkte.

Denken Sie daran, dass die Punkte ein Hilfsmittel für die Schätzung sind. Nicht mehr, nicht weniger. Sie sind keine Belohnung oder Metrik, die die Ausgabe misst. Sie sind lediglich eine Möglichkeit, abzuschätzen, wie viel Arbeit erforderlich ist, um das Ziel der Geschichte zu erreichen.

Sie sagen, diese Aufgabe hat ursprünglich 8 Punkte gekostet, was ungefähr einer Woche entsprach. Nehmen wir jetzt an, Ihre Sprints dauern eine Woche. Bei der Planung werden Sie also Geschichten im Wert von 8 Punkten abrufen. Wenn Sie diese Geschichte bei 8 Punkten halten, können Sie nur planen, diese eine Geschichte im Sprint zu beenden. Wenn die tatsächliche Zeit nur eine Stunde statt 40 Stunden beträgt, was machen Sie dann mit den anderen 39 Stunden? Sie haben gerade einen sehr schlechten Plan für Ihren Sprint erstellt, weil die Story-Punkte ungenau sind.

Wenn die Geschichte genauer als ein Punkt dargestellt wird, bedeutet dies, dass Sie im aktuellen einwöchigen Sprint noch 7 weitere Punkte sammeln können. Das scheint Ihre Realität genauer widerzuspiegeln, daher ist es sinnvoll, die Größe der Geschichte zu ändern, da dies Ihnen bei der Planung hilft.

Sie erwähnen in Ihrer Frage den Wunsch, die Geschwindigkeit zu verbessern, aber das sollten Sie eigentlich nicht tun. Zumindest nicht im wörtlichen Sinne. Ihre Produktivität wird natürlich steigen, aber für die Planung sollte Ihr Geschwindigkeitswert ziemlich konstant bleiben.

Denken Sie an die Auswirkungen. Angenommen, Sie haben ein Team von fünf Personen, eine Geschwindigkeit von 100 Punkten im Sprint, und Sie erwarten vernünftigerweise, dass jeder 20 Punkte erreicht. Jetzt haben Sie diese Aufgabe, die trivial geworden ist, aber immer noch acht Punkte erhält. Ein Teammitglied übernimmt fünf dieser Aufgaben, erledigt sie in zwei Tagen, legt seine Füße für die verbleibenden acht Tage auf den Schreibtisch, schlägt alle, indem es Aufgaben im Wert von 40 Punkten erledigt, und erhält einen Bonus. Alle anderen werden vom Chef gekaut.

Wenn Sie damit zufrieden sind, ändern Sie die Punkte für diese Aufgabe nicht. Diese Situation würde mir nicht gefallen.

Von jeder Aufgabe mit der gleichen Anzahl von Punkten sollte erwartet werden, dass ein Entwickler die gleiche Zeit benötigt.

Und ich bin völlig anderer Meinung als Nathaniels Antwort hier. Das Beibehalten der Punkte würde die Geschwindigkeit völlig unvorhersehbar machen, da einige Aufgaben schneller erledigt werden, andere jedoch nicht. Ein Sprint mit beschleunigten Aufgaben gibt Ihnen also eine enorme Geschwindigkeit, und der nächste Sprint geht wieder runter.

Es ist auch nicht so, wie Sie schätzen würden. Wenn ich weiß, dass ich zehn ziemlich ähnliche Aufgaben habe, gebe ich ihnen überhaupt nicht die gleichen Punkte. Ich gebe dem ersten viele Punkte, die dazu gedacht sind, "die Aufgaben zu erledigen und die Werkzeuge zu bauen, um ähnliche Aufgaben sehr schnell zu erledigen", und dann viel weniger Punkte für die wiederholten Aufgaben.

Es ist eine andere Situation, wenn ein Junior-Entwickler anfängt oder ein Entwickler aus einem anderen Team beitritt und seine Geschwindigkeit ein anderes Mal erhöht, weil er lernt (wie er seine Arbeit überhaupt erledigt oder was er über das Besondere wissen muss) Projekt).