Ich versuche, mit der Scrum-Methodik „Story Points“ in den Kopf zu bekommen. Als Ausgangspunkt habe ich folgenden Artikel verfolgt:
http://scrummethodology.com/scrum-effort-estimation-and-story-points/
Mit meinem Team verwenden wir den T-Shirt-Größen-Ansatz (S, M, L und zu groß). Wie quantifizieren wir mit diesem Ansatz die Zeit für jede User Story?
Macht gerade:
ein guter Ansatz?
Macht gerade:
- S = 1/2 pro Tag (maximal)
- M = ein Tag (maximal)
- L = 2 Tage (maximal)
ein guter Ansatz?
Absolut nicht. Story Points messen die Komplexität und den Aufwand, der erforderlich ist, um ein Feature fertigzustellen, einschließlich der Definition of Done des Teams. Es ist nicht direkt auf Zeiteinheiten abgebildet und sollte es auch nie sein.
Während der zweiten Hälfte des Sprint Plannings können User Stories aus dem Product Backlog in Aufgaben für das Sprint Backlog zerlegt werden. Als allgemeine Faustregel gilt, dass Sprint Backlog-Aufgaben etwa 0,5 - 2,0 Tage lang sein sollten, damit während der täglichen Standups leicht festgestellt werden kann, ob eine Aufgabe „erledigt“ oder „nicht erledigt“ ist, die User Story selbst jedoch nie auf eine Zeiteinheit abgebildet.
Geschwindigkeit ist eine Metrik zur Bestimmung der Kapazität für den aktuellen Sprint. Obwohl es vernünftig ist zu fragen, ob eine bestimmte Geschichte in die Zeitbox eines einzelnen Sprints passt, ist dies eher eine Kapazitätsfrage als eine Zeitumrechnung. Beachten Sie, dass einige Experten vorschlagen , dass eine einzelne Story niemals 50 % der verfügbaren Kapazität für eine Timebox überschreiten sollte, aber das Scrum-Framework selbst erlaubt einer einzelnen Story bis zu 100 % der geplanten Kapazität. Ihr Kilometerstand kann diesbezüglich variieren.
Wie CodeGnome sagt, möchten Sie die Zeit nicht quantifizieren, sondern den Aufwand abstrahieren und ihn dann als "Geschwindigkeit" verwenden - die abgeschlossenen Punkte mehrerer Sprints messen und ihn dann für Planungszwecke verwenden.
Die relative Größe zwischen den Werten ist ebenfalls wichtig, sodass etwas mit einem Punktwert von 3 etwa dreimal so groß ist wie eine 1 oder 1/3 so groß wie eine 9. Ohne relative Größe variiert Ihre Iterationsgeschwindigkeit stark, je nachdem, ob man macht viele kleine sachen oder nur wenige große dinge. Gehen Sie das Backlog durch und suchen Sie nach Geschichten, die sich in Bezug auf die Größe „in der Mitte“ oder von durchschnittlicher Größe anfühlen, und verwenden Sie dies als mittleren Wert (z. B. 5 auf einer Skala von 1 bis 13). Dann werfen Sie einfach die anderen Geschichten als größer oder kleiner ein und in einem letzten Durchgang, wie viel größer oder kleiner. Nach ein paar Schätzungssitzungen wird es viel einfacher aufgrund der Vertrautheit und einer ständig wachsenden Liste abgeschlossener und bemessener Geschichten, die Sie als Referenz verwenden können ("Triangulation", wenn Sie so wollen).
Die Beziehung zwischen Punkten und Stunden ist eine Verteilung. Ein Punkt entspricht einer Verteilung mit einem Mittelwert von x und einer gewissen Standardabweichung. Dasselbe gilt auch für Zwei-Punkte-Geschichten und so weiter. Es kann zwar zu Überschneidungen in der verstrichenen Zeit zwischen 1- und 2-Punkt-Storys kommen (einige Ein-Punkt-Storys können sich als größer herausstellen, als das Team dachte; einige Zwei-Punkt-Storys werden kleiner) oder zwischen 2- und 3-Punkt-Storys Geschichten gibt es selten Überschneidungen zwischen einer 1-Punkt-Geschichte und beispielsweise einer 13-Punkte-Geschichte in Bezug auf die tatsächlich verstrichene Zeit. Nach alledem warne ich Sie davor, Punkte formal mit Stunden zu verknüpfen. Sie laufen Gefahr, zu vergessen, dass die durchschnittliche Zeit bis zur Fertigstellung jedes Teams so unterschiedlich ist wie ihre Vorstellung davon, was einen Punkt ausmacht. Punkte sind schließlich ein relatives Maß.
Das Auferlegen eines willkürlichen Maximums wird nicht funktionieren, da es eine so große Standardabweichung zwischen den Schätzungen für jeden Punkt / jede T-Shirt-Größe gibt. Diese SD ist der eigentliche Grund dafür, dass wir eine relative Aufwandsschätzung verwenden, anstatt eine Anzahl von Stunden nachzuholen, die sowieso falsch sein wird.
Wenn Sie nun mit Dritten oder Auftragnehmern zusammenarbeiten, müssen Sie in Sprints denken. Wenn Sie einen Sprint mit fester Länge und einer festen Anzahl von Personen haben, dann haben Sie feste Kosten für Ihren Sprint.
Die Sache, die dann variiert, ist die Geschwindigkeit oder die Menge der gelieferten Funktionalität in jedem Sprint oder erledigten Inkrement .
Ich schätze, Sie kennen vielleicht Ihr Budget, und Sie können das Budget anhand der Sprintkosten festlegen und sehen, wie viele Sprints Sie finanzieren können.
Sie stellen das Team so ein, dass es in einem nachhaltigen Tempo liefert, und für jeden Sprint haben Sie funktionierende Software. Sie können jederzeit anhalten und versenden, sobald Sie zufrieden sind.
Wenn Sie mit der Geschwindigkeit unzufrieden sind, müssen Sie sich damit befassen. Sie könnten weitere Teams hinzufügen, das Team vergrößern oder die Entwicklung stoppen.
mwan