Wie nutzt man Story Points, wenn User Stories komplett anders sind?

Story Points (SP) sind ein gutes Maß, um User Stories zu schätzen.

SP ( meiner Meinung nach ist es eine wichtige Notiz ) ist praktisch, weil es relativ ist und nicht mit der Zeit zusammenhängt. Alle Schätzungen basieren auf dem Vergleich mit einer gemeinsamen Basis. Was aber, wenn zwei Geschichten völlig unterschiedliche Grundlagen haben?

Lassen Sie uns der Einfachheit halber nach einem Beispiel suchen, das sich nicht auf einen bestimmten Bereich bezieht. Als würde man eine Grube graben.

Nehmen wir an, dass es 1 SP kostet, eine Grube von einem Meter Tiefe zu graben. Dementsprechend benötigen wir 2 SP, um eine zwei Meter tiefe Grube zu bauen. Sehr angenehm. Unsere Ausrüstung ist uns egal. Wenn wir eine Schaufel haben, entspricht 1 SP 1 Manntag. Wenn wir einen Bagger haben, entspricht 1 SP 1 Mannstunde. Aber für zwei Meter Grube brauchen wir sowieso doppelt so viel Zeit wie für eine Ein-Meter-Grube.

Alles ist gut mit Grubengraben. Aber was, wenn die nächste Geschichte „einen Elefanten fangen“ ist?

  • Sollten wir Schätzungen mit einer anderen (elefantenbezogenen) Basis vornehmen? In diesem Fall haben wir zwei Arten von Story Points, die absolut unterschiedlich sein werden.

  • Oder wenn wir wissen, dass 1) das Fangen eines Elefanten bei uns 1 Manntag dauert 2) wir immer noch eine Schaufel zum Graben verwenden, dann sollten wir diese "Elefanten" -Geschichte auf 1 SP schätzen? Dieser Vorschlag klingt für mich absolut falsch. Aber ich habe es geschrieben, weil die Leute in meiner Praxis diese Option in den meisten Fällen verwenden.

  • Oder verstehe ich das Konzept der Story Points einfach falsch?

Das ist eine sehr gute Frage. Aber IMHO hat es keine Antwort, weil Story Points kein konsistenter, wissenschaftlicher Ansatz zum Schätzen ist.
Beweisen Sie auf wissenschaftliche Weise, dass nur das, was wissenschaftlich korrekt ist, auch korrekt ist @ChrisBrettini.
Und "nicht konsequent"... das stimmt nicht!

Antworten (3)

Man kann Ihnen nicht vorwerfen, dass Sie verwirrt sind. Es ist sehr üblich, dass Organisationen versuchen, Story Points direkt mit einer Messung aus der realen Welt abzugleichen. Dies widerspricht genau dem Zweck, Story Points zu verwenden (und warum ich Poker Planning nicht zum Schätzen mag).

Ein Story Point ist vereinfacht gesagt eine Zahl, die dem Team sagt, wie schwer die Geschichte ist. Schwer könnte mit Komplexität, Unbekanntem und Aufwand zusammenhängen. Es war nie beabsichtigt, eine zeitbasierte Schätzung zu ersetzen. Stattdessen erkennt Agile (Scrum, XP usw.), dass zeitbasiertes Schätzen fehlerhaft ist und vermeidet es. Ein klassischer zeitbasierter Schätzungsablauf würde beispielsweise so aussehen:

  1. Ein Ingenieur glaubt, dass er drei Tage brauchen wird. Sicherheitshalber sagt er eine Woche.
  2. Der Chef des Ingenieurs befürchtet, dass es komplexer werden könnte oder dass es zu Verzögerungen bei Abhängigkeiten kommen wird, sodass sie auf zwei Wochen aufstocken.
  3. Der Programm-Manager holt sich die Einschätzungen aller und nimmt an, dass Ingenieure unterschätzen (hey, wann wurde das letzte Mal ein Projekt mit all den ursprünglichen PRD-Elementen ausgeliefert?), sie fügen dem Zeitplan einen 10-prozentigen Fehler hinzu.
  4. Dann wird dem gesamten Projekt gemäß den bewährten Verfahren des Standardprojektmanagements ein Zeitplanpuffer von 20 % zugewiesen.
  5. Dann weiß die Geschäftsleitung, dass die Geschäftsleitung keinen Best-Case-/Worst-Case-Zeitplan verstehen wird, sie fügen einfach den Puffer von 20 % hinzu und machen das zum offiziellen Veröffentlichungsdatum.
  6. Schließlich tritt das Parkinson-Gesetz in Kraft und die Arbeit wird entsprechend der verfügbaren Zeit erweitert. "Hey, wir haben ganze 12 Monate bis zum Versand, wir müssen jetzt nicht neun Monate lang Code vollständig sein!"

Story Point-Schätzungen funktionieren am besten, wenn sie relational sind. Sie versuchen nicht abzuschätzen, wie viel Zeit es dauern wird. Stattdessen versuchen Sie herauszufinden, ob Story A mehr oder weniger komplex ist als Story B.

Schauen wir uns Ihr Beispiel oben an:

  • Ein 1m Loch graben: Gut verstanden und keine Überraschungen. Team nennt es selbstbewusst 3 Punkte.
  • Graben Sie ein 2-m-Loch: Verdoppeln Sie ungefähr die Arbeit eines 1-m-Lochs. Immer noch gut verstanden und keine Überraschungen. 5 Punkte.
  • Einen Elefanten fangen: Wow, wir haben keine Erfahrung damit und das wird eine Menge spezialisierter Ausrüstung erfordern. Definitiv mehr Aufwand als ein 2m Loch zu graben. Es gibt auch viele Unbekannte, also strebt das Team eine 13 an.
  • Da das Fangen eines Elefanten so neu ist, können sie sogar einen „Forschungsstachel“ erstellen, um jemanden loszuschicken, um zu erforschen, wie man einen Elefanten fängt.
Nehmen wir also an, wir haben drei User Storys. Die einfachste Geschichte werden wir in 2 SP schätzen, eine etwas schwierigere Geschichte werden wir in 3 SP schätzen und schließlich wird die schwierigste Geschichte 5 SP sein (nächste Fibonacci-Zahl nach 3). Aber wir wissen im Grunde nicht, was wir schneller machen werden: erster und zweiter Stock zusammen oder dritter Stock.
Trotz der Tatsache, dass diese Geschichten (1+2 vs. 3) die gleiche Summe an Story Points haben, kann die Implementierung der ersten beiden und der letzten Geschichte für uns unterschiedlich lange dauern, da wir in Wirklichkeit nicht wissen, welchen Wert die eine Geschichte dann schwerer hat Ein weiterer. Wir wissen nur, dass diese drei Geschichten unterschiedlich schwierig sind. Es ist also sinnlos, Punkte miteinander zu vergleichen oder zu addieren.
Habe ich Sie richtig verstanden?
Im Wesentlichen ja. Denken Sie daran, dass der Zweck der Schätzung darin besteht, festzustellen, wie viel Arbeit das Team in einem Sprint erledigen kann. Dies wirkt sich über das Aggregat aus. In einer guten agilen Implementierung messen Sie abgeschlossene Stories, nicht Story Points, und Sie messen die Geschwindigkeitsvarianz, nicht die Geschwindigkeit selbst (Geschwindigkeit ist ein internes Teammaß). Fühlen Sie sich frei, mich direkt anzupingen, wenn Sie weitere Fragen haben.
Joel, danke für die gute Erklärung von Story Points. Ich beschloss, T-Shirts zum Messen von Geschichten zu verwenden. Wie ich jetzt verstehe, ist dies absolut dasselbe wie Fibonacci Story Points. Aber bei T-Shirts werde ich keine große Lust haben, damit zu rechnen =)
Die T-Shirt-Größe ist der Ausgangspunkt für die Schätzung. Die Leute können es sehr leicht in die Hand nehmen. Eine gute Wahl. Selbst wenn Sie in Zukunft zu detaillierteren Schätzungen für das Team übergehen (was ich empfehle), ist die T-Shirt-Größe großartig für die Planung auf Portfolioebene.
@Joel Ich bin verwirrt über Ihren Punkt "Sie messen abgeschlossene Geschichten, keine Geschichtenpunkte und Sie messen die Geschwindigkeitsvarianz, nicht die Geschwindigkeit selbst". Bedeutet das, dass es nicht gut ist, die durchschnittlich absolvierten SP meines Teams pro Sprint zu kennen, um zu wissen, ob der nächste Sprint aufgebläht ist? Ich bin wirklich neugierig darauf.

Wie Joel sagte, SPs sind keine Messungen in der realen Welt. Sie symbolisieren den notwendigen Aufwand, um eine User Story zu vervollständigen.

Da sie unabhängig von einer Einheit sind, können sie auf alles angewendet werden, was Aufwand erfordert . Aufgrund dieser lockeren Definition wird oft empfohlen, die Fibonacci-Zahl zu verwenden, um eine höhere Anstrengung zu kennzeichnen.

Es hilft mir, mir Schweißflaschen vorzustellen , die vom Team geschaffen wurden, um die Geschichte abzuschließen. Fühlen Sie sich frei, ein bequemeres Bild einzuführen :)

Tolle Optik, Tobias. :)

In meiner akademischen Ausbildung wurde mir immer gesagt, dass ich aus Gründen des Änderungsmanagements gemäß PMBOK zuerst die Kundencharta vereinbaren sollte. Sehen Sie sich dann die Meilensteine ​​an und schätzen Sie diese ein. Diese helfen Ihnen bei der Entscheidung, wie viele Sprints Sie benötigen. Dann gehen Sie und holen sich die User Stories. Diese bilden das Product Backlog, in dem User Stories gepflegt und vom User priorisiert werden. Wenn diese Geschichten außerhalb des Rahmens des ursprünglichen Projektauftrags liegen, wird der Benutzer darauf hingewiesen und es findet ein Kompromiss oder eine Einigung statt. Hilft das. Ich denke, Sie könnten auf Change Management hinweisen. Ich entschuldige mich, wenn ich die Frage falsch interpretiert habe. Dies ist nur ein grober Überblick über meine Implementierung des agilen Projektmanagements. Ich glaube, dass zuerst eine gute Charta und ein guter Plan notwendig sind, um die erfolgreiche Fertigstellung der Software und einen zufriedenen Benutzer zu sehen.

Wenn Sie versuchen, Agile in einen größeren Wasserfallprozess einzufügen, wird dies normalerweise so gemacht. Es ist auch einer der führenden Orte, an denen wir hören, dass „Scrum fehlschlägt“. Bei Agile ist ein Produkt dann fertig, wenn es für den Kunden ausreichend Wert hat. Das kann nach drei Sprints sein, das kann nach zwölf sein.
Wie nutzt man Story Points, wenn User Stories komplett anders sind?
AntwortenHierDatenschutz-Bestimmungen1y, 2v