Meine ursprüngliche Frage wurde hier aufgeworfen: Wie kann man in Scrum Forschungsgeschichten schätzen? und wie von @CodeGnome vorgeschlagen, habe ich eine separate Frage erstellt.
Meiner Meinung nach sollten Spikes zeitlich begrenzt werden, da es oft einen Köder für "zusätzliche 5 Minuten" gibt, von denen der Programmierer glaubt, dass sie ausreichen, um die Forschung abzuschließen.
Meine Sorge ist also: Wie können Sie Spikes mithilfe von Story Points timeboxen? Das Konzept hinter Story Points, das ich kenne, ist, dass sie sich nicht auf Zeit beziehen sollten, sondern eher eine Mischung aus Aufwand und Aufgabenkomplexität.
(Nebenbemerkung: Ich glaube, sobald Sie anfangen, Story Points in Stunden umzuwandeln, sollten Sie besser anfangen, Stunden zu verwenden. Sie sparen Ihrem Team etwas Zeit bei der Berechnung der Planung von Besprechungen.)
Also, wie soll ich damit umgehen?
Spikes werden in Story Points geschätzt. Aufgaben im Zusammenhang mit der Spitze sollten in Zeiteinheiten geschätzt werden. Die Timebox für eine Spitze wird basierend auf den zugehörigen Aufgaben berechnet, die im Sprint Backlog definiert sind.
[Wie] wie können Sie Spikes mithilfe von Story Points timeboxen? [Sie sind eine] Mischung aus Aufwand und Aufgabenkomplexität.
Sie haben "Unsicherheit" ausgelassen. Story Points sind auch ein Maß für Unsicherheit. Eine User Story, bei der niemand weiß, wo er anfangen soll, wird unendliche Unsicherheit erreichen, während eine gut geschriebene Geschichte mit guten Grenzen die Unsicherheit begrenzen wird.
Zum Beispiel „erforschen Sie die Anzahl der Engel, die auf dem Kopf einer Stecknadel tanzen können“ wird ein hohes Maß an Unsicherheit haben, es sei denn, Sie haben bereits eine Stecknadel, die bekanntermaßen von Engeln als Nachtclub verwendet wird. Dagegen etwas wie:
Als Programmierer
möchte ich alternative Wege erkunden, um die Homepage
so zu rendern, dass sie in weniger als 1.200 Millisekunden geladen wird.
hat eine gewisse Unsicherheit über die Lösung, aber es hat auch gut formulierte Ziele, klar definierte Grenzen von „gut genug“ und schlägt wahrscheinlich Ansätze zur Verringerung der Unsicherheit vor, die zumindest für den Aufwand bemessen werden können.
Im Gegensatz zu einer normalen User Story wird von einem Spike nicht immer erwartet, dass er ein potenziell lieferbares Inkrement generiert. Ein Spike ist ein Erfolg, wenn er dem Team Wissen hinzufügt und die Unsicherheit über eine verwandte Geschichte verringert. Beispielsweise könnte die obige Spitze dazu führen, dass ein Team die Ladezeiten nicht verkürzen kann, ohne Inhalte zu opfern oder die Architektur neu zu gestalten. Das ist ein Gewinn, wenn es dem Team hilft, andere UI- oder UX-Geschichten einzuschätzen. Selbst wenn die Spitze am Ende der Timebox unvollständig ist, verringert sie die Unsicherheit über den Aufwand, der erforderlich ist, um die entsprechenden Ziele zu erreichen.
Geschichten werden in Story Points geschätzt. Aufgaben sollten in Zeiteinheiten geschätzt werden, da sie im Wesentlichen eine Zuordnung der umschließenden Zeitbox sind. Es gibt keine festen Regeln dazu, aber in meiner Scrum-Praxis:
Storys im Product Backlog werden in Story Points geschätzt. Obwohl es Ausnahmen gibt, gehören die meisten Spitzen in das Product Backlog, wo sie für den Product Owner und die Organisation sichtbar sind. Die Forschung ist mit Kosten verbunden, die vom Projekt getragen werden müssen, und es liegt in der Verantwortung des Product Owners, die Forschung über das Product Backlog zu priorisieren.
Aufgaben im Sprint Backlog werden in Zeiteinheiten geschätzt. Ein Teil der Sprint-Planung besteht darin, User Stories in granulare Aufgaben im Sprint Backlog zu zerlegen. Ich empfehle im Allgemeinen, Aufgaben zwischen einem halben Tag und zwei Tagen zu planen; Alles, was kleiner ist, verursacht zu viel Prozessaufwand, und alles, was größer ist, verstößt gegen das zugrunde liegende „Done/Not-Done“-Prinzip.
Spikes haben per Definition eine maximale Timebox-Größe von einem Sprint. Das ist Ihre Obergrenze. Am Ende eines Sprints ist der Spike fertig oder nicht fertig, genau wie jede andere Geschichte.
Spitzen haben auch ein implizites Minimum, das die kleinste Größe einer Aufgabe im Sprint Backlog ist. Dies stellt die minimalen Kosten einer Spitze für das Projekt dar, kann aber auch verwendet werden, um eine Zeitbox innerhalb eines Sprints für die Spitze herauszuarbeiten.
Ein Spike hat eine Story-Point-Schätzung. Jede der explorativen Aufgaben für einen Spike sollte eine Zeitschätzung im Sprint Backlog haben. Sie gehen mit Spike-Slippage genauso um wie mit User-Story-Slippage: frühzeitig scheitern. Während Aufgaben nicht das gleiche starre Timeboxing erfordern wie der Sprint als Ganzes, sollten Aufgaben, die ihre Sprint-Backlog-Schätzungen überschreiten, im täglichen Stand-up kommuniziert werden, und das gesamte Team (einschließlich des Product Owners) sollte entscheiden, was zu tun ist Gehen Sie mit Spitzen um, die keinen Wert liefern oder die nicht innerhalb ihrer Timebox abgeschlossen werden können.
Beispielsweise könnte eine Zwei-Punkte-Geschichte fünf Aufgaben mit einer Zeitschätzung von jeweils einem Tag haben. Die Story hat also eine Timebox von fünf Tagen und jede Aufgabe hat eine Timebox von einem Tag. Wenn eine Aufgabe ihre Ein-Tages-Zeitbox überschreitet, wird dies im täglichen Stand-up gemeldet, wo das Team koordinieren und entscheiden kann, was zu tun ist.
Vielleicht beschließt das Team, der Aufgabe mehr Ressourcen zuzuweisen, die Zeit oder Personen aus einer anderen Geschichte zu verschieben, die sich als einfacher als erwartet herausgestellt hat. Andererseits entscheidet das Team vielleicht, dass genügend Informationen gesammelt wurden, um das Ziel der Verringerung der Unsicherheit der Spitze zu erreichen. Andererseits könnte das Team auch entscheiden, dass die potenziellen Gewinne aus dem Spike es nicht wert sind, andere Stories dem Risiko auszusetzen, am Ende des Sprints nicht fertig zu sein, und den Spike daher frühzeitig beenden .
Wie Sie sehen können, ist dies wirklich derselbe Entscheidungsbaum, den das Team mit normalen Storys hat. Der Hauptunterschied besteht darin, dass ein Spike normalerweise dazu dient, in die Schätzungen einer verwandten Story in einem zukünftigen Sprint einzufließen, anstatt etwas Konkretes zu liefern. Daher ist selbst eine „fehlgeschlagene“ Spitze in der Regel ein Erfolg, da sie die Unsicherheit verringert oder die Komplexität einer verwandten Geschichte hervorhebt.
Denken Sie abschließend daran, dass sich erfolgreiche Scrum-Teams selbst organisieren. Als Scrum Master besteht Ihre Aufgabe darin, die Mitarbeiter daran zu erinnern, die von ihnen zugewiesenen Zeitfenster zu respektieren. Innerhalb der Grenzen des Frameworks ist es für das Team jedoch durchaus akzeptabel, interne Ressourcen innerhalb eines Sprints zuzuweisen oder zu verschieben.
Im Klartext bedeutet das, dass das Team für das Erreichen des Sprintziels verantwortlich ist. Wenn sie Ziele verfehlen, weil sie das Timeboxing nicht einhalten, wird dies deutlich im Burn-Down-Diagramm und im Product Backlog widergespiegelt und sollte in der Sprint-Retrospektive angegangen werden.
Timeboxing ist ein Werkzeug; es ist kein Selbstzweck. Das Framework erfordert, dass die Timeboxen für Iterationen und definierte Meetings eingehalten werden. Innerhalb eines Sprints ist Timeboxing jedoch als Entscheidungshilfe gedacht und nicht als Grenze im Sand, die niemand überschreiten kann.
Schlechte Teams ignorieren Zeitfenster. Gute Teams respektieren die Beschränkungen, die ihnen die Time-Boxes auferlegen. Großartige Teams wissen, wann sie eine selbst auferlegte Timebox verlängern können, ohne das Sprintziel zu gefährden.
Wenn Sie sich derzeit in einem Szenario befinden, in dem Sie, wie CodeGnome vorschlägt, Geschichten mit Story Points und Aufgaben haben, die in Stunden geschätzt werden, würde ich seiner Antwort folgen.
Willl hat auch einen sehr wichtigen Punkt angesprochen, dass Sie, wenn Sie Spikes für Stories im aktuellen Sprint machen, die Untersuchung wirklich einfach mit der Story einbringen und Ihre Story-Punkte für die Story die Ungewissheit widerspiegeln sollten.
Wenn Sie, wie es meine Teams früher taten, ziemlich kleine Stories haben, die in Punkten geschätzt werden, die dann nicht in zeitlich geschätzte Aufgaben zerlegt werden, ist es etwas kniffliger.
Meine Teams haben zwei Ansätze ausprobiert:
Planen Sie maximal Zeit pro Woche für Spikes ein
Früher erlaubten wir zwei Tage Spitzen pro zweiwöchigem Sprint.
Timebox und Nutzungspunkte
Wir haben auch versucht, einen Standardpunktwert zu haben, den wir Spikes mit einer bestimmten Timebox zuordnen (z. B. ein halbtägiger Spike könnte 1 Punkt sein, ein zweitägiger Spike 5 Punkte).
Heutzutage schätzen wir Geschichten überhaupt nicht – dann können Sie einfach alles als „1“ behandeln, egal ob es sich um eine Spitze oder eine Geschichte handelt, und dieses spezielle Problem verschwindet!
Meiner Erfahrung nach lautet die Antwort nicht .
Wir haben bisher zwei Arten von Spikes gemacht:
Aber unter dem Strich haben wir nie einen Wert darin gesehen, Spitzen bei Story Points zu schätzen. Die Art der Arbeit ist völlig anders, daher sind die Story Points nicht dafür kalibriert.
Ich habe mit Spikes zu kämpfen, seit ich ScrumMaster bin. Ich fange endlich an, mich mit ihnen abzufinden, und so geht es:
In meiner Organisation gibt es eine anhaltende Debatte über die Nützlichkeit von Spikes. Nachdem ich akzeptiert hatte, dass das Team für seine eigenen Entscheidungen verantwortlich ist, habe ich mich aus der Debatte zurückgezogen.
Da die Spitze/Recherche notwendig ist, um eine User Story fertigzustellen, sollte sie genauso geschätzt werden wie jede andere Teilaufgabe. Wenn Sie normalerweise User Stories in Aufgaben aufteilen, die in idealen Stunden gemessen werden, wird die Spitze einfach zu einer dieser Aufgaben, z
Dies wirkt sich nicht auf Ihre Geschwindigkeit aus, da die Arbeit erforderlich ist, um die Geschichte abzuschließen. Ihre Geschwindigkeit zeigt, wie viele Story Points Sie in einer Iteration abschließen können. Wenn das Erledigen von Forschungsaufgaben für den Abschluss jeder User Story erforderlich ist und Sie es nicht als Teil der Story einschätzen, werden Sie sowieso Ihre Geschwindigkeit beeinträchtigen. Dieser Schaden wird wahrscheinlich schlimmer sein, als Sie vielleicht denken, denn Sie verlieren die Punkte für die gesamte Geschichte, wenn sie nicht abgeschlossen wird, weil Sie die Recherchearbeit nicht abgerechnet haben. Wenn Sie es stattdessen richtig geschätzt hätten, hätten Sie möglicherweise erkannt, dass es nicht in die Iteration passen würde, und hätten stattdessen eine kleinere Geschichte gewählt, die Ihnen einen Nettogeschwindigkeitsgewinn bringen würde.
Möglicherweise stellen Sie fest, dass die Ausgabe der Spitze bedeutet, dass Sie andere Aufgaben oder Geschichten neu einschätzen müssen, aber das ist eigentlich keine große Sache. Egal, woran Sie arbeiten, dies kann passieren – Benutzeroberflächen sind schwieriger zu programmieren als erwartet, ein seltsames Legacy-System macht alles andere kaputt usw. Der Punkt ist, dass Sie festlegen, wenn Sie es nicht als Aufgabe aufnehmen sich für einen Sturz bereit.
Ben