Können wir Story Points Zeit zuweisen?

Ich bin der Scrum Master und verwende locker das folgende System:

  • 0,2 Punkte ca. < 1 Stunde
  • 0,5 Punkte ca. > 2 Stunden aber < 3 Stunden
  • 1 Punkte ca. > 4 Stunden (halber Tag)
  • 2 Punkte ca. > 8 Stunden (1 Tag)
  • 3 Punkte ca. > 16 Stunden (2 Tage)

Ich verwende die Schätzungen als Richtlinie dafür, wie lange die Aufgabe ungefähr dauern würde. Verwenden Sie dies als Leitfaden, um den Wert einer Woche Arbeit zu erarbeiten. Meine Sprints sind in der Regel 4 Tage lang. Also in diesem Fall wird das Team die Punkte für die entsprechende Woche ungefähr zusammenzählen.

Nachdem ich den Fortschritt meiner Teams nach 3-4 Sprints verfolgt habe, stelle ich fest, dass es sinnlos wird, Zeit gegen die Punkte zuzuweisen, da die Gesamtzahl der Story-Punkte, die sie abschließen können, im Laufe der Wochen zunimmt. Letzte Woche waren es 6,2 Punkte, diese Woche ist diese Zahl auf 9 gestiegen, normalerweise variiert dies und ich versuche, die durchschnittliche Geschwindigkeit des Teams zu finden.

Soll ich die Leistung des Teams anhand der durchschnittlichen Anzahl von Punkten messen, die sie im Sprint erreichen können, oder die Zeit als Annäherung an die Punkte anhängen?

Vielen Dank

Story Points können zeitbezogen sein, nur nicht direkt. Mike Cohn beschreibt es als Verteilung, also entsprechen 3 Punkte zB fünf Tagen mit einer Standardabweichung von X. Aber um an den Punkt zu kommen, an dem Sie diese Annäherung machen können, müssen Sie zuerst mehrere Sprints gelaufen sein, ohne über die Zeitumrechnung nachzudenken. So ergibt sich Ihr Umrechnungsfaktor aus Erfahrung und nicht umgekehrt. scrumalliance.org/community/spotlight/mike-cohn/june-2014/…
Wenn wir Punkte direkt der Zeit zuordnen können, welchem ​​Zweck dient dann die Geschwindigkeit? Was ist unsere evidenzbasierte Rückkopplungsschleife für die Korrektheit dieser Abbildung, wenn nicht die Geschwindigkeit?
Sie verwechseln eindeutig User Stories mit Aufgaben. Sie können Aufgaben in idealen Stunden schätzen, wenn Sie möchten, aber wenn Sie versuchen, Story Points in ideale Stunden umzuwandeln, machen Sie mit Agile Estimation Wrong® falsch .

Antworten (4)

Story Points sind ein ABSTRACT-Maß für die Komplexität eines Produktinkrements. Die Idee ist, dass die Komplexität für alle gleich ist, während der Aufwand, der erforderlich ist, um sie zu vervollständigen, je nach den Fähigkeiten und der Erfahrung eines Entwicklers variiert. Daher macht es für mich überhaupt keinen Sinn, die Zeit aus Story Points zu berechnen. Da Sie bereits eine steigende Geschwindigkeit erleben, während die Arbeitszeiten stabil bleiben, können Sie sehen, dass es keinen direkten Zusammenhang zwischen Story Points und Zeit gibt. Und ich würde nicht empfehlen, die Leistung eines Teams an Zeit oder Story Points zu messen. Stattdessen empfehle ich, die Arbeitskapazität (wie viel kann das Team innerhalb eines Sprints erfolgreich absolvieren) und den Fokus (wie viel Zeit wird tatsächlich in das Sprintziel investiert) zu betrachten.

„Stattdessen empfehle ich, auf die Arbeitskapazität zu schauen (wie viel kann das Team innerhalb eines Sprints erfolgreich absolvieren)“ – wie messe ich das?
@bobo2000 Sie sollten sich engagierte Story-Punkte im Vergleich zu abgeschlossenen Story-Punkten ansehen. Die Kapazität basiert im Allgemeinen auf Punkten.
@bobo2000 hier ist eine Methode, die für mich wirklich gut funktioniert. Messen Sie einfach, wie viel erledigt wurde und wie lange es gedauert hat. pm.stackexchange.com/a/18279/21039

Es gibt also möglicherweise eine Reihe von Dingen, die hier passieren.

Erst einmal; Story Points sollten nicht direkt mit Stunden korrelieren, da sie aufgrund einer Reihe von Faktoren schwanken. Nach mehreren Sprints können Sie den Durchschnitt der letzten paar Sprints nehmen, um die Geschwindigkeit des Teams zu bestimmen, und diesen verwenden, um die Arbeit in die Zukunft zu projizieren. Diese Prognose wird letztendlich auch eine Schätzung sein, da einige Arbeiten früher und andere später erledigt werden.

Allerdings habe ich ein paar Beobachtungen / Gedanken.

  1. Meine Sprints sind in der Regel 4 Tage lang.

Ich denke, dass Ihre Sprints zu kurz sind, um die Leistung Ihres Teams im Laufe der Zeit genau abzulesen. Aus persönlicher Erfahrung würde ich erwarten, dass Sie häufig Geschichten verschleppen oder Geschichten vervollständigen, die nicht getestet werden. Ich denke, die beste Praxis ist, dass Sprints nicht kürzer als 1 Woche und nicht länger als 4 Wochen sind; und am häufigsten dauern Sprints 2 Wochen.

  1. Nachdem ich den Fortschritt meiner Teams nach 3-4 Sprints verfolgt habe, stelle ich fest, dass es sinnlos wird, Zeit gegen die Punkte zuzuweisen, da die Gesamtzahl der Story-Punkte, die sie abschließen können, im Laufe der Wochen zunimmt.

Das von Sprint zu Sprint zunehmende Verhalten der Story Point-Ausgabe ist normal. Es wird sich schließlich nach X Zeit nivellieren. Dies kann auf die Forming-, Storming-, Norming- und Performing -Phasen des Teamwachstums zurückgeführt werden. Kurz gesagt, Ihr Team findet heraus, wie es effizient zusammenarbeiten kann.

  1. Ihre Story-Punkte-Skala scheint mir falsch zu sein. Ich würde die Verwendung von Fibonnaci-Zahlen in Betracht ziehen, wenn Sie Zahlen verwenden müssen oder wenn Sie damit durchkommen können [Klein, Mittel, Groß, XLarge] oder eine Variation [Effizienz, Wohnung, Eigentumswohnung, Haus, Herrenhaus], mit der Sie sich wohl fühlen. Meiner Meinung nach ist alles unter 1 Punkt/halber Tag zu wenig, um es zu schätzen, und wenn Ihr Team diese Punkte/Skala zum Schätzen verwendet, wird es wahrscheinlich daneben liegen, weil die Entwickler im Allgemeinen zu optimistisch sind, wie viel getan werden kann.
Habe zuvor 'Klein', 'Mittel' und 'Groß' gemacht - es wird nicht vom Burndown-Diagramm verfolgt. Nur Punkte tun. Früher habe ich auch 1-wöchige Sprints gemacht, lief nicht gut mit dem Stakeholder, also musste ich 4 Tage machen, alles, was es bedeutete, war, dass ich 4 Tage Arbeit zuteilen musste.
@bobo2000 Wie viele Entwickler sind in Ihrem Team / wird die Arbeit einer QA unterzogen, bevor sie als erledigt markiert wird? Warum hält der Stakeholder an 4-Tages-Sprints fest? Sie könnten das Konzept eines Mid-Sprint-Touchpoints mit dem Stakeholder einführen.
@dmeel ja und ja. Er möchte 4-Tage-Sprints, weil es ihn frustriert, dass er keine Änderungsanfragen stellen kann, dh Dinge in die Sprints hinzufügen kann, sobald der Sprint begonnen hat. Wir haben 2 Entwickler und 1 QA-Tester
@bobo2000 Es hört sich so an, als müssten Sie Ihren Arbeitsrückstand aufbauen. Wenn Sie bereits ein Backlog mit mehreren Sprints haben, klingt es so, als würde Ihr Stakeholder den agilen Prozess wirklich nicht akzeptieren. Wenn 4 Tage in einem Sprint so sind, wie es sein muss, werden Sie meiner Meinung nach weiterhin eine große Schwankung der durchschnittlichen Story Points erleben, da Ihre Geschichten so geschrieben werden müssen, dass sie in einen 4-Tage-Sprint passen.
@bobo2000 hast du darüber nachgedacht , ihn mitten im Sprint neu priorisieren zu lassen? Ich weiß, es klingt verrückt, aber hier raus. Ihr PO möchte mitten im Sprint neue Prioritäten setzen, also bringen Sie ihn zum Board und lassen ihn. Aber Sie müssen darauf hinweisen, dass er dem Sprint nichts hinzufügen wird, ohne etwas herauszunehmen, und er kann nichts herausnehmen, was bereits begonnen hat. Er wird schnell anfangen, den Rückstand besser zu priorisieren, wenn er den Schmerz, den er durch die Unterbrechung des Sprints verursacht, direkt spürt. Achten Sie auch darauf, Kapazitätsänderungen im Verhältnis zur Anzahl der Prioritätsänderungen zu verfolgen.
@RubberDuck Ich habe das bereits getan, aber es fühlt sich schmutzig an, wenn ich es tue, seit ich Leute hier gesehen habe, die sagen, dass „Sie den Sprint-Rückstand nicht ändern können“, sobald sich das Team dazu verpflichtet hat.
Es gibt keinen wirklich agilen Weg @bobo2000. Meiner Meinung nach ist nichts falsch daran, den Rückstand spontan neu zu priorisieren, vorausgesetzt, Sie lassen keine bereits laufende Arbeit fallen. Nehmen Sie es jedoch mit einem Körnchen Salz, ich arbeite mit Kanban, nicht mit Scrum. In meinem Workflow gibt es kein Konzept für ein Sprint Commitment oder einen Sprint Backlog. Nur ein ständig gepflegtes und priorisiertes Produkt-Backlog, in dem wir das Nächstwertvolle tun. Ich kann nur sagen, dass es bei uns funktioniert.

„Sollte ich die Leistung des Teams anhand der durchschnittlichen Anzahl von Punkten messen, die sie im Sprint erreichen können, oder die Zeit als Annäherung an die Punkte anhängen?“

Ich denke, die meisten Leute ordnen den Punkten in ihrem Kopf beim Schätzen eine Zeit zu. Wenn Sie jedoch versuchen, die Leistung anhand abgeschlossener Story Points zu messen, fördern Sie die Überschätzung von Aufgaben. Ich kann leicht eine Million Story Points sprinten. Du wirst meine Schätzungen aber nicht mögen!!!

Vergessen Sie „Teamleistung“. Bei Story Points geht es darum abzuschätzen, wie lange es dauern wird, das Projekt abzuschließen. Nehmen Sie den Durchschnitt pro Sprint und dividieren Sie den Rest durch diese Zahl, um Ihr voraussichtliches Fertigstellungsdatum zu erhalten.

Der Hauptgrund für Story Points und andere abstrakte Messsysteme besteht darin, Sie davon abzuhalten, in Begriffen der Zeit zu denken. Wenn Sie sie mit Zeit assoziieren wollen, entfernen Sie einfach alle Story Points und kehren Sie zu den Arbeitsstunden zurück.

Indem Sie versuchen, Zeitpunkte in Beziehung zu setzen, untergraben Sie das gesamte System.

Sie können Zeit und Punkte messen und herausfinden, wie sie tendenziell gleich sind, und dann ein Burn-Down-Diagramm verwenden, um herauszufinden, wie viele Punkte Sie entfernen müssen, um einen Liefertermin festzulegen, aber das soll Ihre einzige Kontrolle sein.

Sie können nicht Dinge sagen wie „Wir müssen dieses Datum mit diesen Merkmalen vereinbaren, und Sie können die Punkte nicht den Merkmalen zuweisen.

Ein Großteil des ursprünglichen XP-Zeugs drehte sich um das Korrigieren des Projektmanagements, nicht um die Projektentwicklung, und die wichtigsten Punkte wie dieser sind diejenigen, die in die Ableger wie Scrum eingedrungen sind. Das Lesen einiger Original-XP-Inhalte kann helfen, zu verstehen, warum einige dieser Prozesse funktionieren.

Können wir Story Points Zeit zuweisen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v