Wir arbeiten in einem Full-Stack-Entwicklungsteam, das aus drei Gilden (Backend, Frontend, QA) besteht, also teilen wir uns als Team ein einziges Sprintboard.
Benutzergeschichten, die wir in unsere Sprints aufnehmen, sind so geschrieben, dass sie möglicherweise die Arbeit von mindestens einer oder mehreren Gilden erfordern.
Bisher erhielt die Geschichte eine Einzelwertung als Zusammensetzung von Stimmen für alle beteiligten Gilden. Aber auf diese Weise können wir nicht sagen, wie schwer die Geschichte für jede einzelne beteiligte Gilde sein wird, was uns Komplikationen in Sprint-Planungsmeetings und später in Sprints bereitet.
Stellen Sie sich vor, Sie möchten die Teameffektivität maximieren, indem Sie die Ausfallzeiten jeder Gilde minimieren. Da (ich weiß nicht jede) User Story von mehreren Gilden parallel bearbeitet werden kann, können Sie dies tun, indem Sie solche Storys zum Sprinten auswählen, wobei die Zusammenfassung der Schätzungen für jede Gilde die nächste Kapazität dieser Gilde ergibt. Natürlich darf man nicht vergessen, mit Abhängigkeiten zwischen Geschichten zu rechnen.
Ist es in Ordnung, dass Einzelbenutzergeschichten Schätzungen für jede der beteiligten Gilden haben? Und wenn ja, kann Jira (Cloud) damit umgehen? Hat jemand persönliche Erfahrungen?
Wir haben auch darüber nachgedacht, nur Teilaufgaben zu schätzen, nicht die User Story selbst, aber wir haben das verworfen, weil dies die Schätzung unangemessen aufblähen würde.
Stellen Sie sich eine einzelne Geschichte vor, in der alle drei Gilden arbeiten müssen. In der Verfeinerung erhält die Story folgende Einschätzungen (3 SP: Backend, 1 SP: Frontend, 2 SP: QA). Die Gilden einigen sich auf eine Einzelschätzung von 5 SP und geben diese an die Userstory weiter. Unteraufgaben für jede Gilde bleiben ungeschätzt (mit Schätzung Null).
Im Gegensatz dazu, wenn die Geschichte selbst keine Bewertung (Null) erhalten würde, aber Unteraufgaben für jede Gilde ihre jeweilige Bewertung erhalten würden. Dies würde zu einer unangemessen höheren SP-Anzahl führen (hier 6 SP statt 5 SP im ersten Fall), da Sie alle SPs für jede Teilaufgabe summieren müssten.
Stellen Sie sich vor, Sie möchten die Teameffektivität maximieren, indem Sie die Ausfallzeiten jeder Gilde minimieren.
Der Versuch, mehr Arbeit aus einem Team herauszuholen, indem Ausfallzeiten minimiert werden, wird als Ressourcenauslastungsfalle bezeichnet. Hier ist ein nettes Video, das zeigt, wie die Minimierung von Ausfallzeiten die Leistung des Teams nicht wirklich erhöht.
Das Ziel eines Sprints sollte nicht sein, dass alle die ganze Zeit beschäftigt sind, sondern die Menge an Arbeit, die in guter Qualität geliefert wird.
Die Optimierung der Arbeitsmenge, die geliefert werden kann, beginnt damit, zu wissen, wie viel Arbeit das Team als Ganzes innerhalb der Timebox eines Sprints zum Abschluss bringen kann. Und da wir das Team als Ganzes betrachten, liegt der größte Wert in einer Schätzung für das gesamte Team.
Es gibt einen Punkt, an dem Schätzungen pro Disziplin nützlich sein können, und dann sind traditionelle Schätzungen in Stunden am nützlichsten. Das ist während der Planung, wenn es eine ziemlich starke Spezialisierung innerhalb des Teams gibt, um sicherzustellen, dass die geplante Arbeit eine Disziplin nicht zu sehr überlastet.
Es wird nicht erwartet, dass diese Schätzungen dauerhaften Wert haben, also können Sie sie einfach während der Planungssitzung auf einem Blatt Papier notieren oder, wenn Sie es gewohnt sind, früher zu schätzen, einen Kommentar in das Ticket eintragen.
In dieser Situation würden Sie die Storys zunächst entsprechend der Kapazität des gesamten Teams planen, um Arbeit zu liefern. Dies basiert normalerweise auf ihrer bisherigen Erfolgsbilanz, die durch die Geschwindigkeit angezeigt wird, die sie in den vergangenen Sprints erreicht haben. Nachdem das Team angegeben hat, dass es ziemlich zuversichtlich ist, dass es die auf dem Tisch liegende Arbeit vollständig abschließen kann, aber keine weitere aus dem Rückstand abschließen kann, würden Sie eine Gegenprüfung durchführen, indem Sie die erwartete Verfügbarkeit der Teammitglieder mit der vergleichen Schätzungen pro Disziplin, um sicherzustellen, dass die Last nicht zu verzerrt ist. Wenn das Team reifer wird, stellen Sie möglicherweise fest, dass es sich früher in der Planung über eine schiefe Ladung beschwert. In jedem Fall, wenn die Last verzerrt ist, kann eine Verhandlung mit dem Product Owner geführt werden, um etwas Arbeit auszutauschen, um die Arbeit mehr auszugleichen (und wenn Sie Glück haben, mehr Arbeit zu übernehmen).
Die Verwendung von Begriffen wie "Gilde" lässt mich denken, dass Sie ähnlich wie das Spotify-Modell organisiert sind. Was Sie als "Gilde" bezeichnen, scheint damit jedoch nicht vereinbar zu sein. Im Spotify-Modell wird die Arbeit von einem funktionsübergreifenden Team erledigt, das sie als „Squad“ bezeichnen. Eine Gilde ist eine gruppenübergreifende (und auch stammübergreifende) Organisation, die an einer bestimmten Art von Querschnittsproblemen arbeitet, um Wissen in der gesamten Organisation zu verbreiten.
Typischerweise wünscht man sich bei allen agilen Methoden funktionsübergreifende Teams, die die Arbeit übernehmen. Das bedeutet, dass das Team über alle Fähigkeiten verfügt, die erforderlich sind, um ein beliebiges Stück Arbeit von seinem Anfangszustand in einen definierten Endzustand zu bringen, ohne das Team zu verlassen. Es ist nicht immer erreichbar – es kann Fachexperten geben, auf die das Team für einige Arbeiten zurückgreifen muss – aber es ist ein erwünschter Zustand.
Wenn Sie Ihre Arbeit so strukturieren würden, wäre das Team in der Lage, den Aufwand für die Erbringung der gesamten Arbeit abzuschätzen. Idealerweise gäbe es keine Abhängigkeiten außerhalb des Teams. Wenn es eine Abhängigkeit gäbe, dann kann das bei der Schätzung berücksichtigt werden, aber ich würde vermuten, dass dies einen viel größeren Einfluss auf die Planung der Arbeit hätte als die Schätzung der Arbeit.
Die funktionsübergreifende Teamstruktur würde wahrscheinlich auch zu weniger Widerstand der von Ihnen verwendeten Tools führen, solange Sie so konfiguriert sind, dass sie so verwendet werden, dass sie agile Softwareentwicklungsmethoden unterstützen.
Meridius
Bart van Ingen-Schenau
Bart van Ingen-Schenau