Wie ordnet man Story Points bei extrem komplexen User Stories zu?

Wir haben derzeit Story Points wie folgt zugewiesen:

  • 0,5 sehr einfach (ca. 0-30 min)
  • 1 einfach (ca. ein halber Tag)
  • 2 Mittlerer Schwierigkeitsgrad (ein paar Tage)
  • 3 Schwer (3 Tage)

Das funktioniert gut für uns, aber manchmal, wenn wir Infrastrukturarbeit leisten – Integrationen, DevOps – können wir die obige Metrik nicht richtig verwenden, weil die Aufgabe einfach zu groß ist. An diesem Punkt besteht mein Ansatz darin, zu versuchen, die User Story weiter aufzuschlüsseln, um es einfacher zu machen, ihre Komplexität einzuschätzen, aber dann festzustellen, dass wir dies nicht können, da die Story die Aufgabe ist.

Wie wenden Sie Story Points genau auf sehr große Aufgaben an? Danke

„Habe mehr als 3 Punkte“ scheint die triviale Antwort zu sein. Gibt es einen Grund, warum Sie Ihre Schätzungen auf maximal 3 Tage beschränken, anstatt die Komplexität einer Geschichte zu schätzen?
Setzen Sie Story Points nicht mit Stunden gleich. Story Points sind ein Maß sowohl für Aufwand als auch für Komplexität und sind nur relativ zueinander. Es sollte keine Zuordnung von Punkten zu Stunden geben.
Wir messen die Komplexität basierend auf der ungefähren Zeit, die im Vergleich zu anderen Geschichten benötigt wird. Da ich wöchentliche Sprints durchführe, muss ich eine Vorstellung davon haben, wie lange die User Stories dauern werden, sonst kommt man am Ende in eine „Wie lange ist ein Stück Schnur“-Situation.
@ThomasOwens sie sind lose zugeordnet, bestenfalls eine Annäherung. Wenn die Implementierung länger dauert, kann man mit Fug und Recht sagen, dass es für diesen bestimmten Entwickler komplexer ist als andere Aufgaben.
Jede Zuordnung sollte vermieden werden. Auch Aufwand und Komplexität stehen in keinem Zusammenhang.
Verstehe nicht wirklich, warum sie es nicht sind, wenn etwas sehr komplex zu implementieren ist, wird es im Allgemeinen länger dauern, es zu implementieren, oder? Offensichtlich ist es subjektiv, was komplex ist, weshalb es auf den Fähigkeiten des Teams basieren sollte.
@bobo2000 Eine komplexe Geschichte kann eine einfache Lösung haben. Und ein einfaches CRUD kann beispielsweise aufgrund von Eingabevalidierung und Einschränkungen komplex sein. In meinem Team musste ich anderen Mitgliedern beibringen, diese Korrelation zu vermeiden.
Wie erstellen Sie also Ihre Sprintplanung für beispielsweise einen wöchentlichen Sprint, wenn Sie überhaupt keine Ahnung haben, wie lange es dauern wird, Geschichten zu vervollständigen?
"Wie bewerbe ich mich genau ..." ist, wo Sie in die Irre gehen. Agile Schätzung soll eine „ausreichend gute“ Annäherung sein, nicht „genau“ im Sinne einer aussagekräftigen Genauigkeit.
Genau so verwende ich es CodeGnome: "Wir messen die Komplexität anhand der ungefähren Zeit (relativ zum Aufwand)", zweiter Kommentar zu dieser Antwort von mir. Ich kann mir einfach nicht vorstellen, dass dies funktioniert, wenn Sie überhaupt kein Mapping durchführen. Wenn ich meinem Stakeholder sage: "Richtig, es ist komplex und ich habe keine Ahnung, wann es fertig sein wird", was andere vorschlagen, werde ich ihn verunsichern Wahrscheinlich werde ich irgendwann gefeuert, weil ich so tue, als hätte ich keine Ahnung, wie man Arbeit abliefert. Sie müssen in einer Lieferrolle eine Art ungefähren Zeitrahmen angeben. Ebenso muss das Team dies auch wissen.

Antworten (3)

TL;DR

Die Zuordnung von Story Points zu Zeit ist ein Anti-Pattern. Wenn Sie dies tun müssen , weil Ihr Arbeitsumfeld dies erfordert, müssen Sie daran arbeiten, Agilität an Ihrem Arbeitsplatz zu erziehen und zu evangelisieren. QED

Um bei der agilen Schätzung erfolgreich zu sein, stellen Sie sicher, dass sich das gesamte Team und alle Beteiligten innerhalb der Organisation darüber einig sind, was Ihre Schätzungstechniken tatsächlich messen. Stellen Sie außerdem sicher, dass Sie die Ergebnisse Ihrer Planungstechniken routinemäßig auf Plausibilität überprüfen, um sicherzustellen, dass die Iterationszeitbox eingehalten wird!

Story Points messen den Aufwand

Was also messen Story Points? Sie messen den Aufwand . In geringerem Maße messen sie auch Komplexität, Risiko und Ungewissheit insofern, als diese Dinge den Aufwand beeinflussen können, aber die Metrik selbst bezieht sich nur auf den Aufwand, der mit der Fertigstellung einer Leistung verbunden ist. Zum Beispiel sagt Mike Cohn in seinem Blogbeitrag „Don’t Equate Story Points to Hours“ :

Komplexität beeinflusst eine Schätzung, aber nur in dem Maße, in dem die zusätzliche Komplexität den Aufwand für die Durchführung der Arbeit beeinflusst. Zu dem Ein-Punkt-Gebäude zu gehen, während man „Gangnam Style“ singt, ist wahrscheinlich komplexer, als dorthin zu gehen, ohne zu singen. Aber die zusätzliche Komplexität des Singens hat keinen Einfluss auf die Zeit, die ich brauche, um dorthin zu gehen, also würde meine Schätzung in diesem Fall eine bleiben.

Wenn Sie nur versuchen, die relative Größe als eine nicht verankerte Aufwandsschätzung zu behandeln, hören Sie damit auf und messen Sie einfach direkt die Zeit. Sie werden in Ihren Planungsaktivitäten nicht genauer sein, und vielleicht sogar weniger, aber zumindest werden Sie nicht alle frustrieren, indem Sie einen Kamm als "Dinglehopper" bezeichnen, wie es Prinzessin Ariel in "Arielle, die Meerjungfrau " tut .

Zeitmessung mit Grenzen

Sogar Mike Cohn gibt zu, dass Story Points indirekt die Zeit messen , aber nur indirekt. Das liegt daran, dass wir uns in agilen Frameworks wie Scrum wirklich nur um zwei Zeitgrenzen kümmern:

  1. Das tägliche Aufstehen. Wir kümmern uns darum, ob koordinierte Aufgaben auf dem richtigen Weg sind oder nicht, und können die 1-2-Tage-Faustregel für Aufgaben verwenden, um festzustellen, ob eine Story auf dem richtigen Weg oder gefährdet ist oder nicht. Die Standup-to-Standup-Timebox ist jedoch eine Prozesskontrolle, kein Maß für die Geschwindigkeit oder ein Maßstab für die Genauigkeit des Teams.

  2. Die Sprint- oder Iterationsgröße. Am Ende zählt nur, ob das Sprintziel erreicht werden kann. Wenn das Ziel nicht innerhalb der Timebox erreicht werden kann, hat der Aufwand die Kapazität des Teams überschritten und die Arbeit wurde falsch geplant.

Das einzige wesentliche Zeitmaß innerhalb von Scrum ist, ob die geplante Arbeit am Ende des Sprints erledigt ist oder nicht. Idealerweise verwenden Sie Ihre Geschwindigkeit, um sicherzustellen, dass das Team nicht mehr Arbeit übernimmt, als in einem einzigen Sprint erledigt werden kann, und um die Release-Planung durchzuführen, aber diese Messungen beziehen sich auf die Arbeitskapazität pro Sprint , nicht direkt auf die Zeit.

Bei Scrum geht es darum, Prognosen zur Teamkapazität zu verwenden, um den Arbeitsumfang so zu verwalten, dass er in vorhersehbare Zeitfenster passt. Es geht nicht um hochgenaue Zeitschätzungen auf Aufgabenebene oder darum, das Team zu zwingen, härter oder schneller zu arbeiten. Der Schlüssel ist, eine vorhersehbare Kadenz zu entwickeln!

Plausibilitätsprüfung von Workloads mithilfe von Sprint-Grenzen

Okay, tu so, als ob du tatsächlich Kool-Aid trinkst. Das bedeutet, dass Sie Folgendes a priori akzeptieren :

  • Story Points liefern bessere Schätzungen der Kapazität pro Sprint als die „genaue“ Messung der Aufgabenzeit.
  • Die Anpassung der Arbeit an die Teamkapazität führt zu einer nachhaltigen Kadenz, die in etwa 80 % der Fälle erfolgreich ist.
  • Die Messung des Erfolgs anhand der erreichten Ziele und nicht anhand der Anzahl der durchgeführten Aufgaben ist das Erfolgsmaß der Organisation.

Wie validieren Sie angesichts all dessen Ihre relative Größe? Kommen wir noch einmal auf die zentrale Einheit der Zeitmessung in Scrum zurück: den Sprint.

Story Points sind eigentlich nur ein Zwischenwert, um die Kapazität abzuschätzen . Sie funktionieren gut, aber es gibt andere Schätztechniken. Einer meiner Favoriten ist TFB/NFC/1, ein System, bei dem Sie bestimmen, ob es sich um eine Geschichte oder eine Reihe von Geschichten handelt:

  • passt in einen einzigen Sprint (1)
  • ist zu groß, um in einen einzelnen Sprint zu passen, und sollte zerlegt oder umgestaltet werden (TFB)
  • kann nicht so wie es ist oder mit dem aktuellen Wissen des Teams geschätzt werden (NFC)

Sie können diese Art von Technik auch neben traditionellen Story Points verwenden. Indem Sie das Sprint Backlog als Gestalt betrachten und feststellen, ob das gesamte Arbeitsbuch zuverlässig in einem einzigen Sprint erledigt werden kann, großartig! Wenn Ihr anderer Schätzungsprozess einen Rückstand ergibt, der zu einer Bauchprüfung von „zu verdammt groß“ für einen einzelnen Sprint oder (noch schlimmer) „keine verdammte Ahnung“ führt, sollten Sie den Plan bis zum geplanten Ziel und den damit verbundenen Ergebnissen überarbeiten Arbeit passt in einen einzigen Sprint.

Ob Sie TFB/NFC/1, einen Bauchcheck oder eine andere Schätztechnik verwenden, ist nicht wichtig. Ihre Schlüsselstrategie besteht darin, sicherzustellen, dass das Team (und der Rest der Organisation) die Timebox respektiert. Planen Sie nur so viel Arbeit ein, dass die Iteration passt, und verfeinern Sie Ihren Planungs- und Schätzungsprozess kontinuierlich, bis Sie dies die meiste Zeit zuverlässig tun können. Das ist die Essenz der agilen Planung!

+1 für das „TFB/NFC/1“-Konzept. Wusste ich nicht und sieht ziemlich nützlich aus!

Ich versuche, dies zu beantworten und die obigen Kommentare zu berücksichtigen.

Story Point to Time Mapping

Ich verstehe den Wunsch, Komplexität (Story Points) auf Zeit / Geld (Stunden / Dollar) abzubilden, aber wie Jeff Sutherland es ausdrückt:

Story Points liefern genauere Schätzungen, sie verkürzen die Planungszeit drastisch, sie sagen Veröffentlichungstermine genauer voraus und sie helfen Teams, die Leistung zu verbessern. Stunden geben schlechtere Schätzungen ab, führen große Mengen an Verschwendung in das System ein, behindern die Release-Planung des Product Owners und verwirren das Team darüber, welche Prozessverbesserungen wirklich funktioniert haben.

Das bedeutet, dass Zeitschätzungen meistens falsch sind und Ihnen ein falsches Sicherheitsgefühl vermitteln. Wie @vander-lauriano-da-silva erwähnt, gibt es Aufgaben, die sehr komplex sind (in gewisser Weise muss man viel darüber nachdenken und schwer umzusetzen), aber in kurzer Zeit erledigt werden UND es gibt Aufgaben, die wirklich einfach sind, aber nehmen Sie sich viel Zeit für die Umsetzung. Das Mapping ist also gefährlich (@ThomasOwens). Die ungefähre Komplexität sollte "gut genug" sein, um damit zu arbeiten (@codegnome).

Was ist über 3SP (schwer)?

Wenn Sie auf Mapping bestehen, sehe ich kein Problem mit 5SP (Very Hard), wie @nvoigt auch erwähnte. Aber das sollte etwas sein, das in 5 Tagen (= 1 Woche = Sprintdauer) zu schaffen ist!

Splitting Geschichten

Vielleicht überdenken Sie die Art und Weise, wie Sie Ihre Geschichten schneiden, um sicherzustellen, dass die Geschichte NICHT die Aufgabe ist . Aus meiner Erfahrung können Stories größer als 3 meistens irgendwie aufgeteilt werden (das hängt natürlich von Team zu Team ab).

Dazu gibt es mehrere Quellen:

Andere Möglichkeiten zum Teilen

Wenn Ihre Story zu groß ist, können Sie sie auch in ein Epic umwandeln und Storys hinzufügen. Das löst Ihr Problem vielleicht nicht von vornherein, aber Sie haben Stories, die in einen Sprint passen, ohne den Kontext des Features zu verlieren.

Sprintdauer

Sie können auch über die Sprintdauer nachdenken, warum muss es 1 Woche sein? Die meisten Teams, die ich kenne, laufen gut mit 2 Wochen (reduziert auch die Anzahl der Planungen, Reviews und Retrospektiven).

„Wie machst du also deine Sprintplanung für, sagen wir, einen wöchentlichen Sprint?“

Ich schaue mir die Velocity (Story Points / Sprint) der letzten 3 Sprints an und schätze ab, wie viele Story Points im nächsten „verbrannt“ werden können

Infrastrukturelle / DevOp-Arbeit

Vielleicht helfen auch diese Links weiter:

Das ist, was ich gesagt habe, mein Mapping ist eine „ausreichend gute“ Annäherung, basierend auf den Fähigkeiten des Teams, das ähnliche Arbeit leistet. Ich stimme zu, dass der Versuch, Zeit in eine Aufgabe zu investieren, lächerlich ist und niemals funktioniert, da Softwareaufgaben Untersuchung, Implementierung und Tests erfordern - wie misst man die Untersuchungszeit?. Aber wenn Sie es mit Stakeholdern zu tun haben, müssen Sie ein Mapping durchführen. Mein CEO wird mich ungefähr fragen, wie lange die Lieferung von x Ding dauern wird, da er diese Informationen an potenzielle Kunden für den Verkauf weitergeben muss. Wenn ich sage: „Ich weiß es nicht, aber die Komplexität ist 3“, wird es nicht funktionieren.
Ich denke, dies ist einer der größten Diskussionspunkte zwischen Scrum und Geschäftsleuten. Ich würde sagen: "Die Komplexität für dieses 3SP und wenn unsere Velocity stabil bleibt und wir es zusätzlich zu unserem Rückstand priorisieren, kann es ungefähr innerhalb des nächsten Sprints erledigt sein." - wissend, dass dies keine allzu befriedigende Antwort ist. Aber wenn Sie sagen: „Diese Aufgabe wird 3 Tage dauern“, aber am Ende 5 oder mehr Tage brauchen, wird es auf der Geschäftsseite mehr Frustration geben, da sie diese Aussage möglicherweise als Tatsache hinnehmen.
Sieht so aus, als wären wir auf derselben Seite ... Wenn ich mit meinem Stakeholder zu tun habe, sage ich ihm normalerweise, dass es im Verhältnis zur Komplexität der Aufgabe x Sprints dauern wird. Aber ich kann nicht sagen, dass es 1 Sprint statt 2 (7 bzw. 14 Tage) dauern wird, wenn ich nicht sicher bin, dass 5 oder 14 Tage den Aufwand widerspiegeln, der für die Erledigung Ihrer Aufgabe erforderlich ist. Es ist schwieriger, dies zu bewerten, wenn Sie an Dev-Ops-Aufgaben oder Infrastruktur arbeiten, als beispielsweise ein weniger komplexes Feature, das Javascript aus Erfahrung verwendet.
Der Schlüssel ist also, dass Ihre Art der Schätzung für normale (bekannte) Aufgaben gut funktioniert. Ihr Problem sind DevOps-Aufgaben, die normalerweise nicht erledigt werden und viel Unsicherheit aufweisen. Können Sie einige Beispiele geben, welche Aufgaben gemeint sind und was in der Vergangenheit passiert ist?
Grundsätzlich ja, ein gutes Beispiel ist jetzt, wo die Aufgabe darin besteht, einen zusätzlichen Produktionsserver zum Stack hinzuzufügen. Dazu müssen wir ein Stack-Skript erstellen, aber das allein dauert 2 Sprints. Ich weiß nicht, wie viele Punkte ich dafür vergeben soll, und es kann nicht weiter aufgeschlüsselt werden. Es ist buchstäblich eine Aufgabe.
Da dies scheinbar keine echte Team-Entwickler-Aufgabe ist, die im Team erledigt werden muss. Ich würde erwägen, dafür externe Hilfe in Anspruch zu nehmen (ich kenne Ihr Unternehmen nicht, aber wir haben engagierte Experten für solche Dinge).
Wir haben derzeit die Fähigkeiten im Team, um dies zu tun, die Verwirrung besteht darin, nicht zu wissen, wie viele Story Points wir ihm zuweisen sollen. Wenn ich ihm einen willkürlichen Wert gebe, verlieren Story Points an Bedeutung.

Nur ein Gedanke, wenn jemand es bauen möchte ... Mittlere Stunden * Umkehrskala Wahrscheinlichkeitsbereichsmultiplikator N hr mit d/d durchschnittlicher Abweichung (nicht Standard). Bei der Eingabe von N und da wird der Reichweitenrechner zur Bestätigung in Englisch geschrieben. Wobei d der Verteilungsbereich der Hälfte der Zeit ist, weil die Hälfte am einfachsten ist. zB 1 Std. *3/3 (3 Stunden bis 20 Minuten, normalerweise 1 Stunde) oder 1 Std. *1,5/1,5 (1,5 Std. bis 40 Minuten, Median 1) Geben Sie dann dem günstigsten Bieter die erste Möglichkeit, seine Einschätzung zu beweisen, indem er die Aufgabe delegiert. Somit ist der Delegierende, nicht der Darsteller, derjenige, der beurteilt wird. Die meisten delegieren an sich selbst oder an Personen, denen sie vertrauen. Dies erfordert eine Partnerprogrammierung für das Teilen von Fähigkeiten. Wer sich weigert, eine Aufgabe zu erledigen, sollte dies sagen, bevor Schätzungen abgegeben werden. Eine Gammaverteilung ist eine Wahrscheinlichkeitsverteilung maximaler Entropie mit einem inversen Skalenratenparameter. Komplexität verteilt Entropie. Sie müssen also den Median (nicht den Durchschnitt) und die Wahrscheinlichkeitsabweichung der inversen Skala (nicht +/- Zeit) erraten. Dies wird dann einem Chi-Quadrat-Test über wiederholte Versuche auf Genauigkeit unterzogen, der als Trend-Genauigkeitsmultiplikator zurückgemeldet werden kann. Dies liefert auch genauere Burn-Down-Diagramme, da die vorhergesagte Varianz angezeigt und auch Burn-Down angezeigt werden kann. Der individuelle Chi-Quadrat-Fortschritt (vorhergesagte benötigte Zeit abzüglich der tatsächlich benötigten Zeit, quadriert und dann durch die tatsächliche Zeit dividiert) kann ebenfalls als Trend dargestellt werden, da die Erfahrung zu einer Norm tendiert. Dies wird dann einem Chi-Quadrat-Test über wiederholte Versuche auf Genauigkeit unterzogen, der als Trend-Genauigkeitsmultiplikator zurückgemeldet werden kann. Dies liefert auch genauere Burn-Down-Diagramme, da die vorhergesagte Varianz angezeigt und auch Burn-Down angezeigt werden kann. Der individuelle Chi-Quadrat-Fortschritt (vorhergesagte benötigte Zeit abzüglich der tatsächlich benötigten Zeit, quadriert und dann durch die tatsächliche Zeit dividiert) kann ebenfalls als Trend dargestellt werden, da die Erfahrung zu einer Norm tendiert. Dies wird dann einem Chi-Quadrat-Test über wiederholte Versuche auf Genauigkeit unterzogen, der als Trend-Genauigkeitsmultiplikator zurückgemeldet werden kann. Dies liefert auch genauere Burn-Down-Diagramme, da die vorhergesagte Varianz angezeigt und auch Burn-Down angezeigt werden kann. Der individuelle Chi-Quadrat-Fortschritt (vorhergesagte benötigte Zeit abzüglich der tatsächlich benötigten Zeit, quadriert und dann durch die tatsächliche Zeit dividiert) kann ebenfalls als Trend dargestellt werden, da die Erfahrung zu einer Norm tendiert.https://en.wikipedia.org/wiki/Gamma_distribution#Median_calculation

Wie ordnet man Story Points bei extrem komplexen User Stories zu?
AntwortenHierDatenschutz-Bestimmungen1y, 0v