Alternativen zur Schätzung in Stunden/Story Points

Wir wollen unseren Ansatz für Schätzungen ändern. Jetzt schätzen wir in Stunden/Tagen, aber wir würden dies gerne ändern und unseren Prozess flexibler gestalten. Wir arbeiten auf Basis von Scrum, wo Stories basierend auf einer anfänglichen Schätzung geplant werden und nach der technischen Analyse eine neue Schätzung verwendet werden kann (die verfeinert ist).

Da wir festgestellt haben, dass unser Schätzprozess verbessert werden kann, suchen wir nach Alternativen. Ich habe bereits online eine Dokumentation gefunden, in der es darum geht, Story Points und Geschwindigkeit zu verwenden, um den Aufwand anzugeben, der erforderlich ist, um etwas zu implementieren.

Gibt es neben Story Points/Velocity noch Alternativen? Ich habe online gesucht, aber ich finde keine guten Quellen mit Alternativen.

Können Sie einige Details angeben, warum das Lesen der Ergebnisse des Googelns von "Scrum-Schätzmethoden" nicht gut genug ist?
Um ehrlich zu sein, diese Frage ist für StackExchange ungeeignet, da es keine einzige gute Antwort gibt, aber Sie haben unten eine ganze Reihe guter Antworten, die Ihnen helfen sollten.
@Daniel Obwohl die Frage verbessert werden könnte, denke ich, dass der Kern zum Thema gehört, da die meisten Leute davon ausgehen, dass ihre einzigen Möglichkeiten Stunden oder (in geringerem Maße) Story Points sind. Warum diese so weit verbreitet sind und welche Klassen von Alternativen es möglicherweise gibt, scheint für unsere Mission relevant zu sein, auch wenn die Frage in ihrer jetzigen Form etwas Listen erzeugend ist.

Antworten (6)

Für mich klingt es so, als wollten Sie Ihre Schätzgenauigkeit verbessern – nicht flexibler machen. Deshalb hier ein paar Hinweise.

Kegel der Unsicherheit

Je früher Sie im Projekt sind, desto ungenauer wird Ihre Schätzung sein. Der Unsicherheitskegel veranschaulicht dies, indem er bei einer Streuung von 0,25x bis 4x beginnt und langsam auf den Faktor 1 konvergiert. Dies ist die maximale Genauigkeit, die Sie von Ihren Schätzungen erwarten können. Dh. Wenn Sie anfangen, können Sie mit Ihrer Schätzung nicht genauer sein - Sie können nur mehr Glück haben.

Ich spreche das an, weil Ihre Fragen für mich so klingen, als würden Sie Geschichten basierend auf der ursprünglichen Schätzung priorisieren, ohne eine Verfeinerung zu berücksichtigen. Ich könnte mich diesbezüglich aber irren.

Bereiche übertrumpfen einzelne Vermutungen

Anstatt Einzelpunktschätzungen bereitzustellen, bieten Sie Bereiche an. Beginnen Sie mit der Schätzung des absoluten Worst-Case-Szenarios für Ihre Obergrenze. Schätzen Sie dann das "wahrscheinliche" Szenario für Ihre Untergrenze. Versuchen Sie, beide Schätzungen so festzulegen, dass Sie sich zu 90 % sicher sind, dass Sie richtig liegen. Das bewirkt zweierlei: Die Betrachtung des schlimmsten Falls bringt Sie zuerst auf die Spur, was schief gehen kann, und bewahrt Sie davor, zu viele Risiken einzugehen. Zweitens, indem Sie sich dazu zwingen, Ihre Schätzungen auf einen extremen Konfidenzbereich von 90 % auszudehnen, haben Sie eine Chance von mindestens 30 %, richtig zu liegen.

Relative Schätzungen

Vermeiden Sie nach Möglichkeit absolute Schätzungen und versuchen Sie, die Positionen in Relation zueinander zu schätzen. Verwenden Sie dann die Geschwindigkeit, um die Menge der abgeschlossenen Aufgaben pro Sprint in Relation zu den Schätzungen zu setzen, die Sie darauf setzen. Sie KÖNNEN dies mit Stunden tun, wenn Sie möchten. Es kommt einfach natürlicher, wenn man es mit Punkten macht. Um ein gewisses Maß an Zuverlässigkeit zu bewahren, müssen Sie außerdem davon absehen, Ihre relativen Gewichte zu ändern. Wenn Sie Ihren ersten Sprint auf der Grundlage schätzen, dass Aufgabe X Y Stunden/Punkte sind, und dann nach dem Sprint auf Ihre Geschwindigkeit schauen und sagen: „Aha! Wir waren um den Faktor 2,375 daneben. schießen Sie sich selbst in den Fuß.

Beantworten Sie einfach die Frage bereits!

Es gibt im Wesentlichen drei Ansätze, die Sie wählen können, wenn Sie einen Steinhaufen bewegen müssen:

  • Schätzen Sie das wahre Gewicht jedes Steins und akzeptieren Sie, dass Sie an diesen Schätzungen scheitern. Akzeptieren Sie auch, dass Menschen dumme Neigungen haben, wie zum Beispiel zu erwarten, dass sie in der Lage sein sollten, einen Stein einer bestimmten Größe zu tragen, oder nicht schwach aussehen wollen, indem sie einen Stein auf ein zu hohes Gewicht schätzen, um zu argumentieren, dass sie ihn nicht tragen können.
  • Schätzen Sie Ihre Steine ​​relativ zueinander. Akzeptieren Sie, dass Ihre Schätzungen kein guter Indikator dafür sind, wie viel Arbeit es ist, den gesamten Stapel zu löschen, bis Sie damit begonnen haben, daran zu arbeiten.
  • Schätzen Sie nicht das Gewicht der Steine. Da alles oben genannte bedeutet, dass es so unwahrscheinlich ist, dass Sie der tatsächlichen Zahl nahe kommen, konzentrieren Sie sich stattdessen darauf, jeden Stein auf handliche Größen zu zerlegen (was Sie sowieso tun müssen) und erkennen, dass je homogener die Größe Ihrer Steine ​​wird, desto geringer der Unterschied es gibt zwischen dem Schätzen jedes einzelnen von ihnen und dem einfachen Zählen.
Ich liebe diese Antwort

Montecarlo-Simulationen .

Die Idee ist ziemlich einfach. Ihre Geschichten in den vergangenen Wochen haben eine Art Verteilung, wie lange sie jeweils gedauert haben. Nehmen wir an, die Geschichten haben jeweils diese Anzahl von Tagen gebraucht, bis die nächste Geschichte fertig war:

3, 2, 5, 4, 1, 2, 3, 10, ...

Diese folgen oft einer sogenannten Weibull -Verteilung, die in Richtung eines großen, fetten Schwanzes verzerrt ist, da die meisten Entdeckungen Sie mehr verlangsamen als beschleunigen. (Die menschliche Intuition neigt dazu, eine Normalverteilung anzunehmen, was einer der Gründe ist, warum wir normalerweise optimistisch sind.)

Manchmal sind diese Distributionen jedoch bimodal (es gibt zum Beispiel ein altes System, das jede Geschichte verlangsamt, die es berührt) oder einfach nur chaotisch (niemand checkt an einem Freitag ein, weil er den Build nicht beschädigen möchte). Das Gute an Monte-Carlo-Simulationen ist ... es spielt keine Rolle! Es funktioniert unabhängig von Ihrer Distribution.

Die Art und Weise, wie Sie dies tun, besteht darin, eine zufällige Reise durch die Geschichten zu berechnen, die Sie hinterlassen haben, und herauszufinden, wann diese Reise endet. Sagen wir also, ich schätze, ich habe noch 60 Geschichten übrig. Für jede Geschichte werde ich zufällig aus Ihrer Verteilung auswählen, wie lange es zwischen den Geschichten gedauert hat.

1, 5, 4, 10, 3, 2, 10, 2, 5...

Und das machst du so lange, bis alle 60 Geschichten fertig sind. Addieren Sie nun die Anzahl der Tage, die es gedauert hat, zum Startdatum ...

...und dann nochmal.

Machen Sie es 1000 Mal oder öfter (ja, Sie brauchen dafür eine Software oder eine spezielle Tabellenkalkulation). Es spielt keine Rolle, ob diese seltsame "10" zweimal ausgewählt wird, da dies nicht bei jeder Fahrt der Fall ist. Einige werden seltsam langsam sein, aber die meisten werden schneller sein. Notieren Sie die Enddaten für jede Fahrt.

Jetzt haben Sie etwas mehr als eine Schätzung. Sie haben eine Wahrscheinlichkeitsprognose . Wenn ich also am 1. Januar 2018 beginne, bekomme ich vielleicht so etwas wie:

100%    10-04-2018
95%     03-04-2018
90%     29-03-2018
85%     25-03-2018

usw.

Jedes dieser Daten zeigt, wie viel Prozent der Fahrten Sie bis zu diesem Datum beendet haben. Dies gibt Ihnen eine Vorstellung von der Wahrscheinlichkeit , ein bestimmtes Datum mit all den Geschichten zu treffen. Alternativ können Sie sehen, wie viele Geschichten Sie bis zu einem bestimmten Datum fertig haben, indem Sie einfach zählen, bis das Datum erreicht ist.

Die meisten Leute sind wirklich optimistisch, wenn sie schätzen, und Sie können sich glücklich schätzen, wenn Sie sogar 50 % der Reisen erreichen, die bis zu diesem Datum enden!

Troy Magennis von Focused Objective hat kostenlose Tabellenkalkulationen für solche Dinge, und das Tool von Dan Vacanti von Actionable Agile ist billig genug und meines Erachtens ausgezeichnet. Beide haben auch zahlreiche Videos, die über die Technik sprechen. Ich habe auch ein Open-Source-Projekt , das noch keine Validierung hat, aber gut genug für den Import von Excel-Tabellen funktioniert, einschließlich Exporte aus Jira.

Troy empfiehlt Daten zwischen 7 und 25 Wochen, um dies zum Laufen zu bringen; mehr als das ist normalerweise veraltet. Denken Sie jedoch an saisonale Muster.

Wahrscheinlichkeitsschätzungen

Wenn Sie sich den Ärger von Montecarlo nicht antun wollen, aber die Wahrscheinlichkeitsverteilung wollen, könnte Ihnen eine Technik helfen, die ich von Douglas Hubbard, dem Autor von „How to Measuring Anything“, gelernt habe.

Ich bitte das Team, mir eine Vorstellung davon zu geben, wann sie voraussichtlich versenden werden. Normalerweise sind sie sehr optimistisch, wenn es also Anfang Januar ist, sagen sie "Ende April" oder so ähnlich.

Dann frage ich sie, wie wahrscheinlich sie dann versenden werden. „Oh, 70 %“, sagen sie mir.

Also biete ich ihnen einen hypothetischen Preis von 10.000 £ und zwei verschiedene Möglichkeiten, ihn zu gewinnen. Sie können entweder eine rote Murmel aus einem Beutel mit 7 roten und 3 weißen Murmeln auswählen oder bis Ende April versenden.

Sie gehen normalerweise für die Murmeln; Obwohl sie sagen, dass sie zu 70 % sicher sind, dass sie versendet werden, bevorzugen sie die Chancen, 7 von 10 Murmeln zu ziehen!

Also reduzieren wir die Anzahl der Murmeln in unserer hypothetischen Tasche, bis sie lieber versendet werden. Das sagt uns, wie hoch ihr wahres Selbstvertrauen ist. Indem wir dies mit einer unterschiedlichen Anzahl von Murmeln tun, können wir eine Reihe unterschiedlicher Vertrauensniveaus erhalten.

Wie man diese benutzt

Wenn Sie in irgendeiner Weise vom Versanddatum abhängig sind, verwenden Sie nichts weniger als 85 % Vertrauen. Das ist normalerweise ein Ausweg im Vergleich zu den Schätzungen der meisten Leute. Wenn das Datum näher rückt, können Sie sehen, ob Sie es schaffen oder nicht, und Sie haben immer noch die Möglichkeit, die Dinge zu beschleunigen oder andere Abhängigkeiten zu verschieben, falls erforderlich.

Beachten Sie, dass das Unternehmen nicht glücklich sein wird ... bis sie anfangen, die Zeitersparnis zu sehen, die dadurch entsteht, dass sie keine leicht spielbaren Story-Punkte einschätzen und nicht eine Menge Pläne wiederholen müssen, die auf etwas basieren, das sowieso nie passieren würde. Möglicherweise müssen Sie ein wenig Aufklärung betreiben oder durch knifflige Politik navigieren, bis sie die Realität akzeptieren.

Keine Schätzungen

Es gibt ziemlich starke Bewegungen gegen die Erstellung von Schätzungen. Im Gegensatz zum Namen bedeutet dies nicht, dass Sie keine Schätzungen erstellen, sondern nur, dass Sie keine Schätzungen erstellen und veröffentlichen.

Wie es funktioniert

Zuerst sollte sich das Team auf eine Geschichte mit "durchschnittlicher" Größe einigen. Sie würden eine Richtlinie wie „Wir sollten in der Lage sein, 5 bis 8 dieser Geschichten in einem Sprint zu erledigen.“ verwenden. Es ist hilfreich, 2 oder 3 Beispiele früherer Artikel zu haben, die ungefähr diese Größe haben.

Da Sie nun eine ungefähre Zielgröße haben, zerlegen Sie größere Elemente, bis sie in etwa der Größe entsprechen. Die Idee dabei ist, dass dieser Prozess der Größenschätzung die nützlichen Gespräche im Team verdrängt, die das Erstellen von Schätzungen tut, aber da es keine resultierenden Schätzungszahlen gibt, vermeidet es viele der Funktionsstörungen und Probleme, die durch die Veröffentlichung von Schätzungen entstehen können.

Die gute Nachricht für Product Owner und Stakeholder ist, dass Prognosen immer noch einfach sind. Wenn das Team durchschnittlich 5 - 8 Backlog-Items pro Sprint abschließt, können Sie gut abschätzen, wie viele Sprints es braucht, um an eine bestimmte Stelle im Backlog zu gelangen.

Function Points (FP) ist eine gute Maßeinheit für die Softwareausgabe

Wenn Sie Scrum praktizieren, sollten Sie sich für Story Points entscheiden. Die Gründe sind:

  1. Zeitbasierte Schätzungen (z. B. Stunden) vermitteln Personen außerhalb des Teams, insbesondere der Geschäftsleitung, einen falschen Eindruck von Genauigkeit und Vorhersehbarkeit.
  2. Menschen sind besser in der relativen Einschätzung (Story Points) als in der absoluten Einschätzung (z. B. Stunden).

Lassen Sie mich versuchen, Ihre Frage zu beantworten:

Jetzt schätzen wir in Stunden/Tagen, aber das würden wir gerne ändern... Gibt es neben Story Points/Velocity noch Alternativen?

In ausgereiften Branchen werden grobe Schätzungen auf der Grundlage des Outputs vorgenommen:

  • Sie können eine Schätzung erhalten, wie viel ein Bürogebäude pro Quadratmeter kosten wird.
  • Sie können eine Schätzung erhalten, wie viel eine Energieeinheit für einen Energieversorger kosten wird.

Obwohl Scrum Guide Story Points nicht erwähnt, ist Jeff Sutherland, der Mitbegründer von Scrum, ein großer Befürworter von Story Points . Eine der größten Schwächen von Scrum ist, dass es einige Maßeinheiten für den Aufwandseingang gibt, aber keine Maßeinheit für die Ergebnisausgabe.

Es gibt gut etablierte Organisationen, Standards, Tools und Zertifizierungen für Function Point, was ein Maß für die Leistung ist:

Obwohl ich teilweise nicht zustimme, dass Scrum nicht ergebnisorientiert ist (z. B. erledigt/nicht erledigt), stimme ich zu, dass es oft schlecht implementiert wird. +1 für die Erwähnung von Funktionspunkten als Alternative!
@ToddA.Jacobs Ich wollte nicht andeuten, dass Scrum nicht ergebnisorientiert ist. Nur dass die verwendete Maßeinheit, nämlich Story Points, aus Entwicklersicht ein Maß für den Aufwand (Input) ist. Während Function Point (FP) eine Maßeinheit des Ergebnisses (Output) aus Benutzersicht ist.
Einverstanden, in Bezug auf die Schätzung des Rückstands. Ich habe mich auf die Zeile konzentriert, die besagt, dass with no attempt to measure the result output.ich denke, dass die INVEST-Kriterien (nicht Scrum, aber oft eine solide Praxis) und die Sprint-Review-Funktion "testbar" sind, um die Output-Bewertung innerhalb des Frameworks bereitzustellen, aber ich stimme sicherlich zu, dass der Schätzungsprozess selbst ist primär Input-getrieben durch Design. Sehr gute Punkte, Ashok!
„Wenn Sie Scrum praktizieren, sollten Sie sich für Story Points entscheiden.“ Weil . . . seufz "Eine der größten Schwächen von Scrum ist, dass wir nur den Aufwand schätzen und nicht versuchen, das Ergebnis zu messen." Dann zu verstehen, dass wertvolle Ergebnisse ein großer Teil der agilen Philosophie sind und das Scrum-Framework anscheinend fehlt.
@AlanLarimer Story Points werden von Scrum nicht vorgeschrieben. Sie werden jedoch häufig verwendet, weil Scrum erfordert, dass „zu jedem Zeitpunkt die gesamte verbleibende Arbeit zum Erreichen eines Ziels summiert werden kann“. Scrum priorisiert die Messung der verbleibenden Arbeit als primäre Berichtsmetrik, während die Ergebnisse in Sprint Reviews validiert werden. Es ist jedoch nicht fair zu sagen, dass Scrum keine Ergebnisse misst.
Es wurde kein Grund angegeben, warum Story Points verwendet werden sollten; es war eine "nur weil"-Aussage. Entschuldigung, das war nicht klar. Ich habe nicht gesagt, dass Scrum keine Ergebnisse misst; Ich habe darauf hingewiesen, dass in der Antwort und in den Kommentaren die Ausgabe statt der Ergebnisse erörtert wird. Den Unterschied zwischen Output und Ergebnissen und seine Bedeutung nicht zu verstehen, kann ein Indikator für ein Missverständnis sowohl des Scrum-Frameworks als auch der agilen Softwareentwicklungsphilosophie sein. Der Scrum-Leitfaden könnte sicherlich mit mehr Worten in Bezug auf Ergebnisse verbessert werden, da das Wort nur einmal verwendet wird.
@AlanLarimer Ich habe meine Antwort bearbeitet, um die Klarheit zu verbessern.

Entscheiden Sie, was Sie messen

Gibt es neben Story Points/Velocity noch Alternativen?

Sie können in jeder Einheit schätzen, die Sie messen möchten. Übliche Messungen umfassen Zeit, Aufwand, Geld und kalenderbasierte Ziele.

  • "Stunden" sind eine Form der zeitbasierten Schätzung.
  • "Story Points" sind eine Form der aufwandsbasierten Schätzung, die sich auf die relative Größe konzentriert.
  • "Velocity" ist eine Form von trendbasiertem Tracking & Estimation und dient in erster Linie der Release-Planung.

Die drei Eckpunkte des ikonischen „Eisernen Dreiecks“ des Projektmanagements sind Umfang, Zeitplan und Ressourcen. Alle Projektkontrollen und Schätztechniken sollten eines oder mehrere dieser Elemente oder die Beziehungen zwischen ihnen ausdrücken.

Alternativen zu Zeit/Aufwand

Die meisten Projekte schätzen alle drei Eckpunkte, aber die grundlegende Theorie des modernen Projektmanagements besagt, dass Sie nur zwei der drei kontrollieren können. Umfang, Zeitplan und Ressourcen können nicht gleichzeitig festgelegt werden; Mindestens einer der drei muss sich beugen.

Beispielsweise könnten Sie die Ressourcen und den Zeitplan eines Projekts schätzen, um den Umfang zu erreichen. Sie können auch den Umfang und den Zeitplan abschätzen, um zu den Ressourcen zu gelangen. Im Allgemeinen ist das Geschäft jedoch am häufigsten damit beschäftigt, wann ein Projekt geliefert werden kann, sodass Zeit und Aufwand als primäre Schätzungstechniken oft am sinnvollsten sind. Das bedeutet jedoch nicht, dass sie der einzige Ansatz sind.

Einige warteschlangen- oder zyklusbasierte Methoden beinhalten überhaupt keine einheitenbasierte Schätzung. Während Kanban beispielsweise oft viele Metriken bereitstellt, die für die Nachverfolgung, Release-Planung und Prozessverbesserung nützlich sein können, werden einzelne Arbeitselemente nie explizit geschätzt.

Auch auf Einheitsebene werden verschiedene Arten von Arbeiten (z. B. Support oder Wartung) häufig nicht geschätzt. Sie können solche Arbeit als Warteschlange, Ringpuffer oder Bucket ausdrücken, aber letztendlich sind dies alles nur Möglichkeiten, Arbeit auf der Makroebene und nicht auf der Ebene der Arbeitseinheiten zu planen oder zu budgetieren.

Abschiedsgedanken

Wenn Sie Schätzungen ganz vermeiden möchten, können Sie sich die #NoEstimates-Bewegung ansehen . Ron Jeffries hat jedoch einige interessante Gedanken dazu, die meiner Meinung nach gelesen werden müssen, bevor Sie auf diesen speziellen Zug aufspringen.

Sie müssen Ihr Projekt innerhalb einiger grundlegender Parameter bewerten und kontrollieren, und Zeit und Aufwand sind zwei der häufigsten. Wenn Sie von der Schätzung der Arbeitsstunden oder des Aufwands wegkommen möchten, können Sie dies sicherlich tun. Ich würde jedoch einige Zeit damit verbringen, Ihren Business Case dafür sorgfältig zu evaluieren. Das könnte Ihnen helfen, eine bessere Metrik zu finden oder ein X/Y-Problem aufzudecken, das die Suche nach einer Alternative vorantreibt. In jedem Fall ist es im Allgemeinen gut investierte Zeit, sich die Zeit zu nehmen, Ihre Annahmen und Ihren Prozess zu überprüfen!

Meines Wissens "nein".

Zeitschätzungen sind die intuitive Methode der Schätzung. Manager wollen wissen, wie lange X brauchen wird. Intuitive Lösung? Fragen Sie, wie lange X brauchen wird.

Es gibt jedoch Probleme mit diesem Ansatz. Zum einen hängt die Zeit, die zum Ausführen von X benötigt wird, davon ab, wer X abschließt. Zum anderen sind Menschen schlecht darin, Zeit einzuschätzen. So entstanden Story Points, eine Form des Schätzens in relativem Aufwand. Sie haben sich seitdem als alles andere als genau herausgestellt. Sie können durch Anwenden der Geschwindigkeit des Teams in Zeit umgewandelt werden.

Ich glaube nicht, dass es eine andere Methode gibt, vor allem, weil ich nicht sehe, was sonst zuverlässig verwendet werden könnte. Ich sehe auch keine Notwendigkeit. Wenn Sie einen Prozess schnell definieren müssen und keine Zeit zum Nachdenken aufwenden möchten/können, schätzen Sie die Zeit ein. Wenn Sie eine genauere Methode wünschen, verwenden Sie Story Points.

Bearbeiten: Zum Zeitpunkt des Schreibens hatte ich die Methode „keine Schätzungen“ vergessen. Obwohl man technisch sagen könnte, dass eine solche Methode dasselbe wie Story Points ist, wird nur jeder Aufgabe der gleiche Aufwand gewidmet. Es könnte sogar ein Kontinuum geben, mit Ansätzen wie dem, bei dem jede Aufgabe bis auf seltene Ausreißer gleich geschätzt wird. Dies ist der Ansatz, zu dem sich mein letztes Team entwickelt hat – fast jede Story war 1 Punkt, mit der gelegentlichen 0,1- oder 3-Punkte-Story.

Ich mag die Teile Ihrer Antwort, die im Grunde die Notwendigkeit von Alternativen in Frage stellen, da es anscheinend ein zugrunde liegendes X / Y-Problem für das Poster gibt. Aber objektiv gibt es alternative Schätzmethoden, obwohl, wie Sie sagen, Story Points aus pragmatischer Sicht oft genauer sind.
@ToddA.Jacobs Zum Zeitpunkt des Schreibens hatte ich die Methode „keine Schätzungen“ vergessen. Wenn es andere gibt, kenne ich sie nicht (ich betrachte das Schätzen nach Bereichen nicht als wörtliche Antwort darauf, welche Einheiten für die Schätzung verwendet werden - eher als nützlicher Ansatz, um die Wahrnehmung zu ändern und die Genauigkeit durch Verringern der Genauigkeit zu erhöhen). Wenn es andere gibt, würde ich gerne von ihnen hören.