Wir haben eine Story fertiggestellt, die vom Product Owner (PO) oder Management nicht mehr benötigt wird. Die abgeschlossene Geschichte wird keinen geschäftlichen Mehrwert bringen. Was sollen wir in diesem Fall tun? Sollen wir den Aufwand in unsere Velocity einrechnen oder nicht?
Wir haben eine Story fertiggestellt, die von PO/Management nicht mehr benötigt wird. Sicherlich wird diese Geschichte keinen geschäftlichen Mehrwert bringen. Was ist in diesem Fall zu tun? Sollen wir den Aufwand in Geschwindigkeit zählen oder nicht?
Die Geschwindigkeit ist in erster Linie (und am effektivsten) eine Metrik zur Einschätzung der Kapazität eines Teams, zukünftige Aufgaben innerhalb eines Sprints oder einer Reihe von Sprints zu erledigen, und ist nicht als Maß für die Produktivität oder den Geschäftswert gedacht. Da es die zukünftige Kapazität basierend auf der historischen Leistung schätzt, sollten Sie dies berücksichtigen, wenn Sie bestimmen, wie Sie Ihre Geschwindigkeit verfolgen können.
In Ihrem speziellen Fall, der im Detail eher spärlich ist, würde ich folgende Faustregeln vorschlagen:
Wenn die Story zu Beginn des Sprints während des Sprint Plannings übernommen wurde und die Arbeit am Ende des Sprints gemäß der Definition of Done geliefert wurde, wird die Arbeit berechtigterweise zur Geschwindigkeit gezählt, weil sie die geplante Arbeit korrekt ausdrückt /abgeschlossen während des Sprints.
Wenn die Story während des Sprints aus irgendeinem Grund ihren Wert verloren hat, der Product Owner sich jedoch entschieden hat, sie nicht aus dem Geltungsbereich zu nehmen oder den Sprint vorzeitig zu beenden, misst die Arbeit die Fähigkeit des Teams, Arbeit zu liefern, immer noch richtig.
Wurde die Story nicht gemäß der Definition of Done fertiggestellt, kann die Arbeit nicht auf die Velocity des Teams angerechnet werden.
Wenn das Sprint-Ziel erreicht wurde, unabhängig davon, ob der Product Owner darum gebeten hat, es aus dem Sprint zu entfernen, dann hängt es im Wesentlichen davon ab, wie Sie die Geschwindigkeitsmetrik kommunizieren möchten: wie geplant/ abgeschlossene Arbeit oder als Wert oder Opportunitätskosten. Offensichtlich neige ich zu Ersterem, aber einige Praktizierende mögen berechtigterweise anderer Meinung sein.
Einerseits spiegelt die Zählung der Arbeit zur Geschwindigkeit die abgeschlossene geplante Arbeit wider. Andererseits macht das Nichtzählen entwertete Arbeit als Belastung der Geschwindigkeit sichtbar.
Solange Sie nicht den grundlegenden Fehler begehen, dass die Velocity den Aufwand oder den Zeitaufwand widerspiegelt, und die Velocity-Metrik konsequent verwenden, um über den Status des Projekts zu kommunizieren, dann wie das Team mit einem One- Eine Aus-Situation wie diese sollte keinen großen Einfluss auf eine Geschwindigkeitsmetrik haben, die als Bereich oder nachlaufender Durchschnitt ausgedrückt wird.
Es gibt sicherlich Ausnahmen, wie z. B. sehr kurze Projekte oder Fehler bei der Implementierung von Frameworks, aber im Allgemeinen sollte dies kein Ereignis sein, das in der Sprint-Retrospektive behandelt wird. Ihr Kilometerstand kann jedoch variieren.
Wenn die Arbeit basierend auf der PO erledigt wurde, die die Arbeit priorisiert, ja, Sie sollten sie in der Geschwindigkeit zählen. Es ist möglich, dass sich die Marktbedingungen geändert haben.
Wenn das Entwicklerteam alleine vorangegangen ist, kann man es nicht in der Geschwindigkeit zählen. Das Wichtigste zum Mitnehmen ist, Ihren Prozess zu straffen und die Arbeit nur aufzunehmen, wenn sie vom PO priorisiert wird.
Wenn es ein Missverständnis zwischen dem PO- und dem Entwicklerteam gab, sollten Sie Ihre Kommunikation und Ihr Feedback verschärfen.
Unabhängig davon ist dies eine großartige Gelegenheit zum Lernen. Es ist Zeit für eine Retrospektive, um die Grundursache zu identifizieren und Wege zu finden, um ein ähnliches Debakel erneut zu vermeiden.
Bart van Ingen-Schenau
scharma
Vicky Laidler
Todd A. Jacobs