Wir haben neue Teams, die an Scrum arbeiten, und sie schätzen alle Punkte einer Vielzahl von Geschichten ein. Aber am Anfang haben sie keine Ahnung, wie viele Punkte in einem zweiwöchigen Sprint geliefert werden könnten.
Wir sehen am Ende der Sprints, dass nicht alle Punkte abgearbeitet werden. Gegen Ende ist das Team überfordert und die Qualität wird geopfert, nur um pünktlich zu liefern.
Ich möchte wissen, ob diese Art von KPI in einer Scrum-Umgebung sinnvoll ist, und wenn nicht, wie können wir sicherstellen, dass das Team so produktiv ist, wie es normalerweise ist?
Bei Scrum geht es nicht unbedingt darum, mehr Arbeit schneller zu erledigen, obwohl leistungsstarke Teams dies oft tun. Wie bei den meisten agilen Frameworks geht es bei Scrum darum, gerade genug von der richtigen Arbeit zu tun.
Das Messen des Teams an einer Zielgeschwindigkeit ist ein Scrum-Antimuster, ebenso wie das Messen der Produktivität anhand der Anzahl von Backlog-Elementen oder abgeschlossenen Story Points. Stattdessen sollten Sie die Effektivität des Scrum-Teams (einschließlich der Effektivität des Product Owners!) beim Erreichen des Sprint-Ziels bei jeder Iteration messen.
Das Ziel eines Sprints ist es nie, viel Arbeit zu leisten, N Storys abzuschließen, historische oder prognostizierte Geschwindigkeiten zu erreichen oder eine 100-prozentige Auslastung der Ressourcen zu erreichen. Wenn Sie sich an diese Art von Metriken halten, verstoßen Sie gegen die Kernprinzipien von Agile und Scrum.
In Scrum ist der Sprint eine flüchtige Zeitbox, die mit Product Backlog Items gefüllt ist, die:
Diese Fokussierung auf eine zentrale Kohärenz ist nicht willkürlich. Es ist ein grundlegendes Element des formalen Scrum. Im Abschnitt Sprint-Planung des Scrum Guides heißt es:
Sprint-Ziel
Das Sprint-Ziel ist eine Zielsetzung für den Sprint, die durch die Implementierung des Product Backlog erreicht werden kann. Es bietet dem Entwicklungsteam eine Anleitung, warum es das Inkrement erstellt. Es wird während des Sprint-Planning-Meetings erstellt. Das Sprint-Ziel gibt dem Entwicklungsteam eine gewisse Flexibilität hinsichtlich der im Sprint implementierten Funktionalität. Die ausgewählten Product-Backlog-Elemente liefern eine kohärente Funktion, die das Sprint-Ziel sein kann. Das Sprint-Ziel kann jede andere Kohärenz sein, die dazu führt, dass das Entwicklungsteam eher zusammenarbeitet als an getrennten Initiativen.
Während das Entwicklungsteam arbeitet, behält es das Sprint-Ziel im Auge. Um das Sprint-Ziel zu erfüllen, implementiert es Funktionalität und Technologie. Wenn sich die Arbeit als anders herausstellt als vom Entwicklungsteam erwartet, arbeitet es mit dem Product Owner zusammen, um den Umfang des Sprint Backlog innerhalb des Sprints auszuhandeln.
Geschwindigkeit ist eine häufig verwendete Metrik in agilen Frameworks, ist aber formal kein Teil von Scrum. Darüber hinaus dient der korrekte Einsatz von Velocity niemals als Managementziel oder als Maß für die Produktivität. Bei richtiger Anwendung sollte die Geschwindigkeit sein:
In Scrum sollte die geplante Arbeit niemals die Länge einer einzelnen Iteration überschreiten. Eine frühe Fertigstellung ist großartig, während ein unzureichender Durchhang normalerweise den Durchfluss und den Durchsatz verringert.
Während die Velocity bei der anfänglichen Backlog-Schätzung , der agilen Release-Planung , der Vorhersage der Kapazität für den aktuellen Sprint oder der Identifizierung versteckter Prozessprobleme durch Trendlinienanalyse hilfreich sein kann , ist sie definitiv kein genaues Maß für die Produktivität auf individueller oder gar Teamebene. Es ist ein Planungswert und (in geringerem Maße) eine Detektivkontrolle für das Projekt.
Geschwindigkeit wird oft als Managementziel missbraucht und als Möglichkeit, „Entwickler zur Rechenschaft zu ziehen“. Wenn Sie dies tun, machen Sie agil falsch!
Die Geschwindigkeit ist eine Proxy-Metrik für die Kapazität , und Störungen im Fluss sind häufiger auf Folgendes zurückzuführen:
Unter der Annahme, dass Ihr Team eine stabile Geschwindigkeit erreicht hat , sollten Sie, wenn die Geschwindigkeit plötzlich abfällt, auf jeden Fall mit dem Team (und insbesondere dem Product Owner) zusammenarbeiten, um die zugrunde liegenden Prozessprobleme zu identifizieren. Einmal identifizierte Probleme können auf verschiedene Weise angegangen werden, einschließlich Scope-Verhandlungen, vorzeitiger Sprint-Beendigung und Inspektions- und Anpassungsveranstaltungen wie Sprint-Retrospektiven.
Wir sehen am Ende der Sprints, dass nicht alle Punkte abgearbeitet werden.
Ja, das sollte nicht passieren. Tun Sie alles, um dieses Szenario sehr unwahrscheinlich zu machen. Ziehen Sie zum Beispiel eine scheinbar lächerlich wenig ehrgeizige Anzahl von Product Backlog-Einträgen (PBIs) in den Sprint, um dem Team die Erfahrung zu geben, einen Sprint frühzeitig abzuschließen: Was machen sie mit diesem „Slack“? Zeit?. Ein wirklich interessantes Experiment ist es, nur ein PBI in den Sprint zu ziehen, mit dem Ziel, dem Entwicklungsteam die Möglichkeit zu geben, mit Selbstorganisation zu experimentieren: Werden sie „schwärmen“, um die Arbeit abzuschließen?
Gegen Ende ist das Team überfordert und die Qualität wird geopfert, nur um pünktlich zu liefern.
Ja, das sollte auch nicht passieren. Bringen Sie die Teams zusätzlich zu dem obigen Vorschlag dazu, ihre Definition of Done zu überprüfen (sie werden wahrscheinlich eine teilen). Ist es streng genug? Wird es angewendet? Kann irgendetwas automatisiert werden? Qualität ist nicht verhandelbar und null Fehler sind erreichbar.
Erik
Josbel Luna