Warum entsprechen Story Points einer Story nicht geschätzten Tagen/Stunden? Im Scrum [Agil]

Ich arbeite derzeit in einem Team mit neuen bis agilen Methodenprogrammierern und einigen Old-School-Peeps.

Sie scheinen bei Planungsmeetings immer Stunden/Tagesschätzungen für eine Geschichte zu geben. Es kotzt mich wirklich an und ich versuche ihnen zu sagen, dass es Komplexität/Aufwand bedeutet.

Also fragt mein Senior nach einem Beispiel, warum Stunden/Tag-Schätzungen falsch sind, weil es hier zu funktionieren scheint.

Ich kann ihnen anscheinend nicht erklären, dass dies ihre Velocity-Berechnungen, die Pflege des Backlogs und die Release-Planung durcheinander bringen wird und ein falsches Bild der brennenden Fähigkeiten der Teams für die Po/PM und Leads vermittelt.

Um fair zu sein, vielleicht konnte ich es ihnen nicht richtig erklären.

Sie hatten eine Frage wie, was schätzen Sie eine Geschichte, die 4-5 Stunden Migration erfordern würde. Angenommen, die Migration dauert 2 volle Tage. Meine Antwort ist, dass es sich möglicherweise um ein triviales Skript handelt, aber die Zeit hat nichts mit der Schätzung der Story Points zu tun. Hören Sie auf, Äpfel und Birnen zu vergleichen.

Kann mir jemand mit ein paar überzeugenden Beispielen weiterhelfen. Weil die einzige Scrum-Praxis, die hier drinnen richtig gemacht wird, anscheinend das tägliche Standup ist.

Hier gibt es mehrere Standpunkte, und wer sagt, welcher richtig ist.
Klassische Story Points bleiben von konkreten Einheiten fern, um einem Team zu helfen, sich auf relative Komplexität zu konzentrieren und seinen eigenen Rhythmus zu finden. Mit genügend Zeit und Konsistenz werden diese Story Points auf Zeiteinheiten übertragbar. Einige Teams sind in der Lage, direkt in Zeiteinheiten zu schätzen. Gut für sie. Ich interessiere mich mehr dafür, warum, wie Sie sagten, "es macht Sie wütend". Andere Standpunkte sind, dass man nicht mehr als klein, groß und groß schätzen muss oder was innerhalb von ein oder zwei Tagen erledigt werden könnte, andere verzichten auf die Notwendigkeit, alles zusammen zu schätzen und sich auf die Optimierung des Arbeitsablaufs zu konzentrieren.
Ich schlage Ihnen vor, dass die wichtigste Eigenschaft für das Team ist, „kann sich das Team als Ganzes selbst optimieren“, das heißt, weiß das Team, wo es hin will (Vision), weiß, wo es gerade steht (Messen) und arbeitet ihre Fähigkeit, die Zielrichtung immer effizienter und effektiver anzusteuern, zu verbessern?
Persönlich, für alle außer den grundlegendsten und vorhersehbarsten Aufgaben oder komplexeren Aufgaben, die ich oft genug erledigt habe, damit sie einfach / routinemäßig geworden sind, aber ich habe noch nicht automatisiert (schade über mich), dann funktioniert die Schätzung in Stunden und Tagen. Für alles andere ist das Schätzen in Stunden und Tagen eine Illusion von Vorhersagbarkeit und Kontrolle. Eine, an der sich viele als eine Form der Lebensader festhalten, da ihnen die Alternativen zu beängstigend erscheinen. Folgendes könnte für Sie interessant sein: scrumexpert.com/knowledge/…
Denken Sie schließlich daran, dass Menschen dazu tendieren, das, was sie wissen, so zu tun, wie sie es zuvor getan haben. Die Tatsache, dass Ihre Kollegen mit ihren alten Gewohnheiten brechen, muss gefeiert werden. Denken Sie nur daran, dass Rom nicht an einem Tag gemacht wurde und dass sie Veränderungen weniger beängstigend finden werden, wenn sie eine Gewohnheit nach der anderen brechen, anstatt alles mit einem großen Knall zu ändern. Ironischerweise zeigen Studien auch, dass dies der schnellste Weg ist, um komplexe/große Veränderungen zu erreichen, da Big-Bang-Veränderungen zunächst zu großen Veränderungen führen und dann langsamer werden und scheitern, während iterative Veränderungen langsamer beginnen, aber an Tempo und Dynamik gewinnen.
@ ChrisK .... danke. Ich denke, es wird dann immer diskutiert werden. Worüber ich mir Sorgen mache, ist, dass es 8-9 Monate her ist und die Effizienz und die Fähigkeit, Funktionen auszuteilen, sich nicht einmal verbessert hat, tatsächlich habe ich das Gefühl, dass es meine Arbeit beeinträchtigt und beeinflusst. Es ist ein süßes und junges Team. Aber ich spüre auf Dauer, wenn sich wirklich komplexe Arbeit anhäuft. Es würde sich selbst zerstören. Aber danke für diese Links, ich werde sie weiter lesen.
@yudois, das sind wichtige Beobachtungen über das Team, die Sie machen. Was fühlt das Team? Sind sie mit der Fortschrittsrate zufrieden, haben sie das Gefühl, dass sie noch lernen und sich verbessern? Denken sie jede Woche über ihre Fähigkeit nach, immer höhere Standards zu liefern?
@yudois Unsere größte Fähigkeit, ein Team zu größeren Höhen zu beeinflussen, kommt nicht von einer Technik, sondern von unserer Fähigkeit, eine Umgebung zu schaffen, die dem Lernen und Verbessern förderlich ist. Meine Beobachtung ist, dass, wenn ich mich falsch fühle (selbst wenn ich falsch liege), ich einraste und defensiv werde. Meine Lern- und Anpassungsfähigkeit wird beeinträchtigt. Die Lektion, die ich aus dieser Beobachtung gelernt habe, ist, andere nicht zu drängen und ihnen zu sagen, dass sie falsch liegen, sondern sie stattdessen zu fragen, was sie erreichen wollen. Und dann helfen Sie ihnen, dies mit größerer Wirkung zu erreichen, als sie sich erhofft hatten.
@ChrisK ... "Zurückziehen und beobachten" ist das, wozu ich mich jetzt zurückgezogen habe ... Ich werde versuchen, sie zu fragen, was der Ansatz ist. Und ja, ich glaube nicht, dass das Team es weiß, oder vielleicht ist Arbeit nur ein Mittel zum Zweck für sie. Na danke trotzdem.
gerne geschehen und viel Glück. Seien Sie jedoch vorsichtig, wenn Sie sich damit abfinden, wie die Dinge sind, ich bin auch zu oft darauf hereingefallen.
Teams profitieren davon, jemanden zu haben, der schlecht reagiert, wenn die Dinge schlecht laufen, da er für den Rest als Frühwarnalarm fungiert. Lassen Sie sich nur nicht auf einen einzigen Weg zur Lösung eines Problems festlegen. Oft ist es besser zu lernen, das Problem gut zu kommunizieren/zu demonstrieren und es dann vom Team lösen zu lassen. Entwickler sind natürliche Problemlöser, so viele von uns hassen es, wenn man ihnen sagt, dass wir falsch liegen, aber wir lieben es, zu helfen, Dinge zu verbessern und zu lösen. Konzentrieren Sie sich auf diese Stärken.
IMHO gibt es dafür bereits eine Reihe möglicher enger Ziele auf der Website, die sich auf den Wert der relativen Größe für die agile Schätzung beziehen. Wenn nicht, muss die Frage möglicherweise so bearbeitet werden, dass sie weniger eine Frage am Arbeitsplatz ist.
Story Points sollten 4 Dimensionen berücksichtigen: - Volumen - Komplexität - Wissen - Unsicherheit

Antworten (3)

Im Scrum Guide steht nichts , was besagt, dass die Schätzung in Punkten erfolgen muss. Es gibt auch nichts, was besagt, dass Items im Product Backlog oder Sprint Backlog User Stories sein müssen.

Wenn Ihr Team gut darin ist, seine Sprints zu planen und auszuführen, während es die Elemente im Rückstand in Stunden oder Tagen schätzt, warum haben Sie dann das Bedürfnis, dies zu ändern?

Sie geben an, dass dies „ihre Velocity-Berechnungen, das Backlog-Grooming und die Release-Planung durcheinander bringen“ und dem Product Owner und den Leads ein falsches Bild über den aktuellen Status vermitteln wird. Schauen wir uns das einmal an.

Zuerst Geschwindigkeitsberechnungen. Velocity ist kein Bestandteil von Scrum. Der Scrum Guide erwähnt das Wort „Velocity“ überhaupt nicht. Geschwindigkeit ist ein gängiges Maß, aber Sie können es immer noch mit Stunden berechnen. Geschwindigkeit ist einfach die Menge an Arbeit, die in einer bestimmten Zeit erledigt wird. Oft sind das Story Points pro Sprint, aber das muss nicht sein. Genauso gut könnten es „Stunden wertschöpfender Aufwand pro Sprint“ sein. Wenn Sie Backlog Items in Stunden schätzen und wissen, wie viele Stunden ein Sprint hat (Anzahl der Personen * Anzahl der Arbeitstage * Arbeitsstunden pro Tag), können Sie "Vorgangsstunden" durch "Gesamtstunden in einem Sprint" dividieren, um zu erhalten deine Geschwindigkeit. In einer perfekten Welt wird jede Arbeitsstunde mit wertschöpfender Arbeit verbracht. Aber das ist nicht immer wahr,

Zweitens, Rückstandspflege. Im Scrum Guide heißt das jetzt „Refinement“ oder „Product Backlog Refinement“. Es ist einfach das Hinzufügen von Details, Schätzungen und Reihenfolgen zum Product Backlog. Die Einheiten, die Sie für die Schätzung verwenden, haben keinen Einfluss auf den Akt der Verfeinerung. Nach der Verfeinerung sollten Sie Product Backlog Items haben, die detailliert genug sind, damit das Entwicklungsteam daran arbeiten kann, mit einer Schätzung versehen und auf der Grundlage des aktuellen Verständnisses richtig geordnet sind, damit sie in einen Sprint gezogen werden können.

Als nächstes Release-Planung. Wenn Sie über ein ordnungsgemäß geordnetes Product Backlog mit Schätzungen zu jedem Element verfügen und Ihre Geschwindigkeit kennen, sollte die Release-Planung einfach sein. Sie sollten in der Lage sein, die Top-n-Elemente abzurufen, bis die Gesamtschätzung Ihrer Geschwindigkeit entspricht, die diese im nächsten Sprint liefert, wobei alle Abweichungen berücksichtigt werden (Personen, die Urlaub oder Krankheit nehmen, Feiertage, alle Arten von Arbeitsereignissen, die nicht mit den Elementen verbunden sind). im Sprint usw.).

Abschließend abbrennen. Wenn Sie in geschätzten Stunden messen und die im Sprint verbleibenden Stunden nachverfolgen, können Sie sich immer noch eine gute Vorstellung vom Abbrennen machen und es bei jedem Daily Scrum betrachten oder in Ihren Tools sichtbar machen. Unabhängig von Ihren Schätzungseinheiten sollten Sie am Ende Ihres Sprints bei 0 sein. Burndown ist nur eine grafische Darstellung dessen, wie Sie Ihre Arbeit in Ihrer Timebox abschließen.

Nun, nur weil Sie etwas anderes als Punkte verwenden können, heißt das nicht, dass es unbedingt eine gute Idee ist. Es gibt viele Beiträge zu den Vorteilen der Verwendung von Punkten – siehe diese Frage zu Software Engineering Stack Exchange , diese Frage zu Project Management Stack Exchange , diesen Beitrag von Scrum, Inc. , diesen Beitrag von Mountain Goat Software und diesen Beitrag zu Agile Buddha . Das Schätzen in Stunden ist jedoch kein Problem für die Durchführung von Scrum, insbesondere wenn es für Ihr Team funktioniert.

Betrachten Sie die Prinzipien hinter dem Agilen Manifest und den Scrum-Werten . Wenn Ihr Team behauptet, agil zu sein, sollte es sich an die Prinzipien des Agilen Manifests halten, unabhängig davon, welche Implementierung für es am besten funktioniert. Wenn Ihr Team behauptet, Scrum zu folgen, sollte es den Scrum-Leitfaden und die Scrum-Werte befolgen, unabhängig von der Umsetzung der einzelnen Aktivitäten. Wenn Ihr Team diese Prinzipien nicht befolgt, können Sie daran arbeiten, Ihr Team zu ihnen zu führen, aber das Team muss herausfinden, welche Methode zur Befolgung dieser Prinzipien für es am besten funktioniert. Sie können Ihre Gedanken teilen, aber dem Team nicht Ihren Willen aufzwingen.

Tolle Verweise auf den Scrum Guide! Beachten Sie auch, dass Burn-Down-Charts keine Rahmenvoraussetzung sind.

Es gibt keinen Leitfaden für Scrum, ob Sie Story Points oder Stunden für Ihre Schätzungen verwenden sollten, dies liegt ganz im Ermessen des Teams und dessen, was für sie funktioniert. Jedes Team ist anders und was für das eine funktioniert, funktioniert möglicherweise nicht für das andere.

Um Ihre Frage zum großen Vorteil von Story Points zu beantworten:

  • Story Points beziehen sich auf die Schwierigkeit und nicht auf die Zeit, da nicht jeder die gleiche Zeit benötigt, um dieselbe Aufgabe zu erledigen. Für einen Jr-Entwickler kann das Erstellen eines einfachen Bildschirms 2 Tage dauern, aber für einen Sr-Entwickler kann es 4 Stunden dauern. Die Zeitschätzung für diese beiden Ressourcen ist unterschiedlich, während die Schwierigkeit der Aufgabe dieselbe ist.
  • Eine der Grundlagen von Scrum ist ein selbstorganisiertes Team, das sich vollständig darauf konzentriert, alle Aufgaben, denen es sich verpflichtet hat, als Team zu erledigen. Eine der Möglichkeiten, diesen Teamgeist zu erreichen, besteht darin, Aufgaben nicht in der Sprintplanung zuzuweisen, sondern Ressourcen Aufgaben übernehmen zu lassen, wenn sie frei sind. Wenn Aufgaben nach Zeit geschätzt werden, kann dies zu Problemen führen (z. B. das obige Beispiel wird in 4 Stunden geschätzt und vom Jr.-Entwickler übernommen, der 2 Tage benötigt, um es abzuschließen). Nicht alle Aufgaben zu Beginn des Sprints zuzuweisen hilft, das übliche „Das war nicht meine Aufgabe, ich habe alle meine zugewiesenen Aufgaben erledigt“ zu vermeiden.

Wenn die Aufgaben einfach sind und die Unsicherheit gering ist, wird es für manche schwierig sein, den Nutzen von Story Points gegenüber konkreten Einheiten wie 2 Tagen oder 4-5 Stunden zu erkennen. Der Vorteil der Verwendung von Story Points wird deutlicher, wenn Aufgaben geschätzt werden, die komplex sind und/oder etwas mit einem gewissen Grad an Ungewissheit tun.

Zwei kurze Argumente, die vielleicht helfen, jemanden zu überzeugen:

  • In den meisten Fällen sind Schätzungen mit konkreten Einheiten sehr ungenau, wenn der Grad der Komplexität und/oder Unsicherheit hoch ist ; dennoch implizieren diese Schätzungen in Stunden Gewissheit .

    Beispiel: Eine Schätzung von 75 Stunden scheint zu implizieren, dass ein Entwickler dies im Laufe von zwei Wochen tun könnte oder zwei Entwickler es problemlos in einer Woche tun könnten. Es gibt keinen Hinweis auf Komplexität oder Unsicherheit. Es gibt auch keinen wirklichen Grund zu der Annahme, dass die Aufgabe aufgeteilt werden muss oder dass die Gefahr einer Überschreitung besteht.
  • Schätzprozesse, die Story Points verwenden (und eine Abstraktion wie die Fibonacci-Reihe 1, 2, 3, 5, 8, 13, 20, 40, 100), neigen dazu , neben Aufwand auch Unsicherheit und Komplexität zu vermitteln.

    Zum Beispiel: In einer hohen Zahl (40 Story Points) liegt eine Bedeutung. 40 Story Points implizieren Komplexität oder Risiko in einer Weise, die 40 Stunden oder 75 Stunden nicht haben. Es ist auch viel einfacher, den Unterschied zwischen einer relativ gut definierten großen Aufgabe (13 Punkte) und einer viel unsichereren Aufgabe (40 Punkte) sofort zu erkennen und anzugeben, was darauf hindeuten kann, dass der Kunde auf eine Verzögerung oder Komplikation vorbereitet sein sollte.

Ebenfalls wichtig: Der PO- oder Scrum-Master kann die Bedeutung einer bestimmten Story-Point-Bewertung nicht vordefinieren. Die Bedeutung der Story-Point-Bewertungen ist für jedes Team einzigartig. Eine 13-Story-Point-Bewertung wird für ein bestimmtes Team nur dann etwas bedeuten, nachdem sie ein wenig Planungspoker zusammen gespielt haben und nachdem sie einige Baseline-Storys und Sprints haben, aus denen sie Einblicke in die Genauigkeit ihrer Schätzungen gewinnen können.

Ich würde argumentieren, dass jedes Team, das eine Baseline-Story von einem Punkt verwendet, niemals eine Story mit mehr als 13 Punkten haben sollte. Es ist ein völliger und grober Missbrauch von Story Points zu sagen, dass sie eine Geschichte haben, die 40-mal komplexer oder sogar 100-mal komplexer ist als ihre Basislinie. Wenn Ihre Geschichten nicht 13 Punkte oder weniger als 13 Punkte haben, hat die Verwendung von Story Points keinen Vorteil. Es ist nur das Zuordnen willkürlicher Zahlen zu Hirngespinsten der Team-Phantasie.
Passen Sie sie entsprechend Ihrem Baseline-Story-Wert an, aber das 13-fache der Baseline sollte das Maximum sein, bevor eine Story aufgeteilt werden muss, und alles über dem 13-fachen der Baseline sollte in der Sprint-Planung abgelehnt werden.
Warum entsprechen Story Points einer Story nicht geschätzten Tagen/Stunden? Im Scrum [Agil]
AntwortenHierDatenschutz-Bestimmungen1y, 0v