Story Points Fehler?

Die offizielle Antwort auf das Problem lautet:

Es gibt keine festen Nummern. Wenn es sinnvoller ist, eine große Geschichte mit 100 Punkten zu haben, dann tu es. Wenn es sinnvoller ist, Geschichten mit 1/2 Punkt zu haben, verwenden Sie diese. Verwenden Sie beides, wenn Sie müssen.

Für Ihr Problem sollten Sie sich jedoch Ihre 1-Punkt-Geschichten ansehen. Sind das eigentlich Geschichten und was ist deine Definition von Done?

Unter der Annahme einer standardmäßigen 40-Stunden-Arbeitswoche und einer zweiwöchigen Sprintlänge würde dies bedeuten, dass die Person weniger als 20 Minuten pro Ticket benötigt. Dazu gehört bereits, dass diese Person während des gesamten Sprints keine Pausen, keinen Kaffee, keine Toilette, kein einziges Meeting gemacht hat. In Wirklichkeit sind es wahrscheinlich eher 10-15 Minuten pro Ticket.

Mit unserem DoD wäre ich nicht in der Lage, ein Ticket in 20 Minuten zu schließen. Ich muss es öffnen, lesen und verstehen, den aktuellen Code auschecken, ändern, Tests für die Änderung schreiben, die Daten für die Überprüfung/Demo vorbereiten, festschreiben, pushen, zusammenführen und meinen Code irgendwo installieren Rezension/Demo. Selbst für einen Tippfehler mit einem einzigen Zeichen dauert es 15-20 Minuten, nur tippen, auf Schaltflächen klicken und auf die Ergebnisse warten.

Bei 250 so kleinen Geschichten würde ich fragen, ob es überhaupt sinnvoll ist, Story Points für sie zu haben. Von Ihren 251 Stories im Sprint sind 250 schneller fertig als geschätzt . Vielleicht ist es besser, sich anders zu organisieren.

Lassen Sie die Leute vielleicht an dem Strom scheinbar kleiner Tickets arbeiten, und nur wenn sie ein besonders großes treffen, wird dies zu einem Backlog-Element für das Team. Normalerweise hat ein Unternehmen zwei Teams, eines für den täglichen Betrieb (auch bekannt als 250 superkleine Aufgaben) und eines für die Entwicklung, das sich darauf konzentriert, an den großen Geschichten zu arbeiten.

Versuchen Sie, große User Stories in überschaubare Teile zu unterteilen (weniger als einen Tag zu erledigen), das kann Ihr Problem lösen. Wenn Sie die User-Story-Härte erhöhen, kann die Lösungshärte nichtlinear zunehmen, wie Sie an Ihren Story-Punkten sehen können.

Die Grundlage der relativen Schätzung (dafür werden Story Points verwendet) ist, dass 1 Punkt immer ungefähr den gleichen Aufwand darstellt. Dies muss unabhängig von der Größe der Aufgabe sein.

Dies bedeutet, dass eine 20-Punkte-Aufgabe etwa 20-mal so viel Aufwand sein muss wie eine 1-Punkte-Aufgabe (obwohl der tatsächlich aufgewendete Aufwand aufgrund der Unsicherheiten bei der Schätzung leicht zwischen dem 10-fachen und dem 40-fachen schwanken kann).

Wenn in Ihrem Beispiel ein einzelner Entwickler entweder 250 XXS-Aufgaben oder eine XL-Aufgabe erledigen kann, dann ist die XL-Aufgabe etwa 250-mal so groß wie eine XXS-Aufgabe, nicht das 20-fache, das Ihre Story-Point-Werte vermuten lassen. Das bedeutet, dass entweder deine Story-Point-Zuordnung zu den T-Shirt-Größen falsch ist, oder dass die XL-Aufgabe grob unterschätzt wird.

Ok, ich gebe Ihnen eine bessere Größentabelle. Ich denke, das Problem ist, dass Sie das falsche System eingerichtet haben.

Vor allem müssen Sie:

• schulen Sie Ihr Team, um technische Schätzungen abzugeben und
• Nehmen Sie einen Durchschnitt für eine User Story.

Bessere Größentabelle

USER STORY SIZE  TIME ESTIMATE
0                   (-)
1/2                 (<1/2 h)
1                   (1/2 - 1 h)
3                   (1  - 2 h)
5                   (2 - 4 h)
8                   (4 - 8 h)
13                  (8 - 16 h)
20                  (16 - 24 h)
40                  (24 - 40  h)
100                 (40 - 80 h)

Hinweis: Die Teamschätzung ist der Durchschnitt aller Schätzungen