Wie schätzt man Forschungsgeschichten in Scrum ein?

Wenn in unserem Scrum-Team Unsicherheit über eine Story besteht oder das Team sich nicht sicher ist, wie es umgesetzt werden soll, greifen wir zuerst eine Forschungsstory auf. Basierend auf den Erkenntnissen dieser Forschungsgeschichte können wir die Basisgeschichte besser einschätzen. Sollten wir eine Zeitbox (so viele Stunden) für Forschungsgeschichten oder eine regelmäßige Punkteschätzung zuweisen?

Mehr über Spikes – scaledagileframework.com/spikes Und dieser hier schlägt vor, wie man Spikes nicht verwendet –leadingagile.com/2014/04/dont-estimate-spikes

Antworten (3)

Forschungsgeschichten (in agilen Begriffen Spikes genannt) sollten:

  • sparsam verwendet
  • kurz gehalten
  • immer time-boxed sein

Sollten wir eine Zeitbox (so viele Stunden) für Forschungsgeschichten oder eine regelmäßige Punkteschätzung zuweisen?

Die reguläre Punktschätzung kann hauptsächlich aus folgenden Gründen nicht verwendet werden:

  • Story Points liefern ein Maß für den Geschäftswert
  • Punkte werden verwendet, um die Geschwindigkeit des Teams zur Generierung von Geschäftswert zu berechnen
  • Spikes werden ausgelöst, wenn „Unsicherheit bezüglich einer Story besteht oder das Team sich nicht sicher ist, wie es sie umsetzen soll“. Wenn bereits eine Unsicherheit besteht, wird es unvernünftig, sie in einer Planungs-Pokersitzung einzuschätzen. Es wird schwierig, die relative Größe einer Forschungsarbeit (unbekannte Aktivität) mit einer funktionierenden Software zu vergleichen, wie z. B. das Erstellen eines Warenkorbmoduls (bekannte Aktivität). Eine Spitze würde Ihnen helfen, Risiken zu reduzieren, damit Sie andere User Stories besser verstehen / einschätzen können.

Eine Spitze endet, wenn Sie die gewünschten Ergebnisse erzielt haben oder die Zeit abgelaufen ist.

Ähnlichkeiten zwischen Story und Spike:

  • hat Akzeptanzkriterien (was für diese Spitze "erledigt" bedeutet)
  • zum Iterations-/Sprint-Backlog hinzugefügt
  • am Ende der Iteration werden die Ergebnisse diskutiert oder die Spike-Ausgabe demonstriert

Unterschied zwischen Story und Spike:

Spike liefert kein versandfähiges Produkt (Geschäftswert). Wie es in den Agilen Prinzipien heißt, ist funktionierende Software das primäre Maß für den Fortschritt , der Abschluss eines Spikes führt nicht direkt zu einer funktionierenden Software.

Bedenken Sie auch, dass ein Spike manchmal verwendet wird, wenn ein Entwicklungsteam kein Vertrauen in andere wertvolle Product Backlog Items im Backlog hat; ein "Forschungs"-PBI zu haben, kann ein Vorwand sein. Ich neige dazu, Teams zu ermutigen, die Unsicherheit, die sie empfinden, in ihre Schätzung für den wertvollen PBI einzubeziehen, anstatt ihn von der Arbeit zu trennen. Dies trägt dazu bei, die Möglichkeit von Verschwendung zu minimieren, dh die Forschung wird erledigt, aber das wertvolle PBI nicht.
@aziz-shaikh, wie erklären Sie den Aufwand und die Zeit, die das Entwicklerteam in diese Spikes gesteckt hat, die auch Teil des Sprint-Backlogs sind? Lassen Sie die Geschwindigkeit einfach sinken? Reduzieren Sie die Teamkapazität? Etwas anderes?
@bit-pirate Ja, Spikes sind Teil des Sprint-Backlogs. Hinsichtlich der Messung und Aufzeichnung der für einen Spike aufgewendeten Anstrengungen gibt es zwei Ansichten. Eine Ansicht ist, dass Spikes zeitgebunden sind, aber ohne Story Points. Dies bedeutet, dass Ihre Geschwindigkeit sinkt, aber das Ergebnis dieser Spitze kann Ihnen helfen, die Geschwindigkeit in nachfolgenden Sprints zu erhöhen. Die zweite Ansicht ist, dass Sie Story Points genau wie andere User Stories einem Spike zuweisen. Der Vorteil ist, dass Ihre Geschwindigkeit aufgrund dieser Spitze nicht sinkt. Allerdings sind nicht alle Spikes leicht abzuschätzen. Geben Sie höhere oder niedrigere Punkte?

TL; DR

Sollten wir eine Zeitbox (so viele Stunden) für Forschungsgeschichten oder eine regelmäßige Punkteschätzung zuweisen?

Sie sollten beides tun. Ein Spike (oder eine „Spiked Story“) erfordert sowohl eine Timebox als auch eine Aufwandsschätzung und wird immer als Arbeit gezählt .

Spikes sind nur spezielle User Stories

Wie eine Quelle sagt:

Wie andere Storys werden Spikes in das Backlog gestellt, geschätzt und so bemessen, dass sie in eine Iteration passen ... Der Output eines Spikes ist nachweisbar, sowohl für das Team als auch für alle anderen Beteiligten ... Und wie jede andere Story, Spikes werden vom Product Owner akzeptiert, wenn die Akzeptanzkriterien für den Spike erfüllt sind.

Der Hauptunterschied besteht darin, dass eine Spike-Story darauf ausgelegt ist, den Kegel der Unsicherheit zu reduzieren, anstatt ein lieferbares Inkrement zu liefern. Es gelten jedoch alle anderen Anforderungen an gute User Stories und Framework-Prozesse.

Warum Spikes mit Story Points geschätzt werden sollten

Bei Scrum und XP dreht sich alles um Timeboxing; es ist daher selbstverständlich, dass alle Prozesse innerhalb dieser Rahmenwerke eine endliche Dauer haben müssen. Der Grund für die Zuweisung von Story Points ist jedoch etwas weniger offensichtlich.

Das agile Motto von CodeGnome lautet: Keine unsichtbare Arbeit, niemals. Da ein Spike innerhalb eines Sprints Zeit und Ressourcen verbraucht, ist es wichtig, dass der für den Spike aufgewendete Aufwand für das Projekt vollständig sichtbar gemacht wird. Der Weg, dies innerhalb von Scrum zu tun, besteht darin, sicherzustellen, dass die Spitze:

  • in den entsprechenden Backlogs aufgeführt,
  • als Arbeit gezählt, die in den Sprint gezogen werden soll, und
  • im Burn-Down-Chart dargestellt.

Während einige Leute argumentieren mögen, dass das Zuweisen von Story Points zu Spikes die Geschwindigkeit verzerrt, ist dies ein Missverständnis der Geschwindigkeitsmetrik. Velocity misst keine Features, sondern Kapazität . Insbesondere ist die Geschwindigkeit ein nachlaufender Durchschnitt, der verwendet wird, um die verfügbare Kapazität des Teams für zukünftige Sprints abzuschätzen.

Es liegt am Product Owner, diese Kapazität zu priorisieren. Das Abwägen der Lieferung von lieferbaren Features gegen andere (möglicherweise weniger greifbare) Projektanforderungen ist die Domäne des Product Owners; Das Nachverfolgen und Schätzen des gesamten projektbezogenen Aufwands im Product Backlog ist der wesentliche Mechanismus, um dieses Gleichgewicht innerhalb des Projekts sichtbar zum Ausdruck zu bringen.

Wie wandelt man Timebox-Spikes in Stories um? Dazu müssen Sie ein Umrechnungsverhältnis verwenden, das am Ende dazu führen kann, dass das Team Stunden statt Punkte zählt. Die andere Sache, basierend auf meinen Beobachtungen, ist, dass es schwierig ist, das Ergebnis von Forschungsaufgaben vorherzusagen, und dass die Leute dazu neigen, mehr Zeit zu verbringen, weil "ich der Lösung so nahe bin". Deshalb brauchen Sie Timeboxing. Sehen Sie hier kein Problem?
@BartekKobyłecki Sie stellen eine interessante Frage zu idealen Stunden im Vergleich zu Story Points und zum Timeboxing im Allgemeinen. Hier gibt es keinen inhärenten Konflikt, aber wenn Sie nicht verstehen, warum, dann verdienen sie eine längere Antwort. Bitte stellen Sie diese als separate Fragen.

Das ist eine tolle Frage, denn das kommt auch bei uns oft vor.

Wir haben bisher nichts Spezielles dafür getan, aber ich denke, Sie haben Recht mit dem Timeboxing. X Stunden, und dann wieder einberufen. Wenn sie beim Finden von Antworten "fast da" sind, erfinden Sie vielleicht eine neue Geschichte für Runde 2 der Recherche und so weiter.

Wie schätzt man Forschungsgeschichten in Scrum ein?
AntwortenHierDatenschutz-Bestimmungen1y, 0v