Ich denke, es gibt einen weiteren Punkt zu dieser Frage, der noch nicht behandelt wurde, und das ist:

Was sollte eigentlich in einem Sprint Planning abgedeckt werden?

(oder warum muss es überhaupt viel Zeit in Anspruch nehmen?)

Kurze Antwort: Bei einer Sprintplanung sollte man nur den Sprint planen .

Was das heißt:

• Betrachten Sie Ihre Aufgaben und Geschichten
• Schnelle Schätzung (wenn Sie Schätzungen vornehmen; z. B. Planungspoker)
  • Betonung auf schnell
  • Wenn die Diskussionen aus dem Ruder laufen, war die Geschichte noch nicht „fertig“.
  • Schätzen Sie Geschichten neu, die zuvor geschätzt wurden, aber noch nicht fertig sind
• Konsens über die Anzahl der Punkte/Geschichten, die in den Sprint gesteckt werden sollen
• mündliche Zusage des gesamten Teams

Warum dauert das also lange?

Weil die Leute viel zu viel in einer Sprintplanung machen. Zu den schlimmsten Planungskillern gehört keine bestimmte Reihenfolge: Aufgabenaufschlüsselung, Aufgabenschätzung, Story-Schätzung, Storys „fertig“ machen, damit sie überhaupt geplant werden können, Features diskutieren, herausfinden, wer überhaupt während des Sprints verfügbar ist. Ich könnte weitermachen. Und das könnte auch das Sprint-Planning sein.

Tun Sie diese Dinge nicht in einer Sprintplanung . Sie planen nicht, sie bereiten vor und Sie bereiten sich im Voraus vor. Denn Wissen ist die halbe Miete .

Ich hatte die besten Ergebnisse , als ich diese Mörder auf diese Weise aus der Planung herausgezogen habe:

• Backlog-Grooming- Sitzungen nach Bedarf
  • mit: Scrum Master, PO und einige, nicht unbedingt alle Teammitglieder (rotieren, wenn Sie nicht das gesamte Team binden möchten)
  • Doing: Review der Stories im Backlog, Nennung/Diskussion offener Punkte und Priorität
  • um: genug Geschichten „fertig“ zu machen, dh genug Informationen zu bekommen, um eine Aufgabenaufschlüsselung vorzunehmen
• Task-Breakdown- Sitzungen
  • mit: Scrum Master, einigen oder allen Teammitgliedern
    • Kürzlich habe ich dies paarweise machen lassen und dann in der nächsten Sitzung von einem anderen Paar überprüft
  • Doing: eine Liste von Aufgaben, die notwendig sind, um die Story zu vollenden, in einem Detaillierungsgrad, mit dem Ihr Team vertraut ist; alternativ offene Fragen notieren und die Geschichte zum Grooming an das Backlog zurückgeben
  • um: mindestens ein bisschen mehr zu bekommen als – bequem doppelt so viel – ungefähr das, was normalerweise in einem Sprint erledigt würde, damit der Sprint mit etwas Spielraum für abgelehnte Stories geplant werden kann

NB: Ich habe 'bereit' ein paar Mal erwähnt. Dies bezieht sich auf die Definition of Done (die definiert, wann etwas als geliefert gilt), deckt aber das andere Ende des Prozesses ab, die Planung Ihres Sprints, die Definition, wann eine Story bereit ist, in Aufgaben aufgeteilt und geschätzt zu werden. Dafür müssen Sie und Ihr Team genau wie beim Verteidigungsministerium herausfinden, was sie brauchen und womit sie sich wohlfühlen.

Ich möchte dir aber ein Beispiel von mir geben:

• Auf alle offenen Fragen wird eingegangen
• Die Priorität der Story im Backlog ist klar
• Die Stakeholder verpflichten sich, während des Sprints für Fragen zur Verfügung zu stehen
• Es gibt keine inkrementellen Schritte (oder kleineren Geschichten), in die diese Geschichte zerlegt werden kann, die einzeln noch Wert schaffen

Endeffekt

Wenn Sie mit einer solchen Aufteilung Ihrer Schritte eine Routine in Gang bringen , wird Ihre Planung nicht viel Zeit in Anspruch nehmen (so wenig wie etwa zwei Stunden für einen zweiwöchigen Sprint) und jeder der Schritte kann flexibel während des Sprints platziert werden um auch Ihren Teilzeitbeschäftigten die Teilnahme zu ermöglichen.

TL;DR

Ihre Teilzeitmitarbeiter müssen für das Sprint Planning anwesend sein. Speziell:

• Unterlassen Sie:
  • bei wesentlichen Rahmenbesprechungen als Stellvertreter eines Teammitglieds fungieren.
  • Versuchen Sie, vom Framework vorgegebene Meetings wie Sprint Planning oder Daily Stand-Up zu umgehen, um Ressourcenengpässen Rechnung zu tragen.
• Stattdessen sollten Sie:
  • Akzeptieren Sie, dass Teilzeitkräfte zusätzlichen Prozessaufwand verursachen, und vermeiden Sie den Trugschluss der 100-prozentigen Auslastung.
  • Passen Sie Ihren Sprint-Zeitplan und Ihre Geschwindigkeitserwartungen an das Team an, das Sie derzeit haben, und nicht an die Team- oder Projektressourcen, die Sie gerne hätten.

Wer sollte am Sprint-Planning teilnehmen?

Jeder im Scrum-Team muss an der Sprint-Planung teilnehmen. Während es wichtig ist, dass alle Teammitglieder an der Schätzung von Product-Backlog-Elementen teilnehmen, ist es entscheidend , dass alle Task-Performer aktive Teilnehmer an der Zerlegung von Storys für das Sprint-Backlog sind.

Warum die Teilnahme am Sprint Planning wichtig ist

Genaue Schätzungen basieren auf dem, was Teammitglieder über eine Geschichte wissen (oder nicht wissen). Sofern Sie nicht vorhaben, die Aufgaben selbst auszuführen, spielt es keine Rolle, ob Sie eine Aufgabe für einfach, schwierig oder zwischendurch halten, da Sie nicht derjenige sind, der die Arbeit erledigt.

Wenn das gesamte Team schätzt, haben Sie einen breiteren Konsens darüber, worum es geht und wie viel Arbeit erforderlich ist. Darüber hinaus trägt in einem teambasierten Ansatz mehr als eine Person zu jeder Geschichte bei, und jede Person, die an einer geschichtenbezogenen Aufgabe arbeitet, muss:

• haben Input darüber, was sie von anderen benötigen, um jede Aufgabe zu erledigen, und
• in der Lage sein, abzuschätzen (und mit dem Rest des Teams darüber zu kommunizieren), wann und wie Übergaben stattfinden werden.

Diese Dinge sind für ein selbstorganisierendes Team essenziell, um sich während eines Sprints untereinander abstimmen zu können. Wenn Sie dies per Proxy tun, werden die selbstorganisierenden Prinzipien, die Scrum nutzen soll, zunichte gemacht.

Im Falle von Teilzeitressourcen ist dies sogar noch wichtiger, da Teilzeitkräfte einen höheren kognitiven und prozessualen Overhead haben als Vollzeitmitarbeiter und sich enger mit dem Rest des Teams abstimmen müssen, um erfolgreiche Übergaben sicherzustellen. Sie machen die Sache noch schlimmer, nicht besser, indem Sie Ihre Teilzeitkräfte im Namen der Effizienz vom Rest des Teams trennen.

Wie lange die Sprintplanung dauern sollte

Dies variiert je nach Team und Projekt, und Sie müssen die Zeitfenster an Ihre spezifischen Bedürfnisse anpassen. Für neue Teams empfehle ich, mit einem ganzen Tag für die Sprintplanung in jedem Sprint zu beginnen, wobei:

• 4 Stunden sind zeitlich begrenzt, um das Sprint-Ziel zu definieren und dann Stories aus dem Product Backlog zu schätzen, zu verhandeln und zu akzeptieren, um dieses Ziel zu erreichen.
• 4 Stunden sind für die Zerlegung von Storys in Aufgaben und Abhängigkeiten für das Sprint Backlog vorgesehen.

Erfahrene Teams können diese Zeit möglicherweise verkürzen, insbesondere durch den effektiven Einsatz von Backlog Grooming, aber der Versuch, sie „nur weil“ zu verkürzen, ist eine falsche Sparsamkeit. Schließlich wird in der Sprint-Planung ein erheblicher Teil der Analyse und des Designs des Teams durchgeführt. Daher ist es viel wichtiger, nur 10 % Ihres Sprints zuzuweisen, um sicherzustellen, dass Sie die richtigen Dinge auf nachhaltige Weise aufbauen, als ein paar zu rasieren Arbeitsstunden aus Ihrem Budget.

Wann Sie ein Sprint-Planning durchführen sollten

Das ist Sache des Teams, aber es sollte einen festen Zeitplan geben. Da Sie versuchen, Teilzeitkräfte einzugliedern, sollte das Team einen Tag wählen, der für so viele Personen wie möglich geeignet ist, und auch die Teilzeitkräfte müssen flexibel sein.

Sprints können an jedem von Ihnen gewählten Wochentag beginnen. Es ist also nichts falsch daran, Ihre Sprints an einem Donnerstag zu beginnen, wenn dies für Ihr Team am besten funktioniert. Entscheidend ist, dass der Zeitplan sowohl vorhersehbar als auch nachhaltig ist .

Sie können die Product-Backlog- und Sprint-Backlog-Sitzungen auch auf mehrere Tage aufteilen, dies führt jedoch zu zusätzlichem Prozessaufwand. Dies kann erforderlich sein, wenn Sie Teilzeit- oder Matrixressourcen haben, aber Ihr Team und Ihre Organisation müssen anerkennen, dass dies Ihren Prozess zusätzlich belastet. TANSTAAFL ; Es ist einfach der Preis, den das Team zahlen muss, wenn es keine dedizierten Ressourcen sicherstellen kann, und die Organisation sollte es als Kosten für die Geschäftstätigkeit behandeln, anstatt es ins Maisfeld zu stecken .

Beziehen Sie alle Teammitglieder in die Sprintplanung ein

Der Grundgedanke von Agile/Scrum ist, dass es eine direkte Kommunikation zwischen dem Product Owner und dem Team geben sollte, das die Arbeit erledigt. Außerdem sollten die Mitglieder, die die Arbeit erledigen werden, eine Teamverpflichtung eingehen, um das zu erledigen, wofür sie sich angemeldet haben. Sie sollten also versuchen, Ihre Teilzeitkraft in Ihre Sprint-Planungssitzungen einzubeziehen.

Sie haben jedoch nicht gesagt, was Ihre Rolle ist. Sieht so aus, als wären Sie der ScrumMaster. Als ScrumMaster habe ich mich während des Sprints mit Teilzeitressourcen abgestimmt.

Es gibt keine feste Regel, dass die Sprintplanung für einen zweiwöchigen Sprint einen Tag dauern sollte. Wenn Sie in der Lage sind, eine effektive Planung durchzuführen, ohne wesentliche Aktivitäten zu unterbrechen, ist es in Ordnung, sie zu verkürzen.

Ich empfehle, einen Blick auf den Scrum Guide zu werfen, der über Scrum.org (Ken Schwabers Firma) verfügbar ist – er legt die Dinge ziemlich genau dar und wird von den Kodierern des Frameworks (Jeff Sutherland und Schwaber) geschrieben/gepflegt.

Alle Mitglieder des Scrum-Teams sollten anwesend sein:

• Scrum Master (Facilitator, der sicherstellt, dass der Scrum-Prozess eingehalten wird),
• Product Owner (Kurator des Product Backlogs) und
• Alle Teammitglieder (dazu gehört auch die Teilzeitkraft).

Nur die Personen, die die Arbeit tatsächlich ausführen, sollten in ihrem Namen handeln.

Das Sprint-Planungsmeeting ist ein einmaliges Meeting – nicht länger als 8 Stunden für einen 30-Tage-Sprint – proportional kürzer, basierend auf der Länge des Sprints (so würde ein 15-Tage-Sprint ein Sprint-Planungsmeeting von nicht länger als 4 Stunden haben ).

Es ist nicht empfehlenswert, das Meeting auf mehrere Tage zu verteilen – auch nur um die Teilzeitperson einzubeziehen. Ein paar Optionen wären:

1. Finden Sie einen Tag/eine Uhrzeit, an dem/der er/sie dort sein wird, und passen Sie Ihre Sprintlängen an ihn/sie an; oder,
2. Prüfen Sie, ob das Team (einschließlich der Teilzeitkraft) damit einverstanden ist, dass andere Mitglieder seine/ihre Stellvertreter sind.

Wenn Ihr Team jedoch nicht feststellen kann, was innerhalb eines Sprints in einem einzigen Planungsmeeting getan werden kann, ist etwas im Gange, das untersucht werden sollte. Beispielsweise kann die Sprint-Dauer zu lang/kurz sein, die Product-Backlog-Elemente sind möglicherweise nicht gut genug definiert, um richtig geschätzt zu werden, und so weiter. Bei einem zweiwöchigen Sprint sehen Sie ungefähr ein 4-stündiges Planungsmeeting – maximal (die meisten Zeitfenster in Scrum sind „nicht zu überschreitende“ Dauern und proportional zur Länge des Sprints – mit Ausnahme des täglichen Scrum-Meetings von 15 Minuten oder weniger).

Ich hoffe, das hilft. Lassen Sie mich wissen, wenn Sie eine Klarstellung wünschen.