Agile Kapazitätsberechnung – Teil 1 von 2

Kapazität eines agil Team ist eine wichtige Kennzahl, die verwendet werden sollte, um dem Team mitzuteilen, wie viel Arbeitsbelastung es während seiner Arbeit übernehmen sollte Sprint-Planungstreffen für einen bevorstehenden Sprint. Wenn Kapazität und Arbeitsbelastung nicht im Gleichgewicht sind, sollten die Teammitglieder ein fundiertes Gespräch mit dem Product Owner darüber führen, wie das Gleichgewicht erreicht werden kann.

Ich werde drei Methoden zur Kapazitätsberechnung vorstellen:

• Methode 1: Die Kapazität muss nicht geschätzt oder berechnet werden. Dies ist eine idealisierte und einfache Methode.
• Methode 2: Die Kapazität wird (in Stunden) anhand einer kleinen Anzahl von Parametern geschätzt. Dies ist eine ungefähre, aber schnelle Methode zur Einschätzung der Kapazität eines agilen Teams für einen Sprint.
• Methode 3: Die Kapazität wird mithilfe eines ziemlich umfassenden, erweiterbaren und anpassbaren Satzes von Parametern genau berechnet (in Stunden). Dies ist eine genaue Methode zur Berechnung der Sprintkapazität eines agilen Teams. Die eigentlichen Berechnungen erfolgen sehr schnell mithilfe einer Excel-Vorlage.

In diesem ersten Teil einer zweiteiligen Blogserie stelle ich die Methoden 1 und 2 vor. Ich werde Methode 3 vorstellen Teil 2. Am Ende von Teil 2 werde ich Empfehlungen dazu geben, welche Methode Sie basierend auf der spezifischen Situation Ihres agilen Teams für Ihren Einsatz auswählen können.

Methode 1: Die Kapazität muss nicht geschätzt oder berechnet werden.

Betrachten wir die einfachste (und etwas idealisierte) Methode eines gut ausgebildeten agilen Teams; Das heißt, ein Team, dessen Mitglieder in der Vergangenheit mehrere Sprints lang als agiles Team zusammengearbeitet und eine stabile Geschwindigkeit erreicht haben. Ein agiles Team hat beispielsweise in den letzten vier Sprints gearbeitet und eine gemessene Geschwindigkeit in einem engen Bereich (innerhalb von plus-minus 10 %) wie 19, 21, 20, 19 Story Points gezeigt. In diesem Beispiel ist die durchschnittliche Geschwindigkeit des Teams (gemittelt über die letzten vier Sprints) = (19+21+20+19)/4 = 19.75 = ca. 20.

Wenn das gleiche Team (genau die gleichen Mitglieder) plant, im nächsten Sprint als Team zu arbeiten, die Anzahl der verfügbaren Arbeitstage im nächsten Sprint dieselbe ist wie in den letzten Sprints und kein Teammitglied erwartet wird Um einen erheblichen Aufwand aus dem Projekt zu ziehen, kann das agile Team in einem solchen Idealszenario problemlos Arbeit im Wert von 20 Story Points für den bevorstehenden Sprint einplanen.

Bei dieser Methode muss die tatsächliche Kapazität des Teams für den bevorstehenden Sprint nicht geschätzt oder berechnet werden, da davon ausgegangen wird, dass mehrere idealisierte Annahmen erfüllt sind, wie zum Beispiel:

• Ein gut eingespieltes, agiles Team hat eine stabile Geschwindigkeit erreicht; und die durchschnittliche Geschwindigkeit, die über die letzten vier Sprints gemessen wurde, ist ein führender Indikator für die geschätzte Geschwindigkeit für den bevorstehenden Sprint.
• Das gleiche gut eingespielte Team wird im nächsten Sprint arbeiten; Das heißt, genau dieselben Mitglieder bleiben bestehen.
• Die Anzahl der im nächsten Sprint verfügbaren Arbeitstage kommt der Anzahl der Arbeitstage in den letzten Sprints sehr nahe; Das bedeutet, dass es beim nächsten Sprint nicht ungewöhnlich viele Betriebsferien geben wird, von keinem Teammitglied erwartet wird, dass es längere Privaturlaube nimmt, und dass von keinem Teammitglied Kapazitätsverluste aufgrund anderer Aufgaben außerhalb der Sprintarbeit erwartet werden.
• Die Technologieplattform bleibt für den nächsten Sprint dieselbe (keine Änderung gegenüber dem vorherigen Sprint).
• Für den nächsten Sprint sind keine neuen Domänenkenntnisse von irgendeinem Teammitglied erforderlich.

Methode 2: Die Kapazität wird anhand einer kleinen Anzahl von Parametern in Stunden geschätzt.

Diese Methode ist anwendbar, wenn eine oder mehrere Annahmen, die Methode 1 rechtfertigen, nicht wahr oder zumindest fraglich sind. Wenn eine oder mehrere der folgenden Bedingungen zutreffen, sollte Methode 1 nicht verwendet werden:

• Das agile Team ist noch kein eingespieltes Team; Es kam in der Vergangenheit zu unregelmäßig wechselnden Geschwindigkeiten von Sprint zu Sprint.
• Die Zusammensetzung des agilen Teams wird sich für den nächsten Sprint wahrscheinlich gegenüber dem vorherigen Sprint ändern; Dies wird sicherlich die Teamdynamik und Teamproduktivität verändern.
• Es wird erwartet, dass sich die Kapazität des Teams für den bevorstehenden Sprint aufgrund der bevorstehenden Ferienzeit, Sommer- oder Winterferien usw. von der des vorherigen Sprints unterscheidet.
• Von den Teammitgliedern wird erwartet, dass sie im nächsten Sprint an einer anderen Technologieplattform arbeiten.
• Ein oder mehrere Teammitglieder müssen neues Fachwissen erlernen und für den nächsten Sprint anwenden.

In einem solchen Szenario können wir die durchschnittliche Geschwindigkeit der Vergangenheit nicht als führenden Indikator für die geschätzte Geschwindigkeit für den bevorstehenden Sprint heranziehen. Wir müssen die Anzahl der Stunden schätzen, die dem Team für die tatsächliche praktische Arbeit während des bevorstehenden Sprints zur Verfügung stehen. Bei dieser Methode wird ein vereinfachtes Modell verwendet, bei dem historische Daten in der Organisation für die typische „praktische Zeit“ an einem bestimmten Acht-Stunden-Tag berücksichtigt werden (sofern diese Daten vorhanden und verfügbar sind). Basierend auf historischen Daten kann das Team 60 bis 80 % des Acht-Stunden-Tages für die tatsächliche praktische Arbeit nutzen. Die verbleibende Zeit (40 % bis 20 %) wird für allgemeine E-Mail- und Telefongespräche, Firmenbesprechungen sowie die Vorbereitung und tägliche Teilnahme aufgewendet Gedränge Besprechungen usw. Jedes Vollzeit-Teammitglied hat also schätzungsweise 4.8 bis 6.4 Stunden pro Tag (oder 24 bis 32 Stunden bei einer 40-Stunden-Woche) für praktische Arbeit. Wenn ein agiles Team beispielsweise aus acht Vollzeitmitgliedern besteht und vierwöchige Sprints verwendet, schätzt es seine Kapazität auf 8 x 4 x 24 = 768 Stunden (unter der Annahme von 60 % praktischer Arbeit) oder sogar so viel 8 x 4 x 32 = 1,024 Stunden (bei 80 % praktischer Arbeit) für die kommende Woche.

Beachten Sie, dass dies nur eine grobe Schätzung der Kapazität eines agilen Teams ist, da sie auf einem einzigen Parameter basiert (Prozentsatz der für praktische Arbeit verfügbaren Zeit, typischerweise 60 % bis 80 %, basierend auf den historischen Daten der Organisation). Wenn keine historischen Daten verfügbar sind, verwenden einige Organisationen eine geschätzte Zahl (z. B. 75 %), basierend auf anekdotischen Beweisen oder ihrem Gefühl, mit dieser Zahl zufrieden zu sein.

Die geschätzte Kapazitätszahl wird verwendet, um dem agilen Team Orientierung zu geben, wie viel Arbeit (zu implementierende Storys oder Features und zu behebende Fehler) für den bevorstehenden Sprint geplant werden kann. Wenn die Teamkapazität beispielsweise auf 800 Stunden geschätzt wird, sollte die geschätzte Arbeit bei etwa 800 Stunden liegen; das Team darf seine Kapazität überschreiten, jedoch nicht mehr als 5 %; Das heißt, in diesem Beispiel sollte die geschätzte Arbeit 840 Stunden nicht überschreiten.

Ein agiles Team muss nun die Anzahl der geplanten Arbeitsstunden auf der Grundlage seines priorisierten Sprint-Backlogs schätzen oder berechnen. Der Aufwand für jede Story und jeden Fehler muss in idealen Stunden (nicht in verstrichenen Stunden) geschätzt werden. Dies kann auf Story- oder Fehlerebene durch das Team erfolgen, basierend auf seinem kollektiven Wissen über die anfallende Arbeit. Alternativ kann jede Story und jeder Fehler in Aufgaben und Tests unterteilt werden; Für jede Aufgabe und jeden Test wird die Anzahl idealer Stunden geschätzt, und diese Schätzungen werden zusammengefasst, um eine Schätzung des Aufwands für Story oder Fehler in idealen Stunden zu erhalten.

Da Methode 2 nur eine Schätzung der Kapazität auf der Grundlage eines einzelnen oder einer kleinen Anzahl von Parametern liefert, handelt es sich nur um eine ungefähre Messung. Wenn Sie die Teamkapazität in Stunden anhand eines umfassenden Satzes von Parametern genau schätzen müssen, müssen Sie Methode 3 befolgen. Diese Methode wird im vorgestellt zweiter Teil dieses zweiteiligen Blogbeitrags.