Ich bin Scrum Master eines Teams mit 12 Mitgliedern. Ich weiß, dass die Größe des Teams zu diesem Zeitpunkt groß ist, aber wenn wir weiter wachsen, werden wir das Team in mehrere Scrum-Teams aufteilen. Unsere Schätzungen für die User Storys basieren auf Story Points. Für die Aufgaben innerhalb einer User Story veranschlagen wir Stunden. Basierend auf den ersten 6 Sprints konnten wir ein Team Velocity aufbauen.
Wir hatten keine Probleme beim Aufnehmen der User Stories, weil wir wussten, wie viele User Stories wir basierend auf unserer Velocity für den Sprint nehmen könnten. Als ein paar Teammitglieder in einen geplanten Urlaub gingen, konnten wir die Anzahl der Story Points, die wir binden mussten, nicht abschätzen. Da wir die Geschwindigkeit nicht pro Teammitglied berechnen, können wir nicht abschätzen, wie viele Story Points wir für den nächsten Sprint nehmen sollten. Meine Frage ist also, wie wir die Story Points berechnen, die wir für den Sprint festlegen können, wenn einige der Teammitglieder beurlaubt sind ?
Meine zweite Frage ist, dass wir die Anzahl der Stunden berechnen, die jedem Teammitglied für den Sprint zur Verfügung stehen. Da wir Story Points nicht direkt Stunden zuordnen sollten, sehen wir keinen Wert darin, die Anzahl der Stunden für jedes Teammitglied während des Sprint-Planungsmeetings zu berechnen. Wie stellen wir eine Beziehung zwischen Stunden und Story Points her?
Geschwindigkeit ist kein Managementziel. Es ist ein Schätzungstool, und Sie sollten es als ein Tool unter vielen verwenden, um Ihre Sprints zu planen. Behandeln Sie Velocity-Metriken nicht als Ziele oder das Aufrechterhalten einer bestimmten Velocity als primäres Ziel jedes Sprints.
Stunden und Story Points haben keinen direkten Bezug zueinander. Story Points messen den relativen Aufwand, während Stunden die ideale Zeit oder die normale Zeit messen. Sie sind beide nützlich, aber nicht austauschbar.
Geschwindigkeit ist ein Bereich , kein einzelner Wert, und ist im Allgemeinen am nützlichsten, wenn:
Wenn Sie jedoch nicht genügend Geschwindigkeitsdaten gesammelt haben, um Kapazitätsschwankungen auszugleichen, müssen Sie stattdessen etwas gesunden Menschenverstand anwenden. Betrachten Sie diese Beispiele:
Wenn Sie Scrum seit einem Jahr betreiben, werden die Leute von Zeit zu Zeit krank, gehen in den Urlaub oder arbeiten über oder unter ihrer typischen Kapazität. Velocity mittelt diese Datenpunkte über die Zeit und ermöglicht es Ihnen trotzdem, vernünftige Schätzungen vorzunehmen.
Sie machen Scrum erst seit zwei Monaten und hatten für beide Sprints alle Hände voll zu tun. Sie haben keine Daten zur normalen Variation und keine Informationen zur maximalen oder minimalen Teamkapazität. Sie müssen daher einen Fudge-Faktor anwenden .
In Scrum besteht das Hauptziel des Sprint -Plannings darin, ein Überengagement während eines Sprints zu vermeiden. Die Idee ist nicht, den Trugschluss der 100-prozentigen Auslastung zu erfüllen; Sie müssen nicht jeden Sprint basierend auf Ihrer vorherigen Geschwindigkeit auf die Dachsparren packen.
Die Sprint-Planung funktioniert so, dass die Geschwindigkeit einfach eine Anleitung bietet und Sie wissen lässt, ob Sie die angemessenen Work-in-Progress-Grenzen für einen einzelnen Sprint überschritten haben. Es ist allein Sache des Entwicklungsteams zu bestimmen, wie viele Story Points bequem in die aktuelle Iteration passen.
Wenn Sie in Ihrem Beispiel für einen Sprint unterbesetzt sind, wird erwartet, dass das Team diese Tatsache anerkennt und sich während der Sprint-Planung entsprechend anpasst. Das Team könnte zum Beispiel sagen:
Normalerweise versuchen wir, unsere Story Points auf 10-15 Punkte pro Sprint zu begrenzen. Bob lässt sich jedoch COBOL-basierte kybernetische Implantate in seine Großhirnrinde einsetzen, also sollten wir uns dieses Mal wahrscheinlich nur auf 8 Punkte oder weniger festlegen.
Das Team akzeptiert dann nur 8 Punkte für den Sprint, basierend auf seiner erwarteten Kapazität. Wenn sie jedoch vorzeitig fertig sind, können (und sollten) sie zum Product Owner zurückkehren, um:
Die erste ist die üblichste Praxis, aber die zweite ist innerhalb der Grenzen des Scrum-Frameworks sicherlich akzeptabel. Es hängt wirklich nur davon ab, was für Ihr Team am besten funktioniert.
Die Teamgeschwindigkeit ist ein Maß für die bisherige Leistung des Teams – wie viel Wert sie in jedem Sprint erbringen konnten, und wird in Story Points gemessen. Geschwindigkeit ist hilfreich, um vorherzusagen, wie viele Storys das Team im nächsten Sprint fertigstellen kann. Die Geschwindigkeit ist jedoch nicht der einzige Faktor, der dies vorhersagt. Die Teamkapazität kann ein weiterer Faktor sein. Nehmen wir ein Beispiel:
Ihr Team besteht aus 5 Mitgliedern und die Velocity beträgt 60 Story Points pro Sprint. Ein Mitglied ist während des nächsten Sprints im Urlaub. Die Teamkapazität wird also um 20 % sinken. Ihre geschätzte Geschwindigkeit für diesen Sprint wäre dann 48 Story Points. 60 * (100 % - 20 %) = 60 * 0,80 = 48
Dies ist eine Option, die in Betracht gezogen werden kann, denke ich.
Aufgrund der Komplexität eines Teams werden Sie niemals das Story Point / Person-Verhältnis berechnen können. Wenn Sie also das Sprint Backlog zusammenstellen, verwenden Sie die User Storys aus dem Backlog und den Kapazitätsplan (dieser sagt Ihnen, wie viele Personen während des bevorstehenden Sprints an Bord sein werden) . Sie verpflichten sich auf der Grundlage dieser Daten. Die Velocity hilft dir, dich in einem Sprint nicht zu überfordern. Es ist also nicht so hilfreich.
Basierend auf Ihrer Frage verwenden Sie die geschätzten Stunden für nichts. Wenn Ihre Arbeit auf Story Point basiert, benötigen Sie die Stunden überhaupt nicht. Wenn es möglich ist, versuchen Sie nicht, Story Points in Stunden umzuwandeln. Sie sind nicht umbaubar, so wie man ein Pferd nicht in ein Fahrrad umbauen kann. Beide können für Reisen verwendet werden, aber es gibt keine anderen Gemeinsamkeiten.
Es gibt jedoch etwas, das Sie ausprobieren können, was Ihnen bei Ihrer ersten Frage helfen kann. Wenn Sie die Stunden für die Aufgaben schätzen, können Sie diese zusammenfassen und anhand der Kapazität prüfen, ob die Summe zu Ihrem bevorstehenden Sprint passt . Sie haben beispielsweise 2 User Storys. US1 hat 2 Aufgaben und die Summe beträgt 48 Stunden. US2 hat 3 Aufgaben und die Summe beträgt 68 Stunden. Nehmen wir an, die 12 Kollegen schaffen 120 Stunden in einem Sprint. Ohne 2 hast du nur 100 Stunden, also passen US1 + US2 nicht in deinen Sprint. Sie können US2 weglassen oder in US2.1 und US2.2 aufteilen. Ich denke, das könnte in deinem Fall funktionieren.
Ich denke, Sie verwenden den Geschwindigkeitsbegriff falsch, kehren wir zum Wesentlichen zurück. Der Story Point ist eine grobe Schätzung des Aufwands, der zur Implementierung einer Story erforderlich ist, und wird normalerweise während der Release-Planung oder Vorplanungssitzung verwendet.
Die Geschwindigkeit ist die Gesamtzahl der Story Points, die während des vergangenen Sprints implementiert wurden, und dies wird von einem Sprint zum anderen variieren. Story Points und Sprint Velocity geben uns dann eine Richtlinie über die geschätzten Stories, die in den kommenden Sprints begangen werden sollen.
Die Schätzung der Aufgabenstunden erfolgt während der Sprintplanung. Es handelt sich um eine Schätzung auf niedriger Ebene, die vorgenommen wird, um den tatsächlichen Aufwand in Stunden darzustellen, der erforderlich ist, um alle Anforderungen einer Story zu erfüllen.
Zu Ihrer ersten Frage, es gibt keinen wissenschaftlichen Weg, dies zu tun. Hier ist ein schneller und schmutziger Weg.
Anteil der Personen im Team bei dieser Iteration x Geschwindigkeit des Teams. Wenn Ihre Team-Velocity also 10 beträgt und 1/3 Ihres Teams ausfällt, könnte 6 eine faire Prognose für Ihre mögliche Velocity sein. Eine Reichweite zu haben wäre besser, also vielleicht 5-8 im obigen Szenario. Der Wert besteht darin, die Annahmen zu verstehen, die Sie zur Anpassung Ihrer Geschwindigkeitsprognose verwendet haben.
Was auch immer Sie tun, Geschwindigkeit ist ein Werkzeug, das den Teammitgliedern hilft, ihre Arbeit zu diskutieren und zu verstehen. Wenn also Teammitglieder unterwegs sind und Sie sich nicht sicher sind, wie nützlich Velocity als Werkzeug ist, fragen Sie einfach Ihre verbleibenden Teammitglieder: „Erscheint das, was wir auf Grundlage unserer angepassten Velocity zusagen/prognostizieren, vernünftig?“
Zu deiner zweiten Frage. Mach dir keine Sorgen. Story Points sind zeitliche Verteilungen und sollten nicht für die Kapazitätsplanung oder Berichterstellung außerhalb des Teams verwendet werden. Wenn Sie in zeitbasierte agile Methoden einsteigen möchten, ist Lean Kanban Ihr nächster Stellvertreter, der die Zykluszeit und ihre Varianz verwendet.
Wenn Sie keinen Wert darin sehen, die Anzahl der Stunden zu berechnen, die jedem Teammitglied für jede Iteration zur Verfügung stehen, hören Sie damit auf :). Es ist sehr üblich, dass Scrum-Teams aufhören, Stundenschätzungen für ihre Aufgaben zu erstellen, sobald sie erkennen, dass Geschwindigkeit und konsistente Vorgehensweisen zur Schätzung von Story Points gut genug sind, um eine Prognose/Verpflichtung zu erstellen.