Artikel
Kapazitätsplanung in einer agilen Scrum-Umgebung

Die Schätzung ist ein wichtiger Aspekt von Scrum. Jedes Scrum-Team schätzt in seinen Sprint-Planungstreffen den Umfang der Arbeit, die es in seinem kommenden Sprint bewältigen kann. Dazu schätzen sie jede User Story in Story Points und summieren dann die Story Points. In den meisten Fällen wird angestrebt, die Anzahl der Story Points zu erreichen, die der durchschnittlichen Geschwindigkeit der letzten drei Sprints oder in einigen Fällen der durchschnittlichen Geschwindigkeit aller Sprints, an denen das Team gearbeitet hat, entspricht (oder nahe kommt). Aber es gibt ein grundlegendes Problem, wenn wir uns zum Ziel setzen, Story Points zu liefern, die den Story Points entsprechen, die in den letzten Sprints geliefert wurden.
- Wenn im kommenden Sprint ein Feiertag ist, sinkt unsere Kapazität für den Sprint. In diesem Fall ist es offensichtlich, dass wir nicht die gleiche Anzahl von Story Points liefern können wie in den letzten Sprints.
- Wenn wir bei der Sprint-Planung feststellen, dass nur wenige Teammitglieder geplante Urlaube nehmen, ist es offensichtlich, dass wir im kommenden Sprint nicht mit unserer durchschnittlichen Geschwindigkeit arbeiten können.
- Teambesprechungen, Organisationsbesprechungen und andere Verpflichtungen auf Organisationsebene fressen die Zeit der Entwickler auf, so dass sie weniger Stunden als die vorgeschriebenen acht Stunden für die Programmierung zur Verfügung haben.
- Wenn das Team neu ist, dann gibt es keine durchschnittliche Geschwindigkeit. In diesem Fall kann das Team nicht einschätzen, wie viel es in dem bevorstehenden Sprint erreichen kann.
Scrum-Teams berücksichtigen die oben genannten Faktoren und nehmen meist weniger Story Points für den bevorstehenden Sprint. Aber berechnen sie auch, wie viel weniger Story Points sie nehmen sollten, wenn es einen einzigen Tag Urlaub gibt, und wie viel weniger, wenn sie während des Sprints drei Tage Urlaub haben? Und wie viel weniger sollte das Team nehmen, wenn eine Person drei Tage Urlaub hat, während zwei Personen jeweils drei Tage im Urlaub sind? Um diese Probleme zu lösen, messen einige Agile Teams die Kapazität des Teams für jeden Sprint, bevor sie sich auf die Anzahl der Story Points festlegen, indem sie eine Kapazitätsplanung durchführen.
Was genau ist Kapazitätsplanung?
Die Kapazitätsplanung ist ein Prozess, bei dem das Scrum-Team die Gesamtzahl der Stunden berechnet, die dem gesamten Team für die Entwicklungsarbeit im kommenden Sprint zur Verfügung stehen. Wir können die Kapazität eines einzelnen Teammitglieds als ein Glas betrachten, in dem verschiedene Aktivitäten Platz finden (wie in der Abbildung dargestellt). Scrum-Ereignisse, organisatorische Aktivitäten, Urlaub, der in den Sprint fällt, die Verfügbarkeit der Teammitglieder in diesem Projekt, geplanter Urlaub des Teammitglieds, Fokusfaktor und schließlich die Entwicklungszeit füllen das Glas, bis es voll ist. Wenn wir also davon ausgehen, dass die maximale Arbeitszeit eines Teammitglieds in einem zweiwöchigen Sprint 80 Stunden beträgt (8 Stunden x 10 Tage), ergibt sich durch Subtraktion der oben genannten Aktivitätsstunden die genaue Anzahl der Stunden, die ein Einzelner in diesem Sprint für die Entwicklung erhält.

Wenn Sie die Kapazitäten der einzelnen Teammitglieder addieren, erhalten Sie die Gesamtkapazität des Teams.
Die Frage ist nun: Wie können wir die Kapazität des Teams in Stunden der Geschwindigkeit zuordnen, die das Team in Story Points erreichen kann?
Scaled Agile Framework (SAFe) hat einen sehr guten und einfachen Leitfaden zur Ermittlung der Kapazität des Teams gegeben, wenn keine historischen Daten vorliegen:
- Geben Sie dem Team für jeden Vollzeitentwickler und -tester im Team acht Punkte (passen Sie diese für Teilzeitmitarbeiter an)
- Ziehen Sie für jeden Urlaubstag und jeden Feiertag eines Teammitglieds einen Punkt ab.
- Suchen Sie sich eine kleine Geschichte aus, deren Entwicklung etwa einen halben Tag in Anspruch nimmt, und einen halben Tag, um sie zu testen und zu validieren, und schon ist sie fertig.
- Schätzen Sie jede andere Geschichte in Relation zu dieser ein.
Beispiel: Angenommen, ein siebenköpfiges Team, bestehend aus drei Entwicklern, zwei Testern, einem Product Owner und einem Scrum Master, hat keinen Urlaub und eine zweiwöchige Iteration.
Geschätzte Kapazität = 5 x 8 Punkte = 40 Punkte/Iteration.
Wie können wir nun die Kapazität in Story Points ermitteln, wenn wir eine historische Geschwindigkeit eines Teams haben, aber im kommenden Sprint feststellen, dass es Urlaube und geplante Abgänge von Mitarbeitern gibt?
Berechnen Sie zunächst die Gesamtzeit, die das Team in diesem Sprint mit Zeremonien verbringen wird:.

Berechnen Sie als Nächstes Urlaub, Abwesenheit von Teammitgliedern und Engagement in anderen Projekten, Fokusfaktoren usw. Ziehen Sie diese Zeit von den Arbeitsstunden ab, um die produktiven Stunden für jede Person für den Sprint zu erhalten.

Nehmen Sie die durchschnittliche Geschwindigkeit des Teams aus früheren Sprints. Ermitteln Sie die Kapazität, die Ihr Team für diese historischen Sprints hatte. Teilen Sie die Geschwindigkeit in Story-Points eines jeden Sprints durch die entsprechende Kapazität in Stunden. So erhalten Sie ein Maß für die Geschwindigkeit Ihres Teams pro Stunde. Sie können den Durchschnitt der Geschwindigkeit Ihres Teams pro Stunde für alle historischen Sprints nehmen, um die durchschnittliche Geschwindigkeit Ihres Teams pro Stunde zu ermitteln. Ermitteln Sie nun die Anzahl der Story-Points, die Sie für diesen Sprint nehmen können, indem Sie die Kapazität des Teams in Stunden mit der durchschnittlichen Geschwindigkeit pro Stunde multiplizieren.
Mit der obigen Methode können Sie also ganz einfach die Kapazität des Teams im kommenden Sprint messen und die entsprechende Anzahl von Story Points festlegen, wobei Sie alle Faktoren berücksichtigen, die die Geschwindigkeit Ihres Sprints beeinflussen können.
Unsere Ideen
Weitere Artikel

Der Aufstieg der Künstlichen Intelligenz (KI): Transformation von...
Entdecken Sie, wie KI Organisationsstrukturen, Arbeitsabläufe und Führungsqualitäten revolutioniert und die Effizienz und Anpassungsfähigkeit in der...
Daniel Burm

Der Slam Dunk der KI: Xebia’s Innovation Xchange trifft auf March Madness
KI trifft auf March Madness: Entdecken Sie, wie AWS, Axos Bank & Morgan Lewis KI nutzen, um das Wachstum voranzutreiben, Systeme zu modernisieren...
Matt Gosselin
Contact

