Scrum -Rituale: Sprintplanung

Scrum Sprint Planung: Ein tiefes Tauchgang

Sprintplanung, der Eckpfeiler jedes Sprint, bereitet die Bühne für die bevorstehende Iteration. Diese kollaborative Anstrengung zwischen dem Produktbesitzer, dem Scrum Master und dem Entwicklungsteam definiert die Ziele des Sprints und die für die Erreichung erforderliche Arbeit.

Das Kernziel: , um eine klare Agenda für den Sprint zu etablieren. Der Produktbesitzer präsentiert priorisierte Benutzergeschichten und richtet sie mit der Produktvision aus. Das Team schätzt dann die Bemühungen und verpflichtet sich, eine realistische Anzahl von Geschichten basierend auf ihrer früheren Leistung (Geschwindigkeit) zu vervollständigen. Das Ergebnis? Ein gegenseitig vereinbarter Sprint-Rückstand.

(Dieser Abschnitt ist ein Auszug von "Scrum: Novice to Ninja" von M. David Green. Erhältlich in Buchhandlungen und als E -Book.)

Der Scrum Master erleichtert, aber der Produktbesitzer treibt den Inhalt der Sprintplanung vor.

Zeitzuweisung: Die Dauer ist je nach Sprintlänge flexibel (z. B. 3-4 Stunden für einen zweiwöchigen Sprint, möglicherweise einen ganzen Tag für längere Sprints). Eine gründliche Planung ist der Schlüssel zu einer effektiven Kommunikation und einem gemeinsamen Verständnis der Leistungen. Ein erfahrener Scrum -Master stellt sicher, dass der Prozess konzentriert bleibt und innerhalb der zugewiesenen Zeit.

Vorbereitung: Der Produktbesitzer bereitet einen raffinierten Produkt-Rückstand vor, der mit den Stakeholdern zusammenarbeitet, um sicherzustellen, dass Geschichten klar, gut definiert und priorisiert werden. Jede Geschichte enthält Akzeptanzkriterien für eindeutige Fertigstellung.

Einführung von Geschichten: Der Produktbesitzer präsentiert die vorbereiteten Geschichten, fördert die offene Diskussion und ermöglicht es dem Team, Machbarkeit und Vollständigkeit in Frage zu stellen. Diese kollaborative Überprüfung sorgt für die Ausrichtung und ist potenzielle Herausforderungen proaktiv vorgesehen.

Technische Überlegungen: Das Team beteiligt sich aktiv, wobei Bedenken hinsichtlich technischer Schulden, Refactoring -Bedürfnisse oder Infrastruktur -Upgrades aufmerksam gemacht werden. Während der Produktbesitzer Prioritäten festlegt, behält das Team die Befugnis, schlecht definierte oder technisch nicht realisierbare Geschichten abzulehnen.

Story-Schätzung: Das Team schätzt die relative Anstrengung für jede Geschichte mit einer ausgewählten Methode (z. B. Punkte, T-Shirt-Größen). Dies ist relativ, keine Zeitschätzung, die sich auf vergleichende Anstrengungen auf der Grundlage früherer Erfahrungen konzentriert. Die Konsistenz im ausgewählten Schätzsystem ist für die Verfolgung der Geschwindigkeit von entscheidender Bedeutung.

Teamkonsens: Die Vereinbarung zu Geschichtenschätzungen ist wesentlich, was Transparenz und gemeinsames Verständnis fördert. Jedes Teammitglied sollte die Bemühungen verstehen, auch wenn nicht direkt an der Geschichte arbeiten.

Behandlungsfehler: Fehler (verpasste Anforderungen in abgeschlossenen oder akzeptierten Geschichten) werden angesprochen, erhalten jedoch keine Punkte. Ihre Auflösung wirkt sich auf Geschwindigkeit aus, ist jedoch nicht in Punktschätzungen berücksichtigt. Es wird keine separate Kapazität für die Behebung von Fehler zugewiesen.

Aufgaben vs. Geschichten: Aufgaben (Code -Wartung, Infrastrukturverbesserungen) sind entscheidend, erhalten jedoch keine Punkte, da sie keinen Benutzerwert liefern. Die Verhandlung mit dem Produktbesitzer stellt sicher, dass diese wichtigen Aufgaben priorisiert werden.

Spikes: unsichere technische Herausforderungen erfordern möglicherweise Spikes (Forschungsaufgaben). Diese haben Akzeptanzkriterien und zeitliche Einschränkungen definiert, um den Ressourcenabfluss zu verhindern.

Verpflichtung zum Sprint -Rückstand: Das Team arbeitet zusammen, um einen Sprint -Rückstand zu erstellen, der auf seinen Geschwindigkeits- und Geschichtenschätzungen basiert. Während der Produktbesitzer die endgültige Behörde für Inhalte und Reihenfolge hat, kann sich das Team für Anpassungen zur Optimierung des Workflows und zur Aufrechterhaltung der Kontinuität einsetzen. Die endgültige Vereinbarung ist entscheidend, bevor Sie den Sprint beginnen.

Das Endergebnis: Ein gemeinsamer Sprint -Rückstand, ein klares Sprintziel und ein kollektives Engagement, die priorisierten Geschichten innerhalb des Sprint -Zeitrahmens zu liefern. Jeder versteht seine Verantwortung und den Weg nach vorne.

häufig gestellte Fragen (FAQs):

• Ziel der Sprintplanung: Erstellungen und den Arbeitsplan für den Sprint definieren.
• Besprechungsdauer: variiert basierend auf der Sprintlänge (z. B. 4 Stunden für einen 2-wöchigen Sprint).
• Rolle des Scrum Master: Erleichterung, um sicherzustellen, dass die Prinzipien der Scrum festgehalten werden.
• Sprint Zielbestimmung: Kollaborative Entscheidung basierend auf ausgewählten Backlog -Elementen und Teamkapazität.
• unvollständige Aufgaben: zurück zum Produktrücken zurückgegeben; Retrospektiven adressieren Wurzelursachen.
• Teamkapazität: bestimmt nach Teamgröße, Verfügbarkeit und historischer Leistung.
• Sprint Zieländerungen: sollte sich während des Sprint nicht ändern; Stornierung ist eine Option, wenn sich die Umstände drastisch ändern.
• Die Rolle des Produktbesitzers: klärt den Rückstandselemente, Akzeptanzkriterien und arbeitet an der Aufgabenauswahl zusammen.
• Besprechungsergebnis: Sprintziel, ausgewählte Backlog -Artikel und ein Lieferplan (Sprint -Rückstand).
• Besprechungsfrequenz: zu Beginn jedes Sprint.

Diese detaillierte Erklärung liefert ein umfassendes Verständnis der Scrum Sprint -Planung, die Zusammenarbeit, Transparenz und Engagement betont.

Das obige ist der detaillierte Inhalt vonScrum -Rituale: Sprintplanung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!