Rechtfertigen „fast abgeschlossene“ Aufgaben oder Geschichten eine Planung mit Überlastung im nächsten Sprint?

Der fragliche Fall:

Der Sprint ist fast vorbei und eines meiner Scrum-Teams hat einige Aufgaben nicht erledigt. (Der Grund dafür ist für diese Frage nicht wesentlich und wird entsprechend behandelt.) Einer davon ist ein klassischer "90% erledigt" -Fall mit einer ziemlich großen Anzahl von Story-Punkten und wird Teil des nächsten Sprints sein - wie in der Frage hier .

Wir haben den Rückstand gepflegt und einige vorläufige Schätzungen für den nächsten Sprint vorgenommen und besprochen, wie diese unvollendete Aufgabe zu bewältigen ist. Obwohl wir uns alle einig sind, dass dies nicht für die Geschwindigkeit dieses Sprints zählt, argumentierte ich, dass wir den fast vollständigen Fall nicht mit 1 statt mit fünf Story-Punkten neu schätzen sollten, da ich möchte, dass die wahre Komplexität und die gesamte geleistete Arbeit erreicht werden noch sichtbar. Und rückblickend war die Schätzung richtig. - Wir wechseln gerade zu (skalierter) Agilität und einige Managementebenen müssen "sehen", dass wir immer noch in mehr als nur gelieferten Produkten produktiv sind.

Natürlich wird die Geschwindigkeit in diesem Sprint sinken, aber die übertragenen "bereits erledigten" Teile sollten sie im nächsten Sprint wieder erhöhen.

Bisher sind wir uns alle einig.

Da unsere Teams jedoch eher klein sind, sind vier Punkte ein großer Klumpen. Ich schlug vor, dass wir nur für diese Aufgabe und mit der richtigen Dokumentation bewusst eine Überlastung von vier Punkten planen könnten.

Ist das ein machbarer Ansatz oder werde ich

• stoße auf Probleme, die ich noch nicht erwarte
• ein schlechtes Beispiel mit einem Team geben, das erst vor wenigen Monaten auf Agile umgestellt wurde?

Wenn eine Geschichte am Ende des Sprints nicht fertig ist, zählen die Punkte der Geschichte nicht zur Geschwindigkeit dieses Sprints und die Geschichte geht zurück in den Rückstand.

Wenn während der Planung des nächsten Sprints die Story als abgeschlossen ausgewählt wird, können Sie die verbleibende Arbeit schnell neu einschätzen. Diese Schätzung sollte nur während der Planungssitzung verwendet werden, um sicherzustellen, dass Sie den Sprint nicht mit Storys mit einer großen Anzahl von Punkten unterladen, an denen tatsächlich nur sehr wenig Arbeiten durchgeführt werden müssen, um sie abzuschließen.
Auf dem Brett (und in der Geschwindigkeit des neuen Sprints) sollte die ursprüngliche Schätzung der übertragenen Geschichte verwendet werden.

Solche übertragenen Geschichten sind ein Grund, warum die Geschwindigkeit von Sprint zu Sprint variieren kann, und Sie sollten einen Durchschnitt verwenden, um die Kapazität des Teams bei der Planung eines Sprints zu berechnen.

Wenn die nicht abgeschlossene Story im nächsten Sprint nicht erfasst wird, ist es möglicherweise besser, sie für den vollen Punktewert zu planen, wenn sie erneut erfasst wird, da es auch einige Zeit dauert, bis sie auf dem neuesten Stand ist wieder mit dem Zustand, als das Team aufhörte, daran zu arbeiten.

Versuchen Sie nicht, Ihre Geschwindigkeit besser aussehen zu lassen als sie ist. Der Weg nach vorne besteht darin, zu bestätigen, dass die Aufgabe nicht abgeschlossen wurde. Sie haben überschätzt, was Sie im Sprint tun konnten, und sind fehlgeschlagen. Aber das ist das Leben und eine Gelegenheit zum Lernen.

Also 0 Punkte für die unvollständige Aufgabe.

Schätzen Sie für den neuen Sprint die zur Erledigung der Aufgabe erforderliche Arbeit in Story-Punkten und zählen Sie sie als normale Aufgabe.

Sie befürchten, dass Ihre Geschwindigkeit zu niedrig aussieht. Sie sollten sich Sorgen machen, dass Ihre Geschwindigkeit künstlich zu hoch ist.

Wenn Sie eine höhere Geschwindigkeit haben, als Sie tatsächlich erreichen können, werden Sie immer wieder zum Scheitern verurteilt.

In unserem Team verwenden wir je nach den Umständen verschiedene Methoden, um Übertragsgeschichten zu verarbeiten.

• Wenn der Sprint fast vorbei ist und alles, was geplant ist, bereits beendet ist (was bei jedem zweiten Sprint der Fall ist), beginnen wir mit den nächsten Storys im Backlog (aber verpflichten Sie sie nicht zur Sprint-Veröffentlichung). Diese werden automatisch in den nächsten Sprint aufgenommen, und zu Berichtszwecken werden alle Story-Punkte an den nächsten Sprint weitergeleitet.

• Wenn Teile der Geschichte vollständig fertig sind und einen eigenen Geschäftswert haben, passen wir im Allgemeinen sowohl den Umfang als auch die Schätzung für die ursprüngliche Geschichte neu an, und die verbleibenden Teile gehen auf den Rückstand zurück.

• Wenn die ursprüngliche Schätzung für die Geschichte nicht korrekt war (was manchmal bei großen, komplexen Geschichten der Fall ist), versuchen wir, daraus zu lernen :). Keine Story-Punkte im aktuellen Sprint. Schätzen Sie die gesamte Story in der nächsten Sprint-Planung neu.

Wenn einige der Geschichten aus dem vorherigen Sprint übernommen wurden, beginnen Sie in der Sprintplanung nicht mit einem leeren Sprint-Rückstand. Das Team entscheidet, wie viel zusätzliche Arbeit es zusätzlich aufnehmen kann. Zum Beispiel: normale Teamkapazität 100 SP / Sprint, 20 Punkte bereits in Bearbeitung, das Team beschließt, 90 neue SPs zu nehmen, sodass Sie zu Beginn des Sprints 110 SPs im Sprint haben.

Der Hauptnachteil dieses Ansatzes ist, dass die Geschwindigkeitsberichte nicht so gut sind, wie es einige Manager gerne hätten. Aber auf lange Sicht gleicht sich alles aus, und auf diese Weise wird alles, was möglicherweise freisetzbar ist, so früh wie möglich geliefert, und das Team erhält Credits für seine Arbeit.

Ein bisschen Hintergrundwissen: Ursprünglich hatte dieses Team einen sehr strengen Ansatz in Bezug auf Sprintfristen, sodass es sich weigerte, mehr große Geschichten aufzunehmen, als sie in der ersten Woche (des 2-wöchigen Sprints) beenden konnten, und kleine und sichere verwenden konnte Arbeite für den restlichen Teil des Sprints. Während dies am Ende des Sprints zu einem schönen leeren Sprint-Rückstand führte, hatte dies zu viel Einfluss auf die Frage, woran wir als nächstes arbeiten sollen.

Dies ist keine Frage für eine einfache Antwort. Es wird viele Meinungen darüber geben, was zu tun ist, aber ich schlage vor, dass Sie zunächst die verschiedenen Bedürfnisse identifizieren, die Sie erfüllen müssen, und auf dieser Grundlage eine Lösung finden. Beispiel:

1. Ein Team "muss" verstehen, wie es funktioniert, und mögliche Verbesserungsmöglichkeiten identifizieren. Manchmal maskiert das Ändern von Story Points Probleme, die behoben werden sollten.
2. Der Product Owner "muss" wissen können, wie viele Story-Punkte für ein Feature (häufig werden diese auf Feature-Ebene aggregiert) oder Release (AKA "PI" in SAFe-Sprache) geschätzt wurden, und kann einen Abbrand bei beantragen die Funktionsebene (oder PI), um den Fortschritt bei der Bereitstellung eines MVP oder MMF zu demonstrieren. Das Ändern von Story-Punkten kann die Zahlen verzerren und Verwirrung stiften.

Es gibt einige "Leitplanken", die bei der Entscheidung helfen.

• Die Arbeit ist entweder erledigt oder nicht. Unvollständige Arbeiten zählen nicht für den Sprint, in dem sie abgeschlossen wurden.
• Unvollständige Geschichten sollten neu priorisiert werden (es ist nicht selbstverständlich, dass sie auf den nächsten Sprint übertragen werden, sie können zum Rückstand zurückkehren oder aufgegeben werden).

Davon abgesehen habe ich viele Teams gesehen, die auf verschiedene Weise damit umgehen.

1. Wenn die unvollständige Geschichte noch gültig und von der PO genehmigt ist, wird die gesamte Geschichte zum nächsten Sprint weitergeleitet. Was diese Teams häufig tun, ist, diese Geschichten als Übertragung zu markieren und zu schätzen, wie viele Punkte der "verbleibenden Arbeit" sie darstellen. Wenn es sich also um eine 13-Punkte-Story handelt, aber nur noch 1 Punkt übrig ist, rechnen sie nach, indem sie 12 abziehen. Dadurch bleibt die ursprüngliche Schätzung für historische Zwecke erhalten, wie Sie vorgeschlagen haben, und hilft dem Team dabei, ihre Kapazität herauszufinden. In diesem Fall, JA, haben Sie möglicherweise "mehr Punkte" als Ihre geschwindigkeitsbasierte Kapazität "Schwelle". Die Geschwindigkeit kann sich jedoch geringfügig ändern, sie ist nicht in Stein gemeißelt.
2. Ich habe gesehen, wie Teams die Geschichte aufgeteilt haben (Rally hat zum Beispiel eine sehr schöne Funktionalität) und einige Punkte für den Teil der Geschichte angewendet, der im alten Sprint "bleibt", und dann Punkte auf den Teil angewendet, der fortfährt. Dieser Ansatz ist praktisch, verstößt jedoch gegen das Prinzip "Fertig bedeutet FERTIG" und verbirgt die Tatsache, dass Schätzungen schlecht sind und die Arbeit übertragen wird, sodass die Möglichkeit zum Lernen und Verbessern verloren gehen kann. (Dies ist aus diesen Gründen nicht meine Empfehlung)
   3. Die schlimmste Lösung, die ich gesehen habe, war, dass sie nur die alte Geschichte als FERTIG markiert haben, vielleicht haben sie die Punkte reduziert, vielleicht auch nicht, und dann haben sie eine neue Geschichte für die verbleibende Arbeit eröffnet (oft getestet!). Dies ist meiner Meinung nach eine hässliche Lösung.

Worauf ich mich konzentrieren würde, ist Folgendes: "Einer von ihnen ist ein klassischer" 90% erledigt "-Fall mit einer ziemlich großen Anzahl von Story-Punkten" - der Schlüssel hier ist GROSSE Story! Denken Sie daran, INVEST: Geschichten sollten klein sein. Das Team sollte sich entweder die Aufteilung von Geschichten (bevorzugt) oder das Schwärmen von Geschichten ansehen. Aber größer bedeutet immer mehr Risiko, auch wenn es schwärmt.