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?
Forschungsgeschichten (in agilen Begriffen Spikes genannt) sollten:
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:
Eine Spitze endet, wenn Sie die gewünschten Ergebnisse erzielt haben oder die Zeit abgelaufen ist.
Ähnlichkeiten zwischen Story und Spike:
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.
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 .
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.
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:
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.
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.
Atul Kumar