Definition eines Story Points [geschlossen]

Soweit mir bekannt ist, gibt es keine Definition von Story Points und wie man sie vergleicht. Jede Person in einem Team kann sein persönliches Verständnis der Korrelation zwischen einer Anstrengung und Story Points haben. Ist die Schätzung der Story Points nicht nur ein Trugschluss?

Ist es nicht nur ein Glaube. Beispielsweise wird angenommen, dass alle Aufgaben eine bestimmte Eigenschaft haben – die Schwierigkeit, den Aufwand. Aber sie tun es vielleicht nicht. Und selbst wenn sie es tun, ist es nur ein Glaube, dass wir es als Zahl angemessen schätzen können. Die Zeit, die eine Aufgabe in Anspruch nehmen wird, ist an sich unbestimmt.

Zum Beispiel: Beim Planning Poker stimmen alle Teammitglieder zu, dass ein PBI auf 10 Story Points geschätzt werden sollte und sie gehen zum nächsten PBI. Diese 10-Story-Point-Schätzung bedeutet eigentlich nichts, weil jeder 10-Story-Point anders versteht (unterschiedlicher Aufwand, Zeit, Risiken).

Ich möchte nur zuverlässige Argumente (eine Recherche, umfassende Umfragen), dass SP wirklich ein Werkzeug ist und nicht nur eine Überzeugung .

Die Frage und die Kommentare zu den Antworten lassen den Anschein erwecken, als wollten Sie nur streiten. Story Points sind nicht fest an Zeit oder Geld gebunden. Konsistente Teams, die im selben Kontext arbeiten, beobachten oft eine starke Korrelation, nachdem sie eine Zeit lang zusammengearbeitet haben. Die Technik wurde so entwickelt. Es ist nur ein Werkzeug, das Sie verwenden können oder nicht.
Ich denke das gleiche @Daniel.
@Daniel Nein, ich möchte nur zuverlässige Argumente dafür, dass SP wirklich ein WERKZEUG ist und nicht nur ein GLAUBE.
Chris Brettini, du hast Argumente! Die Sache ist die, dass Sie den GLAUBEN haben, dass nur Ihr GLAUBEN richtig ist und Sie dafür keine verlässlichen Argumente liefern können.
Die Informationsanfrage ist gut - obwohl ich eher dachte, dass dies schon einmal auf PM:SE angesprochen wurde. Die Unterscheidung zwischen „Tool“ und „Belief“ erscheint wie eine falsche Dichotomie und scheint im Dienste eines rhetorischen Ziels eingesetzt zu werden.
Ja, ich denke auch, was Chris Brettini will, wurde hier schon beantwortet .
Ich bin mir nicht sicher, wie ein Glaube definiert wird. Was Taigo gepostet hat, kann helfen. In einer von Mike Cohns Keynotes spricht er darüber, dass seine Organisation mehrere Schätzungsmethoden gegeneinander anwendet, und Story Points haben sich als am nützlichsten herausgestellt. Hunderte, wenn nicht Tausende von Teams setzen sie jeden Tag erfolgreich ein. Sie sind ein preisgünstiges Werkzeug, unabhängig von veröffentlichten Studien. Sie stellen jedoch viele traditionelle Annahmen über Schätzungen in Frage, sodass Sie sie nicht wie Stunden verwenden können.
Ich habe ähnliche Argumente von unzähligen Entwicklern gehört, die einfach keine Schätzungen machen wollten. Sie kamen auf die komplexesten Punkte, um die Idee zu rechtfertigen, dass jede Art von Schätzung fehlerhaft und daher nutzlos ist. SP mit Religion zu verbinden, ist mir jedoch neu. Kudos für die Kreativität.
Mir fällt keine einzige Aufgabe ein, die nicht mit Schwierigkeiten oder Anstrengung verbunden ist. Können Sie einige Beispiele nennen?
Wie geschrieben, diese Frage ist zu offen. Ganze Bücher wurden zum Thema empirische Steuerungstheorie und Schätztechniken geschrieben, daher ist diese Frage zu weit gefasst. Es lädt auch zur Debatte ein, was eine Art subjektives, listengenerierendes Frageformat ist, das hier als nicht zum Thema gehörend betrachtet wird. Es gibt eine gültige zugrunde liegende Frage, aber ohne umfangreiche Bearbeitung wird sie wahrscheinlich in Kürze geschlossen, da sie nicht der Anleitung zum Stellen von Fragen in unserem Hilfezentrum entspricht.
Aufgrund des langen Hin und Hers in den Kommentaren bleibe ich bei meiner vorherigen Aussage, dass diese Frage zu allgemein und zu offen ist. Ich denke, es gibt hier eine gültige Frage, aber PMSE ist für kanonische Fragen und Antworten konzipiert, nicht für Debatten. Die Community kann diese Frage jedoch nach eigenem Ermessen nach sorgfältiger Bearbeitung und Bereinigung der Kommentare erneut öffnen.

Antworten (5)

Story Points sind eher ein relatives Maß für den Aufwand als ein absolutes. Jedes Mitglied des Teams sollte jedoch die gleiche Vorstellung von der Größe einer Punkteschätzung haben. Ein gemeinsames Verständnis wird erreicht, wenn das Team wiederholt gemeinsame Schätzungen vornimmt und sich auf gemeinsame Baseline-Storys einigt, an denen gemessen werden soll. Das ist wirklich nichts anderes als das Schätzen in Stunden oder Tagen, wo die Leute auch Dinge gegen erinnerte Basiswerte messen. Planungspoker ist eine Möglichkeit, um sicherzustellen, dass Teams ein gemeinsames Verständnis der Größe von Gegenständen haben.

Die relative Schätzung mit Story Points hat einige Vorteile gegenüber der absoluten Schätzung. Es scheint, dass viele Leute zu genaueren relativen Schätzungen kommen als zu absoluten. Die Geschwindigkeit, gemessen an Story Points, die pro Iteration abgeschlossen werden, ist ein evidenzbasiertes Maß, während stundenbasierte Schätzungen eher subjektiv sind. Wenn Sie die Dinge in Stunden messen, können Sie immer noch rückblickend messen, wie viele geschätzte "Stunden" Sie tatsächlich geleistet haben, aber das wird sich zwangsläufig von den tatsächlich geleisteten Arbeitsstunden unterscheiden, so dass "Stunden" in Wirklichkeit auch zu einem relativen Maß werden.

Danke schön! Der Vorteil von Stunden ist, dass jeder sie versteht. Woher wissen wir, dass wir das gemeinsame Verständnis von Story Points haben? Sollten wir Risiken in die SP-Schätzung einbeziehen? Wie kann man die Komplexität in SPs abschätzen?
Sie wissen, dass Sie ein gemeinsames Verständnis von Story Points-Schätzungen haben, genauso wie Sie wissen, dass Sie ein gemeinsames Verständnis von Stundenschätzungen haben: indem Sie sich als Gruppe darauf einigen. Team-Schätztechniken wie Poker oder Bockman's Game stellen sicher, dass, wenn jemand eine Meinungsverschiedenheit hat, diese Differenz für alle offensichtlich ist und die Gruppe die Möglichkeit hat, sich auf einen Konsens zu einigen.
Ihre Argumentation hat einen Fehler – Sie gehen bereits davon aus, dass jeder ein gemeinsames Verständnis hat. Unter der Annahme, dass dies der Fall ist, beschreiben Sie dann den Planungs-Poker-Prozess.
Bei Planning Poker geht es darum, eine gemeinsame Schätzung für einen PBI zu erreichen – nicht darum, ein gemeinsames Verständnis davon zu erreichen, was 1 SP bedeutet.
Es läuft auf dasselbe hinaus. Wenn sich das Team einig ist, dass Story X 4 Punkte ausmacht, „stimmt“ es zu, dass 1 Punkt etwas ist, das ein Viertel von X ist. Die Maßeinheit ist nicht so wichtig. Was zählt, ist, dass sie sich auf eine Zahl einigen und diese Zahl dann verwenden können, um die Geschwindigkeit des Teams zu messen.
Was ist Ihr eigentliches Anliegen? Das Team sollte entscheiden, wie es Schätzungen messen möchte. Wenn das Team glücklicher ist, die Schätzungen als Stunden und nicht als Punkte zu definieren, ist das in Ordnung. Viele Leute finden, dass Punkte für sie funktionieren, aber es ist nicht unbedingt für jeden richtig.
Ich möchte einen zuverlässigen Schätzungsansatz, um ein Fertigstellungsdatum oder Veröffentlichungsdaten zu planen, und die Story Points geben mir diese Informationen einfach nicht.
@ChrisBrettini Ich beginne oft mit 8 Punkten = was an einem Tag machbar ist, aber egal. Ihre ersten Iterationen werden falsch sein, aber immer weniger falsch, wenn die Leute ihre Schätzungen basierend auf Daten anpassen. Bei der letzten Iteration versucht, 40 Punkte zu erreichen, 20 geschafft, die Kapazität der nächsten Iteration beträgt 20. Ihre Iterationen sollten kurz sein, ein oder zwei Wochen, um schnelles Feedback und Korrekturen zu ermöglichen. Die tägliche Verfolgung der Aufgabenerfüllung mit Burndown-Diagrammen zeigt Ihnen schnell, ob Sie auf dem richtigen Weg sind oder nicht. Dies lässt nichts zu, um schlechte Schätzungen zu verbergen. Langzeitschätzung ist ein fortgeschrittenes Thema.
@ChrisBrettini Zusammenfassend geht es bei Story Points und den damit verbundenen Praktiken darum, Ihre kurzfristigen Kapazitäten zu verstehen, Ihre Fähigkeit aufzubauen, die Kosten von Aufgaben genau abzuschätzen, und zu wissen, wann Sie aus dem Ruder laufen. Erst wenn Sie das im Griff haben, wenn Sie Ihre Marke für die Arbeit einer Iteration regelmäßig treffen können, können Sie damit beginnen, genaue langfristige Schätzungen vorzunehmen. Sie können diesen grundlegenden Schritt nicht überspringen.

Seien wir ernst, die Leute interessieren sich normalerweise nicht dafür, wie Sie Schätzungen vornehmen. Was sie interessiert, ist, wie viel es braucht und / oder wie viel es kostet. Zeit und Geld. Das wollen sie. Die Schätzungen sind nur etwas, das Ihnen hilft, diese Fragen zu beantworten. Es spielt keine Rolle, was Sie für Schätzungen verwenden, solange die Leute einen Zeit- oder Geldwert zurückerhalten können. Es kann direkt in Stunden oder Manntagen geschätzt werden, oder es können Story Points, T-Shirt-Größen, Welpen oder Gemüse sein. Niemanden interessierts. Jetzt ernsthaft. Es geht um Zeit und Geld.

Sie müssen also eine Möglichkeit haben, eine Schätzung in Zeit und Geld umzuwandeln, richtig?

Jeder versteht, wie spät es ist. Jeder versteht, was Geld ist. Und wir betrachten sie gerne als absolut. Eine Stunde ist eine Stunde. Zehn Dollar sind zehn Dollar. Aber nicht wirklich. Sie bedeuten für verschiedene Menschen unterschiedliche Dinge. Wenn ich reich bin und Sie arm sind, mögen zehn Dollar für mich nutzlos sein, aber für Sie könnte es einen Unterschied machen, ob Sie Essen auf dem Tisch haben oder nicht. Wenn ich eine vielbeschäftigte Person bin und Sie nicht, dann bedeutet eine Stunde für mich viel und ich nutze sie mit Bedacht, während es für Sie bedeuten könnte, sie online mit Katzenvideos auf YouTube zu verbringen. Obwohl wir sie als absolut wahrnehmen, sind sie es nicht.

Aus den Diskussionen zu den anderen Antworten geht hervor, dass Sie fragen, warum Sie nicht direkt in Stunden statt in Story Points schätzen, da Story Points abstrakt und nicht absolut sind. Jeder versteht eine Stunde, aber Story Points bedeuten für verschiedene Leute unterschiedliche Dinge, richtig? Aber aus dem, was ich oben gesagt habe, sehen Sie, dass sich Story Points nicht so sehr von Stunden unterscheiden. Sie bedeuten für verschiedene Menschen unterschiedliche Dinge. Eine Stunde Entwicklung für einen Senior-Entwickler bedeutet nicht dasselbe wie eine Stunde Entwicklung für einen Junior-Entwickler. Der Senior kann ein komplettes Feature in einer Stunde erstellen, der Junior kann diese Stunde nutzen, um herauszufinden, wie er genau an das Feature herangehen soll. Wenn der leitende Entwickler schätzt, dass eine Funktion eine Stunde dauert, ist diese Schätzung subjektiv. Es kommt sehr auf die Fähigkeiten an. Der Senior baut Feature F in einer Stunde, aber der Junior könnte vier Stunden brauchen, um dasselbe Feature zu bauen. Was nützt also eine Schätzung von einer Stunde für Feature F, wenn es der Junior sein muss, der daran arbeiten muss? (wenn beispielsweise der leitende Entwickler nicht verfügbar ist).

Das Schätzen in Stunden ist eine Möglichkeit, sich selbst zu belügen und Ihnen falsches Vertrauen zu geben. Sie verstehen Stunden, also wenn Sie ein Projekt schätzen und 1078,65 Stunden zurückbekommen, dann haben Sie da einige absolute Informationen, richtig? Sie wissen, womit Sie es zu tun haben. Aber du nicht. So funktioniert Softwareentwicklung nicht. Deshalb machen wir Wasserfall nicht mehr überall, sondern versuchen, agiler zu sein. Das Erstellen von Software ist sehr komplex, es gibt viel Aufwand, um das Richtige zu entwickeln, und viele Risiken. Stundenschätzungen spiegeln diese nicht wider und zu denken, dass Stunden absolut sind, ist einfach illusorisch. Das hat uns die Geschichte gezeigt. Die Leute sind schlecht darin, zu schätzen, und sie sind schlecht darin, Stunden an diese Schätzungen anzuhängen. Aber es scheint, dass wir die Dinge relativ zueinander besser einschätzen können. Wenn Sie zwei Funktionen haben,

Story Points sind eine Möglichkeit, den Größenunterschied zwischen Features hervorzuheben. Ein 5-SP-Feature ist mehr als ein 3-SP-Feature und weniger als ein 8-SP-Feature. Die Leute sind sich vielleicht nicht einig, dass eine Stunde oder zehn Dollar für alle gleich sind, weil viele subjektive Dinge das beeinflussen, aber sie können zustimmen, dass eine Funktion komplexer ist als eine andere. Eine 5-SP-Story ist eine 5-SP-Story sowohl für den Senior-Entwickler als auch für den Junior-Entwickler. Der Senior braucht vielleicht eine Stunde und der Junior vier Stunden, um es zu bauen, aber das ändert nichts daran, dass dies in Bezug auf die Dinge, an denen beide bisher gearbeitet haben, eine 5 ist.

Anfangs haben die Menschen unterschiedliche Vorstellungen darüber, was eine 5 ist. Der Senior könnte denken, dass 5 einfach ist, der Junior könnte denken, dass 5 schwer ist. Beim Schätzen erhalten Sie also unterschiedliche Werte für dasselbe Merkmal. Aber es gibt eine Diskussion. Die Leute analysieren das Merkmal und erklären, warum sie denken, dass es eine 5 oder eine 1 oder eine 13 oder was auch immer ist. Mit der Zeit finden sie heraus, was eine 5 und eine 1 und eine 13 im Verhältnis zu den anderen Merkmalen ist. Es spielt keine Rolle, wie sie diese Zahl subjektiv erreicht haben, relativ gesehen lernen sie, die gleichen Zahlen mit Merkmalen ähnlicher Größe zu verbinden. Sobald dies geschieht, wissen die Leute, wie viel sie in den Sprint hineinziehen müssen, und die Geschwindigkeit wird relevant. Dann können Sie den Story Points pro Team Stunden hinzufügen, da Sie wissen, wie viel sie pro Sprint liefern können. Aber denken Sie daran, dass es immer noch kein Absolut sein wird. Es gibt ' Es ist kein Zufall, warum Sie Fibonacci zur Schätzung verwenden. Je höher die SPs, desto höher die Unbekannte. Tatsächlich ist es nicht einmal Fibonacci. Eine Fibonacci-Folge ist 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, aber die meisten Planning-Pokerkarten sind 1, 2, 3, 5, 8, 13, 20, 40, 100. Die Dinge kommen abgerundet. Die Zahl 89 ist absolut, 100 ist eine Annäherung. Ist es wirklich wichtig, ob es eine 89 oder eine 90 oder eine 95 ist? Es macht keinen Unterschied. Das ist viel. Sagen Sie also einfach 100 und nennen Sie es einen Tag. 89 oder 90 oder 95? Es macht keinen Unterschied. Das ist viel. Sagen Sie also einfach 100 und nennen Sie es einen Tag. 89 oder 90 oder 95? Es macht keinen Unterschied. Das ist viel. Sagen Sie also einfach 100 und nennen Sie es einen Tag.

Genug geredet...um auf deine Frage zurückzukommen. Die Definition eines SP ist, dass es ein abstraktes Maß für die Schwierigkeit eines Features und den Aufwand ist, der erforderlich ist, um es zu erstellen. Mit der Zeit finden die Leute im Team heraus, was SPs für sie bedeuten (aus diesem Grund können Sie beispielsweise Story Points eines Teams nicht mit den Story Points eines anderen vergleichen; 10 SP in einem Team können 40 SPs bedeuten andere).

Sehen Sie auch, ob dies zusätzliche Einblicke bietet: Warum Story Points anstelle von Stunden zum Schätzen verwenden?

Vielen Dank für eine ausführliche Antwort! Aber es ist immer noch nur ein Glaube. Sie gehen zum Beispiel davon aus, dass es so etwas wie eine Schwierigkeit einer Aufgabe/Funktion gibt. Woher wissen Sie, dass es so etwas überhaupt gibt? Sie sind sich sicher, dass alle Aufgaben eine bestimmte Eigenschaft haben – die Schwierigkeit. Aber sie tun es vielleicht nicht. Und selbst wenn sie es tun, ist es nur ein Glaube, dass wir es als Zahl angemessen schätzen können.
Alle Funktionen erfordern Schwierigkeiten und Mühe, um sie zu erstellen. Das ist kein Glaube. Ist einfach so. Dinge können einfach oder schwer zu tun sein. Dinge können eine kleine oder große Zeit in Anspruch nehmen, um erledigt zu werden. Und alle Dinge bergen Risiken. Wenn Sie schätzen, berücksichtigen Sie all diese Faktoren, egal ob Sie in Stunden oder in SPs schätzen. Ich habe Ihren Kommentar nicht ganz verstanden, aber es geht bei den SPs darum, die Schwierigkeit als Zahl nicht angemessen einzuschätzen. Sie sollten SPs als Boxen betrachten, in die Sie Ihre Features stecken können. Kleinere Kisten, größere Kisten usw. Alle Schätzungen sind...
... höchstwahrscheinlich falsch. Wenn Sie SPs zum Schätzen verwenden, bespricht das Team die Arbeit ausreichend, um herauszufinden, zu verstehen und zu vereinbaren, in welche Box ein Feature gehört. Wie viele Dinge in Agile ist die SP-Schätzung "gerade genug", um den erforderlichen Aufwand zu verstehen (dh ähnlicher Aufwand wie andere ähnliche Funktionen aus der Vergangenheit). Ein 5-SP-Merkmal bedeutet nicht, dass die 5 korrekt ist, es identifiziert nur die Box mit der darauf geschriebenen 5. Sie können später die Zeit für SPs berechnen, je nachdem, wie viele SPs das Team pro Sprint liefert. Wenn Sie direkt in Stunden schätzen, erhalten Sie falsche Absolutwerte ...
... die Sie glauben machen, dass Sie aus der Schätzung greifbare nützliche Informationen erhalten, aber in Wirklichkeit ist dies nicht der Fall. Wenn Sie etwa 10 Stunden schätzen und es tatsächlich 11 Stunden dauert, dann sind Sie mit Ihrer Arbeit zu spät dran. Wenn ein 5-SP-Feature 10 Stunden oder 11 Stunden dauert, dann hat es auch so viel gedauert. Du bist nicht zu spät. So werden 5 SPs in Stunden übersetzt. Nach ein paar Sprints, ein paar Runden SP-Schätzungen, ein paar Velocity-Werten können Sie sich ein Bild davon machen, wie viel die Dinge brauchen. Aber nichts ist absolut, wenn es um Schätzungen geht. SPs drücken diese Tatsache besser aus, als es Stunden tun könnten.
Wozu dienen SPs? Werden sie für ein Sprint-Planning oder für die Planung einer großen Arbeitsmenge (z. B. Epics) verwendet?
Das Team verwendet SPs, um herauszufinden, wie viel Arbeit es in den Sprint ziehen kann. Sobald Sie die Teamgeschwindigkeit für eine Reihe von Sprints haben, können Sie extrapolieren, wie viel andere Arbeit wie Epics oder sogar das gesamte Backlog in Anspruch nehmen wird. Wenn Sie beispielsweise Ihren gesamten Rückstand auf 1000 SPs geschätzt haben und die Geschwindigkeit des Teams im Durchschnitt 100 SPs beträgt, können Sie davon ausgehen, dass Sie alle PBIs in mindestens 10 Sprints abschließen können (ich sage mindestens und nicht genau 10, weil je länger man vorausschaut, desto mehr Ungewissheit und Risiko sind damit verbunden)
Nun, wie schätzen Sie das ganze Epos ein? Sie können schnell etwas Kleines, Beobachtbares, etwas, von dem Sie verstehen, wie man es macht, einschätzen. Epic ist ziemlich groß, das Schätzen eines Epic gibt Ihnen einen großen Schätzfehler. Statt 10 Sprints können es auch 30 Sprints sein – was nützt diese Schätzung? Ich frage das, weil ich mir immer noch nicht sicher bin, wie SPs überhaupt nützlich sein können.
Grundsätzlich ist ein Epic eine sehr große User Story, die andere User Storys enthält. Sie können nicht direkt an einem Epos arbeiten, da es nicht richtig detailliert ist. Sie müssen es in kleinere User Stories aufteilen. Das ist zum Beispiel der Zweck des Refinement Meetings. Das Team diskutiert das Epic, erstellt User Stories mit den entsprechenden Details und schätzt jede Story. Die Epic SPs sind dann die Summe aller User Stories SPs. Bei jeder Art von Schätzungen, einschließlich SPs, müssen Sie die Dinge in kleinere Teile aufteilen, wenn Sie bessere Ergebnisse erzielen möchten, da Sie sonst tatsächlich einen größeren Schätzungsfehler haben.
OK, also verwenden wir SPs nur für die kurzfristige Planung, wenn wir die Arbeit in kleine Teile zerlegt haben. Wir verwenden keine SPs und keinen schnellen Planungspoker, um das Fertigstellungsdatum eines Projekts zu schätzen. Es scheint mir, dass die Verwendung von SPs nur eine Frage der Tatste ist.
@DJClayworth: Schlechte Wortwahl. Was ich meinte war, dass es den Leuten egal ist, wie Sie Schätzungen machen. Danke, dass Sie mich darauf aufmerksam gemacht haben. Die Leute erwarten normalerweise einen Zeitwert von allen Schätzungen. Sogar Ihr Kommentar bekräftigt, was ich sage. Sie sagen "Release im nächsten Monat" und "in der Zeit fertig". Aber schon der ursprüngliche Wortlaut gilt. Wenn Entwickler mit einer Aufwandsschätzung von 13 Story Points zu Ihnen kommen, interessiert es Sie oder möchten Sie stattdessen eine Dauer? Wenn Sie eine Dauer haben, neigen Sie dann dazu, zu versuchen, sie zu reduzieren, wenn Sie nicht mögen, wie viel etwas dauert? Neben all den Dingen, die...
... wurde in diesem Beitrag gesagt, ein Vorteil der Schätzung in SPs besteht darin, dass das obere Management weniger Spielraum hat, um mit den Schätzungen herumzuspielen. Wenn Entwickler 10 Tage sagen, könnten einige versucht sein, Entwickler dazu zu drängen, einen geringeren Wert zu geben ("Können Sie es nicht in 8 Tagen schaffen? Es ist wirklich wichtig, es wird für so und so benötigt, bla bla bla"). Wenn etwas 5 SPs sind, können Sie nicht sagen: "Können Sie daraus 3 SP machen?" weil Sie die tatsächliche Schwierigkeit einer Sache nicht auf die gleiche Weise verringern können, wie Sie dies tun könnten, indem Sie die Zeit verringern, in der Sie daran arbeiten.
Lange Antwort, aber es lohnt sich wirklich, sie zu lesen!

Jede Person in einem Team kann sein persönliches Verständnis der Korrelation zwischen einer Anstrengung und Story Points haben.

In einem neuen Team mag das zunächst stimmen. Aus diesem Grund ist eine auf Story Points basierende Schätzung mehr, als dass jedes Teammitglied nur eine Zahl angibt und dann den niedrigsten/höchsten/durchschnittlichen/was auch immer als endgültige Schätzung nimmt.

Wenn Sie eine Story Point-Schätzung durchführen, sollte dies auch eine Diskussion beinhalten, in der die Teammitglieder erklären können, was sie bei der Berechnung ihres Punktewerts berücksichtigt haben. Es ist wichtig, dass zumindest die Personen mit den höchsten und niedrigsten Schätzungen gehört werden, da sie wahrscheinlich spezifische Einblicke in das jeweilige Thema haben. Dies kann auch Einblicke in Risiken und/oder Ungewissheiten beinhalten, die mit der jeweiligen Arbeitsaufgabe verbunden sind.

Durch diese Diskussionen erhalten die Teammitglieder auch ein gemeinsames Verständnis für die Kombination aus Aufwand, Komplexität und Risiko, die in einen Story Point einfließt.

Um zu unterstreichen, dass die Schätzung keine exakte Wissenschaft ist, und um endlose Debatten darüber zu vermeiden, ob ein Arbeitselement 40 oder 41 Punkte haben sollte, haben Schätztechniken wie Planungspoker (die üblicherweise zum Schätzen von Story Points verwendet werden) eine Granularität von Schätzungen, die so angegeben werden können steigt mit der Größe der Schätzungen selbst.

Wie kommen sie zu einem gemeinsamen Risikoverständnis? Die Risikoeinschätzung hängt von der persönlichen Erfahrung ab. Warum sollten wir uns mit diesen verschleierten SP beschäftigen, anstatt nur Stunden zu verwenden?
@ChrisBrettini, wie sammelt man Erfahrungen beim Einschätzen (und Erkennen) von Risiken? Ich hoffe nicht nur aufs Nasenschlagen, sondern auch auf andere, die darauf hinweisen können, bevor man sich auf die Nase schlägt. Und da kommen die Diskussionen ins Spiel, denn da kann jemand die anderen Teammitglieder auf das Risiko hinweisen.
@ChrisBrettini Das Team kommt durch Erfahrung zu einem gemeinsamen Verständnis. Je länger ein Team als Team existiert, desto mehr stimmen ihre eigenen persönlichen Vorstellungen davon, was ein Story Point wert ist, tendenziell überein. Wenn Sie die Mitglieder eines Teams ändern, gibt es eine Phase der Anpassung, in der ihre individuellen Schätzungen stärker voneinander abweichen, und sie müssen diskutieren und sich darauf einigen, welche Anzahl verwendet werden soll. Mit der Zeit werden sie anfangen, die gleichen Zahlen vorzuschlagen, sie erfordern weniger Diskussionen und ihre Geschwindigkeit von Punkten pro Sprint wird konsistenter. Ich habe das bei mehreren Firmen erlebt. Es klappt.

Mike Cohn hat einen großartigen Artikel über Story Points . Einige der Highlights sind

Story Points sind eine Maßeinheit, um eine Schätzung des Gesamtaufwands auszudrücken, der erforderlich ist, um ein Product-Backlog-Element oder eine andere Arbeit vollständig umzusetzen.

...

Da Story Points den Aufwand darstellen, eine Story zu entwickeln, muss die Schätzung eines Teams alles beinhalten, was den Aufwand beeinflussen kann. Das könnte beinhalten:

  • Die Menge der zu erledigenden Arbeit
  • Die Komplexität der Arbeit
  • Jedes Risiko oder jede Ungewissheit bei der Ausführung der Arbeit

...

Eine Story-Point-Schätzung muss alles beinhalten, was dazu gehört, ein Produkt-Backlog-Element vollständig fertigzustellen. Wenn die Definition of Done eines Teams die Erstellung automatisierter Tests zur Validierung der Story beinhaltet (und das wäre eine gute Idee), sollte der Aufwand für die Erstellung dieser Tests in die Story Point-Schätzung einbezogen werden.

Story Points können ein schwer zu verstehendes Konzept sein. Aber der Aufwand, um vollständig zu verstehen, dass Punkte den Aufwand darstellen, der durch den Arbeitsaufwand, die Komplexität der Arbeit und jedes Risiko oder jede Unsicherheit in der Arbeit beeinflusst wird, wird sich lohnen.

Ja, aber er gibt keine Regeln, wie man jede persönliche Prognose des Arbeitsaufwands, der Komplexität, der Risiken in eine Ein-Zahlen-Schätzung umwandelt. Also, wie gesagt, jeder versteht Stoty Points anders. Was nützen sie dann...
Sie definieren sie als Team. Ich meine, Sie kommen als Team zum letzten SP für eine User Story. Man kommt also zu einer Einigung, denn wenn man einen eher niedrigen SP oder hohen SP wählt, dann beginnt eine Diskussion, um zu verstehen, was zu dieser Entscheidung geführt hat. Jedes Mal, wenn ich SP verwendet habe, gab es nur ein oder zwei Mal, dass das Team nach Diskussionen keine vollständige Einigung erzielte. Ist das sinnvoll?
Nicht wirklich. Bei der Vereinbarung von SP geht es darum, Dinge zu benennen – der eine kann eine Story mit „10 Story Points“ bezeichnen, der andere mit „5 Story Points“. Aber das sind nur Bezeichnungen – zwei verschiedene Personen können derselben Sache unterschiedliche Bezeichnungen geben. Und es ist schwierig, ein gemeinsames Verständnis dessen zu erreichen, was wir 1SP, 2SP usw. nennen
Sie sind Bezeichnungen, die sich, wie Mike Cohn erklärt, in der Anstrengung niederschlagen, ein bestimmtes US zu entwickeln. Sie haben ein Ziel und das sind Ihrer Erfahrung nach 4 SP. Ihr anderes Teammitglied erkennt etwas, das Sie nicht bemerkt haben, was die Unsicherheit erhöht, und entscheidet sich für 12 SP. Dann werden Sie diskutieren, um zu verteidigen, warum. Sie stellen fest, dass Sie diesen Teil, der unsicher ist, nicht berücksichtigt haben, und stellen fest, dass 4 vielleicht nicht sehr gut ist. Sie entscheiden sich also, 8 oder 12 oder sogar mehr zu geben.
Der Scrum Master gibt oft eine Grenze vor. Ist nicht wie "Hey alle zusammen, wählen Sie eine Zahl von 1-100". SM kann so etwas sagen wie "2-4-8-16-32-64"
Wenn Sie innerhalb dieses Bereichs 32 SP für einen sehr, sehr einfachen US auswählen (was bedeutet, dass es ziemlich komplex oder unsicher ist oder viel Arbeit erfordert), dann bin ich sicher, dass Ihre anderen Teammitglieder nicht damit einverstanden sind, 32 SP zu geben zu diesen USA.
Aber ohne die gemeinsamen Regeln werden diese Nummern wirklich unzuverlässig gewählt und vereinbart. Wie können Sie etwas besprechen und vereinbaren, für das Sie keine Definition haben?
Mit Plannning Poker können Sie sicher einige Schätzungen erhalten, aber die Frage ist, wie genau sind diese Schätzungen? Wenn die Genauigkeit nur 30 % beträgt, sind diese Schätzungen ziemlich nutzlos. Und woher wissen Sie die Genauigkeit?
Das ist für mich eine Definition «Story Points sind eine Maßeinheit, um eine Schätzung des Gesamtaufwands auszudrücken, der erforderlich sein wird, um ein Product Backlog Item oder eine andere Arbeit vollständig umzusetzen.»
Aber Stunden sind auch "eine Maßeinheit, um eine Schätzung des Gesamtaufwands auszudrücken, der erforderlich sein wird, um ein Product Backlog Item oder eine andere Arbeit vollständig umzusetzen". Warum nicht Stunden verwenden?
Es gibt viele Faktoren, die die Präzision beeinflussen. Fähigkeiten Ihrer Entwickler ist eine.
Ja. Woher wissen wir also am Ende des Tages, dass SP nützlicher sind als Stunden? Stunden haben zumindest die Eigenschaft, von allen Teammitgliedern gleich verstanden zu werden.
Sie können Stunden verwenden, wenn Sie möchten. Aber die Zeit, die man braucht, um etwas zu erreichen, drückt nicht die Anstrengung aus. Dieselbe Logik gilt, wenn Sie nach Stunden bezahlt werden, dann ist die Art und Weise, wie Sie Aktivitäten / Aufgaben erledigen, anders, als wenn Sie nach Aktivität / Aufgabe bezahlt werden.
Das ist der wahre Grund? Um Zeitdruck zu vermeiden und Entwickler sich auf die Qualität konzentrieren zu lassen, anstatt den Fertigstellungstermin einzuhalten?
Sehr einfache und sich wiederholende Aufgabe - 3 Stunden. Schwere Aufgabe - 1 Stunde.
Das Entwicklungsteam arbeitet innerhalb der Grenzen des Sprints. Sie wollen die USA liefern, die sie zu Beginn des Sprints versprochen haben. Es ist eher aktivitäts- / aufgabenorientiert.
Warum nicht einfach die harte Aufgabe 5 Stunden dauern lassen?
Wenn sie wirklich liefern wollen, was sie versprochen haben, sollten sie danach streben, genau in Stunden zu schätzen, um vorherzusagen, was für den Sprint ausgewählt werden könnte – es ist nicht aufgabenorientiert, es ist stundenorientiert. Ich bin mir nicht sicher, was Sie mit harten letzten 5 Stunden meinen - verschiedene Aufgaben dauern unterschiedliche Zeiten
Länger zu dauern bedeutet nicht, dass es schwieriger ist.
Aber was müssen wir wissen, wenn wir ein Projekt machen? Wir müssen die Zeitdauer kennen, richtig? Nicht der Härtegrad. Den Kunden interessiert es nicht, ob es schwer ist oder nicht - er möchte wissen, wie lange es dauert.
SP sind langfristig nützlicher. Sie werden wissen, dass „mein Team in der Lage ist, X während eines Sprints zu handhaben“.
Und Sie werden wissen, was X IRL bedeutet, weil Sie Metriken haben werden.
Aber warum müssen wir dieses X kennen? Wie verwenden wir dieses X? Welche Metriken?
Aus verschiedenen Gründen. Das Entwicklerteam kann anhand seiner durchschnittlichen Leistung nachvollziehen, wann der beste und wann der schlechteste Moment war, wie es sich verbessern kann. Wissen Sie, ob und warum Sie mehr Leute brauchen.
Wir müssen zuerst beweisen, dass es eine starke Korrelation zwischen SP und der Leistung gibt. Vielleicht wollen wir nur an SP glauben.
Hast du auch einen für Stunden?
Wenn wir über Stunden sprechen, ist es einfacher, einander zu verstehen, das Gespräch wird konkreter, wir können die Schätzung genauer ausführen und erhalten eine zuverlässigere Zeitmenge. Das Veröffentlichungsdatum wird zuverlässiger. Das ist für mich das reizvollste Eigentum des Hauses.
Dan Radigan - «Stunden berücksichtigen nicht die nicht projektbezogene Arbeit, die sich unweigerlich in unsere Tage einschleicht (E-Mails usw.). Stunden haben eine emotionale Bindung. Jedes Team schätzt die Arbeit auf einer etwas anderen Skala, was bedeutet, dass ihre Geschwindigkeit (gemessen in Punkten) natürlich unterschiedlich sein wird. Dies wiederum macht es unmöglich, Politik mit Geschwindigkeit als Waffe zu betreiben. Story Points belohnen Teammitglieder für das Lösen von Problemen basierend auf dem Schwierigkeitsgrad und nicht auf der aufgewendeten Zeit (Dadurch konzentrieren sich die Teammitglieder auf den Versandwert und nicht auf den Zeitaufwand).»
@ChrisBrettini Story Points sind genauer, weil Menschen notorisch schlecht darin sind, Zeit abzuschätzen. Es ist schwer, eine Anzahl von Stunden abzuschätzen, um „es besteht noch eine gewisse Unsicherheit darüber, wie dies implementiert wird“. Es ist einfach, eine Aufgabe mit etwas zu vergleichen, das Sie zuvor erledigt haben, und zu entscheiden, ob sie größer, kleiner oder ähnlich ist. Die Punkte sind absichtlich nicht in allen Teams gleich, was bedeutet, dass Sie zu Team A nicht sagen können: "Hier, Team B sagt, das sind vier Tage Arbeit, also brauchen Sie vier Tage, oder?" Team A muss es selbst schätzen, was das Problem des „mythischen Mannmonats“ entschärft.
Auch „Den Kunden interessiert es nicht, ob es schwer ist oder nicht – er möchte wissen, wie viel Zeit er benötigt“, das stimmt, aber der Kunde sollte keine Story Points sehen. Story Points haben für niemanden außerhalb des Teams, das die Storys geschätzt hat, eine Bedeutung. Die Punkte können verwendet werden, um zu entscheiden, wie viel Arbeit in einen Sprint passt, und an diesem Punkt ist es sehr wichtig, ob es schwer ist oder nicht. Story Points können verwendet werden, um abzuschätzen, wie viele Sprints an Arbeit sich in Ihrem Backlog befinden, was verwendet werden kann, um Ihrem Kunden das geschätzte gewünschte Lieferdatum mitzuteilen. (Beachten Sie, dass sich dies im Laufe der Zeit ändern wird).
@anaximander Story Points zu verwenden, um abzuschätzen, wie lange die Arbeit im Backlog dauern wird, ist problematisch und ich würde mich davon fernhalten. Story Points haben keinen zeitlichen Bezug. Sie werden einfach im „Jetzt“ verwendet, um zu vergleichen, wie groß etwas mit etwas anderem ist. Der Versuch, Zeit und Schätzungen daraus zu extrapolieren, ist ein Rezept für eine Katastrophe.
@GeorgeStocker Ich stimme voll und ganz zu, und ich habe gesehen, dass es alle möglichen Probleme verursacht hat (ein Ort, an dem ich gearbeitet habe, hat sogar „berechnet“, dass ein Story Point 2,5 Stunden wert ist, und alles darauf basiert, was wirklich nicht funktioniert hat). Was ich meine ist, dass Sie Story Points und Geschwindigkeit verwenden können, um zu entscheiden, wie viel Arbeit in Ihren Sprint passt (was normal ist), und dies kann extrapoliert werden, um sehr grob abzuschätzen, wie viele Arbeitssprints im Rückstand sind, aber wenn ich sagen, es wird sich verschieben, ich meine das wirklich, diese Art von Schätzung ist nur auf einen, vielleicht zwei Sprints in der Zukunft genau.

Ohne externe Messgeräte kann ich zwei Tassen Wasser vergleichen und erraten, welche voller ist als die andere.

Ich kann Ihnen nicht sagen, wie viel Flüssigkeit genau in die Tasse passt, und ich kann Ihnen auch nicht sagen, ob das Überlaufen der Flüssigkeit von einer Tasse in die andere ohne Versuch zum Überlaufen führt. Wenn beide wirklich satt sind, habe ich vielleicht eine gewisse Fähigkeit dazu; aber es hängt von der relativen Größe der Becher ab und davon, wie viel Wasser in jedem zu sein scheint.

Mein Punkt ist: Während ich Schlussfolgerungen und Schlussfolgerungen ziehen kann, versuche ich, die beiden Tassen miteinander zu vergleichen; Ich kann Ihnen nicht viel mehr sagen, weil es ohne genauere Messungen und einen wissenschaftlichen Prozess nicht erkennbar ist.

Softwareentwicklung ist alles andere als ein wissenschaftlicher Prozess – es ist so weit von der Wissenschaft entfernt, wie es nur geht. Ich denke, deshalb nennen wir es "Softwareentwicklung" und nicht "Softwarewissenschaft".

Story Points werden verwendet, um die Arbeit mit der im selben Sprint erledigten Arbeit zu messen; und ihre Werte sind relativ zu der geleisteten Arbeit. Ähnlich wie das Wasser in der Tasse haben sie keine Messung oder Relevanz für die Arbeit, die in der Vergangenheit oder noch zu erledigen ist – das erfordert Messungen, die wir nicht haben, weil wir nicht wirklich in der Lage sind, die Veränderungen in der Umgebung zu messen die dazu führen, dass Software erstellt oder nicht erstellt wird.

Beispielsweise kann Folgendes die Geschwindigkeit beeinflussen:

  • Neues Teammitglied
  • Bug enthält eine Abhängigkeit, von der wir nichts wussten
  • Teammitglied hat ein Problem mit einem anderen Teammitglied
  • Ein Upgrade der Softwareentwicklungsumgebung verursacht unvorhergesehene Nebenwirkungen
  • NPM sinkt
  • Nach Beginn der Entwicklung stellt ein Entwickler fest, dass das Problem tiefer liegt, als wir dachten
  • Ein Entwickler wird durch den „klugen“ Code eines anderen Entwicklers verwirrt
  • Jeder der hier aufgeführten Artikel .

Mein Punkt ist, dass jede Schätztechnik, die versucht, etwas anderes zu tun, als die Arbeit, die direkt vor Ihnen liegt, mit der Arbeit zu bewerten, die auch direkt vor Ihnen liegt, zu extremer Enttäuschung führt.

Es gibt zwei Möglichkeiten, dies zu umgehen:

  1. Zerlegen Sie die Arbeit so klein, dass sie leicht zuverlässig geschätzt werden kann.
  2. Arbeiten Sie an einer Sache nach der anderen, wobei das gesamte Team daran arbeitet, um sicherzustellen, dass es keine blinden Flecken oder Spuren gibt, die kollidieren können ( Mob-Programmierung ).

Die meisten Teams, die ich gesehen habe, die auf Probleme mit Story Points gestoßen sind, haben versucht, sie als eine Art Schätzung dafür zu verwenden, wie viel Arbeit in einem Sprint zuverlässig in einer dynamischen Umgebung erledigt werden kann. oder die Geschwindigkeit über die Zeit vergleichen, oder sie als zuverlässige Messung der absoluten Schätzung betrachteten.

Die Zwei-Tassen-Wasser-Analogie erklärt ziemlich genau, woher der Wert eines Punktes kommt. Bei zwei verschiedenen Bechern könnte man erkennen, dass ihre Größen etwa ein Verhältnis von 3:5 haben (zum Beispiel), aber das bedeutet nicht, dass der kleinere Becher 3 Liter oder drei Pints ​​oder drei einer bestimmten Einheit fasst, es ist nur ungefähr drei Fünftel des größeren. Es erklärt auch die Verwendung von Fibonacci-Zahlen - bei einem sehr großen Becher können Sie den Unterschied zwischen 25: 3 und 26: 3 wahrscheinlich nicht sehr genau erkennen, aber Sie könnten wahrscheinlich entscheiden, ob es näher an 21 oder 34 lag.
Definition eines Story Points [geschlossen]
AntwortenHierDatenschutz-Bestimmungen1y, 0v