Derzeit haben wir das „Sprint Planning Meeting“ in zwei Teile aufgeteilt:
SPM1 - Dies machen wir am ersten Tag des Sprints. Der Product Owner bespricht die Stories, die aus dem Backlog in den aktuellen Sprint gekommen sind. Alle Geschichten sind bereits im Backlog besprochen, daher haben wir hier nicht viel. Meistens diskutieren wir, ob etwas im Rückstand war oder nicht geklärt war. Nach diesem Meeting stellt PO sicher, dass das Team 100 % Klarheit über die Geschichten hat.
SPM2 - Dies ist eine rein technische Diskussion. Wir schließen PO hier nicht ein. Wir unterteilen Geschichten in die testbare Aufgabe, damit das Teammitglied einen umfassenden Überblick darüber erhält, was ausgeführt werden muss, was von jeder Aufgabe erwartet wird, und erleichtern die parallele Entwicklung.
Die Probleme, mit denen wir konfrontiert sind:
Etwas zusätzlicher Kontext:
Machen wir hier etwas falsch? Sollten wir das „Sprint Planning Meeting“ so in zwei Teile aufteilen, ist das Standard-Scrum-Praxis? Wie sollen wir diese Probleme lösen?
Sie haben mehrere Prozessprobleme. Prozessprobleme haben ihren Preis. Diese Kosten sollten sichtbar sein, und die Kosten für die Behebung der Probleme sollten dem Projekt angerechnet werden, um Transparenz zu gewährleisten.
Sie können Ihre aktuellen Prozessprobleme wie folgt angehen:
Der Rest dieser wirklich langen Antwort erklärt, warum und wie Sie diese Dinge tun sollten.
Sie haben verschiedene Probleme. Wie ich es sehe, ergeben sich Ihre sekundären Probleme aus diesen Aussagen, die Sie in Ihrem ursprünglichen Beitrag gemacht haben.
Das Team ist von der genauen Tagesordnung des Treffens nicht überzeugt[.]
Dies liegt daran, dass Backlog Refinement und Sprint Planning nicht richtig genutzt werden.
Wir haben Probleme damit, Aufgaben aus Geschichten zu erstellen.
Dies liegt wahrscheinlich daran, dass die Storys nicht den INVEST -Kriterien entsprechen, die Größe oder Schätzung falsch sind oder dass Ihr Team und Ihre Sprints nicht kohärent sind.
Die restlichen vorgeschlagenen Abhängigkeiten können per E-Mail usw. besprochen werden.
Dies ist ein riesiger Projektgeruch. Es ignoriert das agile Prinzip , dass „die effizienteste und effektivste Methode zur Übermittlung von Informationen an und innerhalb eines Entwicklungsteams das persönliche Gespräch ist“. Es zeigt auch, dass es dem Team an Zusammenhalt mangelt und dass es keinen Wert in der derzeit strukturierten Planungssitzung findet.
Die obigen Probleme sind jedoch eigentlich X/Y-Probleme. Sie sind Symptome eines größeren Prozessproblems. Basierend auf den bereitgestellten Informationen sehe ich mehrere Hauptprobleme.
Kurz gesagt, wenn Sie alle Probleme auspacken, läuft es im Grunde darauf hinaus, dass Sie den Scrum-Prozess nicht vollständig nutzen und nicht in der Lage sind, ein zusammenhängendes Team zu bilden, anstatt eine Ansammlung von Personen, die demselben Projekt zugewiesen sind. Schauen wir uns einige mögliche Lösungen an.
Die folgenden Lösungen befassen sich mit Ihren zugrunde liegenden Prozess- und Teamproblemen und sollten daher auch die spezifischen Folgeprobleme ansprechen, die Sie in Ihrem ursprünglichen Beitrag angesprochen haben. Die Situationen variieren jedoch, passen Sie sie also nach Bedarf an.
Ihr gesamtes Team sollte am Backlog Refinement beteiligt sein. Während reifere Teams manchmal damit durchkommen, dass nur der Scrum Master und der Product Owner an dem Meeting teilnehmen, könnte der Mangel an Zusammenhalt in Ihren Sprint-Planungssitzungen behoben werden, indem Sie sicherstellen, dass jeder das Backlog Grooming mit einem klaren Ziel vor Augen und einer festgelegten Agenda verlässt .
Backlog Refinement ist die Zeit, in der sich das Team mit dem Product Owner zusammensetzt, um zu bestimmen, welche Funktionen voraussichtlich im Umfang des bevorstehenden Sprints enthalten sein werden, und um dem Product Owner zu helfen:
Wenn das Team das Backlog-Refinement-Meeting mit einem Sprint-Ziel und einem Pool potenzieller User Stories für den nächsten Sprint verlässt, haben Sie eine Agenda!
Reservieren Sie weniger Zeit für Ihre Sprint-Planungssitzungen. Als Faustregel habe ich herausgefunden, dass die meisten Teams ungefähr 4 Stunden Sprintlänge pro Woche für die Planung benötigen. Natürlich variiert dies je nach Projektkomplexität und Teamreife, aber wenn Sie mehr als 6-8 Stunden mit der Planung eines zweiwöchigen Sprints verbringen, haben Sie möglicherweise andere Prozess-, Rahmen- oder Fähigkeitsdefizite im Spiel.
Ganz am Anfang des Sprint Plannings muss das Team seine Kapazität für den aktuellen Sprint einschätzen. Oft ist dies die Velocity, angepasst an aktuelle Gegebenheiten (z. B. Urlaub, Änderungen in der Teamzusammensetzung oder Komplexität der aktuellen Projektphase). Diese Kapazitätsschätzung wird verwendet, um die Arbeit zu begrenzen, die für den Sprint geplant wird, und um die Prognose zu gestalten , die durch die Sprint-Planung erstellt wird.
In der ersten Hälfte der Sprint-Planung muss das gesamte Team das Sprint-Ziel überprüfen und mit dem Product Owner zusammenarbeiten, um Stories von der Spitze des Product Backlogs auszuwählen, die in einen einzelnen Sprint passen. Dies kann einige Diskussionen, Schätzungen, Kuhhandel und spontane Neupriorisierung (durch den PO) des Product Backlog beinhalten. Unabhängig davon , ob das Team eine Story oder viele zieht, ist das Team dafür verantwortlich, Storys von der Spitze des Product Backlogs zu entfernen, basierend auf der geschätzten Kapazität des Teams für den Sprint.
Auch die zweite Hälfte des Sprint Plannings erfordert das gesamte Team, einschließlich des Product Owners. Dies ist der Teil, in dem das Team das Sprint Backlog entwickelt, d. h. die Aufgaben und Abhängigkeiten, die erforderlich sind, um jede Story zur Definition of Done zu bringen. Während sehr reife Teams die beiden Schritte oft kombinieren können, benötigen die meisten Teams diesen Schritt, um explizit zu sein.
Das Ziel hier ist nicht, einen traditionellen Projektstrukturplan zu erstellen. Stattdessen geht es darum, die Aufgaben zu definieren, die zur Umsetzung der Story erforderlich sind, oder Informationslücken über den Umfang oder die Definition of Done für eine bestimmte Story zu identifizieren. Mit anderen Worten, Sie brauchen einen groben Überblick darüber, was getan werden muss, damit die Akzeptanzkriterien für die Geschichte verstanden werden, bevor Sie mit der Arbeit beginnen.
Stellen Sie sich zum Beispiel vor, Sie hätten eine Geschichte wie:
Als Benutzer
möchte ich meinen Benutzernamen im System ändern können,
damit ich den technischen Support nicht anrufen muss, um einfache Tippfehler zu beheben, die während der Kontoerstellung gemacht wurden.
Eine gute Geschichte hat einen Wertkonsumenten (den Benutzer), eine Funktion (Änderung des Benutzernamens) und einen Kontext, um den Umfang der Implementierung einzuschränken. Eine großartige Geschichte ist oft so granular, dass die Aufgaben der Geschichte selbstverständlich sind. Wenn dies nicht der Fall ist, müssen Sie möglicherweise die INVEST -Kriterien für die Entwicklung einer Geschichte erneut überprüfen.
Während der Sprint-Backlog-Definition muss das Team gemeinsam Folgendes herausfinden:
Das ist es! Wenn das Meeting beginnt, in detaillierte Diskussionen darüber abzugleiten, wie ein Entwickler plant, ein Widget einzubetten, hat das Team wahrscheinlich den Punkt verfehlt und der Scrum Master muss den Prozess besser begutachten.
Wenn es Ihrem Team an Zusammenhalt, Reife oder Erfahrung mit effektivem Scrum mangelt, sollten Probleme identifiziert und während der Sprint-Retrospektive besprochen werden. Der Product Owner muss dann User Stories im Product Backlog erstellen, damit das Team Kapazitäten für die Lösung der Prozessprobleme zuweisen kann.
Wenn das Team beispielsweise Schwierigkeiten hat, Geschichten zu schreiben, die den INVEST - Kriterien entsprechen, sollten die Probleme oder Wissenslücken in der Retrospektive genannt werden. Der Product Owner könnte dann eine User Story erstellen wie:
Als Mitglied eines Scrum-Teams
möchte ich lernen, wie man Product Backlog Items (PBIs) definiert, die unabhängiger
sind, damit es während der Sprint-Planung weniger Abhängigkeiten zwischen PBIs gibt.
Die Story sollte dann geschätzt, priorisiert und einem zukünftigen Sprint als Arbeit zugewiesen werden . Prozessprobleme können nicht als versteckte Arbeit oder Overhead behandelt werden; Sie müssen explizit gemacht werden, und alle damit verbundenen Aufgaben müssen explizit auf die Kapazität des Teams angerechnet werden, entweder als geschätzte Arbeit oder als nicht angegangene Technologie-/Prozessschuld, die die verfügbare Kapazität verringert .
Mit anderen Worten, Prozessprobleme haben ihren Preis. Diese Kosten sollten sichtbar sein, und die Kosten für die Behebung der Probleme sollten dem Projekt angerechnet werden, um Transparenz zu gewährleisten.
Es scheint mir, dass Problem 2 eines neuen Projekts oder Teams ist.
Mit einem vorhandenen Teil der Software oder einem alten, eingebetteten Team kennt jeder die Gesamtarchitektur des Projekts. Fragen wie „Wo sollen wir diese Geschäftslogik platzieren“ oder „Welche Technologie sollen wir verwenden, um dieses Problem zu lösen“ wurden vor langer Zeit beantwortet, und es bedarf keiner Diskussion.
Bei einem neuen Team oder Projekt ist es am besten, die Grundstruktur zu klären, bevor Sie beginnen. dh. „Wir erstellen eine c# mvc 4-Website, die in AWS gehostet wird und eine mssql-Datenbank verwendet. dieses und jenes JS-Framework usw.
Bringen Sie alle architektonisch auf dieselbe Seite, damit Sie einen Rahmen haben, um technische Fragen zu diskutieren, wenn sie auftauchen.
Das SPM in zwei Teile aufzuteilen, ist der klassische Ansatz. Erster Teil, Vereinbarung über Sprint-Backlog und Sprint-Ziel (beinhaltet PO/Team). Im zweiten Teil bespricht das Entwicklungsteam, wie die Anforderungen im Sprint-Backlog umgesetzt werden können.
SPM1 Problem - Es gibt weniger Dinge zu besprechen. Das Team ist von der genauen Tagesordnung des Treffens nicht überzeugt, sie sagen, warum besprechen wir das Ganze nicht nur im Backlog. (Wir haben zwei Rückstände in einem Sprint). Die restlichen vorgeschlagenen Abhängigkeiten können per E-Mail usw. besprochen werden.
Sorry, aber ich verstehe deine Probleme nicht ganz. Wie ich bereits geschrieben habe, dient dieser Teil dazu, ein gemeinsames Verständnis und eine Einigung über den Sprint-Backlog und das Ziel zu erzielen. Vielleicht liegt das Problem darin, dass die Anforderungen, die im Sprint erledigt werden sollen, überhaupt nicht zur Diskussion stehen?
SPM2-Problem – Wir haben Probleme damit, Aufgaben aus Geschichten zu erstellen. Wir haben keine klare Vorstellung, bis zu welcher Tiefe die Dinge diskutiert werden sollten. Sollte die Diskussion beinhalten, welche Codeebene, dh BL, DAL, UI, welcher Code eingefügt würde ODER wie verschiedene Systeme miteinander verbunden würden, dh die Funktionalität unterbrechen und dem Entwickler den Rest überlassen würden?
Der wichtige Gedanke im zweiten Teil besteht darin, die Anforderungen an einzelne Aufgaben zu verfeinern, eine Einigung darüber zu erzielen, wer für eine Aufgabe verantwortlich ist, und festzulegen, wann eine Aufgabe erledigt ist.
Ob in diesem Meeting gestalterische/technische Entscheidungen zur Diskussion stehen oder nicht, hängt vom Team und der Komplexität der Anforderungen ab. Es ist auch möglich, solche Entscheidungen in einzelne Aufgaben zu packen.
Ich denke, das größte Problem, das Sie haben, ist, dass Sie keine gemeinsame und regelmäßige Struktur gefunden haben, die jeder respektiert und befolgt. Sprechen Sie mit Ihren Teamkollegen und versuchen Sie, sich auf ein Verfahren zu einigen, das deutlich macht, welche Entscheidungen in SPM2 getroffen werden und welche außerhalb des Geltungsbereichs liegen.
MrHinsh - Martin Hinshelwood
Einzelgänger
Todd A. Jacobs