Mein Team arbeitet in einem 3-Wochen-Sprint, und dementsprechend berechnen wir die Kapazität des Teammitglieds auf der Grundlage seiner oder ihrer geplanten Ferien und Betriebsferien.
Aber wir können keine ungeplanten / krankheitsbedingten Abwesenheiten, ungeplanten Meetings und Schulungen leugnen. Unterschiedliche Kommunikation zwischen und innerhalb von Teams, die für mein eigenes Projekt oder andere Teams wichtig sein können. Wissensaustausch ist ein wichtiger Kernwert einer wachsenden Organisation, die offene teamübergreifende Interaktionen fördert.
Verschiedene Sprint-Zeremonien nehmen in diesen 3 Wochen auch einige Zeit der Teammitglieder in Anspruch. Welche Punkte sind wichtig, um die Kapazität der Teammitglieder zu berechnen, wenn man bedenkt, dass sie 8 Stunden im Büro verbringen.
Ich schließe daraus, dass Ihr Team Story Points für eine erste Schätzung verwendet und dann beim Planungsmeeting Storys in Aufgaben aufteilt und sie auf Stundenebene schätzt.
Zunächst einige allgemeine Vorschläge:
Planen Sie niemals 8 Stunden am Tag ein. Unterbrechungen passieren. Planen Sie nur ca. 6 Stunden pro Tag für Entwicklungsaufgaben ein.
Stellen Sie sicher, dass Sie diese geplanten freien Tage aus der Kapazität des Teams entfernen. Achten Sie auch darauf, bekannte Besprechungszeiten aus der Kapazität zu entfernen.
Aber das scheinst du ja schon zu wissen. Sie möchten wissen, wie Sie mit unerwarteten Abwesenheiten umgehen.
Lassen Sie etwas Spielraum in Ihrer Planung.
Wir Menschen sind wirklich schlecht im Schätzen. Dinge dauern in der Regel länger, als wir davon ausgehen. Wenn Sie in Ihrem Zeitplan etwas Spielraum lassen, können Sie sowohl die schlechten Schätzungen als auch einige Abwesenheiten auffangen. Wenn das Team sein Iterationsziel frühzeitig erreicht, hat es etwas Zeit, um einige technische Schulden zu begleichen.
Akzeptieren Sie, dass jede gegebene Schätzung wahrscheinlich falsch sein wird und Sie nicht immer alle Geschichten erledigen werden, selbst wenn jeden Tag jede auftaucht.
Machen Sie sich im Grunde keine Sorgen. Nehmen Sie sich etwas Zeit, um sich daran zu erinnern, dass Entwickler Menschen sind, dass Sie eine Person sind und keine Maschinen, die Code generieren. Akzeptieren Sie die Ungewissheit der Softwareentwicklung und finden Sie Wege, flexibel zu sein. Können wir eine Geschichte aus dieser Iteration streichen? Joe hat seine Aufgaben früher erledigt, kann er Susys abholen, während sie weg ist? Können wir diese Iteration um eine weitere Woche verlängern? Lernen Sie, flexibel zu sein (ich wage es zu sagen, agil ) und reagieren Sie mit Anmut auf das Unbekannte.
Sie haben es also versäumt, jede Geschichte in der Iteration zu liefern? Große Sache. Es passiert. Bringen Sie es im Retro zur Sprache, lassen Sie das Team darüber sprechen, warum und wie es die Auswirkungen ungeplanter freier Tage verringern kann. Sie werden viel bessere Ideen haben als Fremde im Internet.
Stoppen Sie die Schätzung des Stundenniveaus.
Nach meiner persönlichen Erfahrung ist es größtenteils Zeitverschwendung, die ein falsches Gefühl des Wissens erzeugt. Verwenden Sie stattdessen die historische Anzahl abgeschlossener Story Points als Kapazität Ihres Teams. In jedem konkreten Fall wird es falsch sein, aber auch die Kapazitätsplanung auf Stundenebene. Manchmal schaffen sie mehr, manchmal weniger, aber im Durchschnitt ist dies ein ziemlich guter Hinweis darauf, wie viel das Team in einer Iteration erreichen kann.
Das Ziel ist nicht der reine Durchsatz von Aufgaben. Das Ziel ist eine Iteration einer funktionierenden und wertvollen Software. Erledigen Sie das Wichtigste zuerst, und das haben Sie, egal ob jemand im Team für ein paar Tage krank wird oder nicht.
Der Scrum Guide sagt dies zu den Dingen, die bei der Festlegung der Commitments für den nächsten Sprint zu berücksichtigen sind.
Der Input für dieses Meeting ist das Product Backlog, das neueste Produktinkrement, die voraussichtliche Kapazität des Entwicklungsteams während des Sprints und die bisherige Leistung des Entwicklungsteams. Die Anzahl der aus dem Product Backlog für den Sprint ausgewählten Elemente liegt allein im Ermessen des Entwicklungsteams. Nur das Entwicklungsteam kann beurteilen, was es im bevorstehenden Sprint erreichen kann.
Das Wichtigste, was Sie berücksichtigen müssen, ist der tatsächliche Nachweis Ihrer bisherigen Arbeit . Das Maß dafür, wie viel Ihr Team in einer Iteration erledigen kann, wird normalerweise als Velocity bezeichnet .
Es spielt keine Rolle, ob Teammitglieder 8 Stunden dort sind. Es spielt keine Rolle, dass es manchmal Meetings gibt. Wir sind an diesen Dingen nicht individuell interessiert, und es ist viel besser, das, was uns wichtig ist, direkt zu messen, unsere Velocity.
Beachten Sie, dass das Entwicklungsteam (nicht der Scrum Master) für die Entscheidung über Verpflichtungen verantwortlich ist und dass die Leistung als Team und nicht als Einzelpersonen gemessen wird .
Während der Scrum-Leitfaden das „Wie“ die Geschichten des Entwicklungsteams schätzt, als Übung für den Leser überlässt, verwenden die meisten erfolgreichen Teams so etwas wie Story-Punkte .
Nehmen wir zum Beispiel an, mein Team hat ein paar Storys der Größe (in Punkten hat links die höchste Priorität) { 1, 5, 8, 3 }. Wenn wir im letzten Sprint 6 Punkte geschafft haben, weiß das Team sich zu wehren 1und 5nur zu nehmen. Wenn wir 9 Punkte geschafft haben, wissen wir, dass ich es mit 1, 5und aufnehmen kann 3. Was die Entscheidungen des Teams antreibt, sind Beweise aus früheren Iterationen. Ein "Punkt" ist mit keiner Zeit verbunden, außer durch unsere evidenzbasierte Geschwindigkeitsmessung.
Teams, die Stundenschätzungen in der Praxis verwenden, nutzen die Geschwindigkeit nicht gut und planen daher schlecht.
Also zusammenfassend,
Schätzen Sie die Kapazität Ihres Teams als aggregierten Bereich basierend auf der historischen Leistung und nicht als Summe der idealen Stunden, die jedem Einzelnen zur Verfügung stehen. Darüber hinaus sollten Sie sorgfältig überlegen, was Sie mit einer solchen Berechnung erreichen möchten, und feststellen, ob ein agilerer Ansatz für Produktivität und statistische Schätzungen nicht besser geeignet ist.
Mein Team arbeitet in einem 3-Wochen-Sprint, und dementsprechend berechnen wir die Kapazität des Teammitglieds auf der Grundlage seiner oder ihrer geplanten Ferien und Betriebsferien.
In Scrum wird Geschwindigkeit oder Kapazität für eine Person niemals berechnet. Stattdessen berechnen Sie die prognostizierte Kapazität des gesamten Teams basierend auf empirischen Messungen der bisherigen Leistung und erwarten, dass sich geringfügige Abweichungen in der individuellen oder iterativen Kapazität im Laufe der Zeit ausgleichen.
Noch wichtiger ist, dass Sie zwar verschiedene Techniken verwenden können, um die idealen Stunden abzuschätzen, die dem Team zur Verfügung stehen, aber dies gibt Ihnen keine gute Vorhersagbarkeit hinsichtlich des Arbeitsaufwands , den Sie in einem Sprint erledigen können. Sofern es nicht Ihr allererster Sprint ist, sind Sie viel besser dran, wenn Sie eine relative Dimensionierung (z. B. Story Points) verwenden und schätzen, wie viel Arbeit Sie in einer bestimmten Iteration erledigen können, basierend auf empirischen Daten darüber, wie viel Arbeit das Team leisten konnte in der Vergangenheit zu erfüllen.
Selbst wenn Sie sich dafür entscheiden, ideale Stunden anstelle von Story Points zu verwenden, würden Sie eine Teamkapazität berechnen. Zum Beispiel:
Ein fünfköpfiges Team hat also in einem dreiwöchigen Sprint 60-90 ideale Arbeitsstunden zur Verfügung. Sie könnten hier einfach aufhören und statistische Schwankungen sich selbst ausbügeln lassen.
Alternativ können Sie einen Fudge-Faktor anwenden, um bekannte Probleme in einem bevorstehenden Sprint auszugleichen. Zum Beispiel könnten Sie:
Pragmatisch neige ich dazu, Fudge-Faktoren für große potenzielle Geschwindigkeitseinbußen anzuwenden, ignoriere sie jedoch im Allgemeinen für geringfügige Störungen wie geplante Zahnarzttermine.
Es scheint wahrscheinlich, dass Ihr eigentliches Problem nicht ein Mangel an präziser Schätzung ist, sondern dass Sie Teammitglieder als individuelle Ressourcen behandeln und danach streben, die Auslastung und nicht den Durchsatz zu optimieren. Obwohl Sie dies nicht ausdrücklich gesagt haben, impliziert die Art und Weise, wie Ihre Frage formuliert ist, zumindest, dass Aufgaben Einzelpersonen zugewiesen werden und nicht kollektiv im Besitz des Teams sind, und daher kann die Abwesenheit oder eingeschränkte Kapazität eines Mitglieds des Teams zu Engpässen führen oder Abhängigkeiten innerhalb Ihrer Bereitstellungspipeline aufdecken.
Tu das nicht.
Stellen Sie stattdessen sicher, dass Backlog-Elemente im Besitz des gesamten Teams sind und dass das Team kollaborativ daran arbeitet, Storys fertigzustellen, anstatt sequentiell oder parallel. Außerdem sollten Backlog-Items möglichst unabhängig voneinander sein, damit die Unfähigkeit, eines aufgrund von Ressourcen- oder Zeitbeschränkungen zu erledigen, nicht auch für andere Backlog-Items „anhält“.
Auch wenn Sie nicht die gerade skizzierten Fehler machen, nehmen Sie sich bitte etwas Zeit, um wirklich zu überlegen, warum Sie versuchen, Kapazitätsmetriken auf die individuelle Ebene zu verfolgen, anstatt den teambasierten Ansatz zu verfolgen, der den meisten agilen Methoden zugrunde liegt. Sie werden überrascht sein, dass dies unter vielen Umständen unnötig und sogar kontraproduktiv ist.
Versuchen Sie, die LEAN-Idee von „Verschwendung“ zu übernehmen
Lassen Sie das Team seine Stunden anhand von Aufgaben, Besprechungen, Verwaltung usw. aufzeichnen, damit Sie genau ausrechnen können, wie viel Zeit Sie jede Woche für „nicht arbeitsbezogene“ Aufgaben aufwenden.
Dies gibt Ihnen sowohl einen durchschnittlichen Prozentsatz der „verschwendeten“ Zeit, die Sie in die Kapazität des Einzelnen einbeziehen können, als auch die Möglichkeit, Dinge zu identifizieren, die Sie streichen können, um die Kapazität zu erhöhen
Anstatt zu versuchen, ungeplante Besprechungen, Schulungen oder Krankheitstage einzuplanen, planen Sie jeden Tag eine Reihe von Stunden für teamorientierte Aktivitäten ein, wie zum Beispiel:
Erstellen Sie außerdem eine Reserve-Story, die einen Prozentsatz der Kapazität jedes Teammitglieds in jedem Sprint erfasst, um vorhersehbare Aktionspunkte zu bewältigen, wie zum Beispiel:
Verweise
Anurudh Singh
Nathan Cooper
Nathan Cooper