Bedenken Sie, dass wir 10 Product Backlog Items (PBIs) haben, die geschätzt wurden und es, wenn alles gut geht, nach der Sprintplanung in unseren nächsten Sprint schaffen werden. An welchem Punkt wäre es angemessen, das Team über ALLE 10 PBIs nachdenken zu lassen, um das Endziel dieser 10 PBI-Bemühungen zu verstehen (vorausgesetzt, alle PBIs sind mit einem gemeinsamen Thema/Epos verbunden)? Es versteht sich zwar, dass jede PBI für sich genommen einen Mehrwert liefert, aber für das Team ist es oft hilfreich zu wissen, was als nächstes kommt, da es helfen kann, technische Entscheidungen zu treffen.
Meetings, die ich für diese Arbeit in Betracht gezogen habe:
Grooming - Scheint nicht der richtige Zeitpunkt zu sein, da es hier zu sehr um das "WIE" gehen würde, wenn wir über das "WAS" diskutieren sollten. Planung - Zu spät, da die PBIs bereits definiert wurden. Ich bin immer davon ausgegangen, dass zu diesem Zeitpunkt jeder bereit sein würde, sich anzumelden und die PBIs zu beauftragen.
Wann ist der richtige Zeitpunkt dafür? Oder ist das ein PBI-Qualitätsproblem?
Wäre dies in der Tasking-Phase des Sprint Plannings? Ich denke, das ist zu spät im Prozess, da es möglich ist, dass die während dieser Bemühungen gesammelten Informationen zur Umstrukturierung von PBIs beitragen würden.
Der richtige Zeitpunkt (oder Prozess) dafür ist Backlog Grooming. Sein Ziel ist es, PBI in den Zustand "Bereit" zu versetzen. Und es ist kein eigenständiges Meeting, wie man im Scrum Guide ( http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog ) sehen kann
Product Backlog Refinement ist der Akt des Hinzufügens von Details, Schätzungen und Reihenfolgen zu Elementen im Product Backlog.
Es ist auch in Jeff Sutherlands Video https://www.youtube.com/watch?v=XkhJDbaW0j0 klar beschrieben :
Fertig fertig [...] ist nicht nur eine gute Liste. Es hat bestimmte Eigenschaften.
Das erste wirklich wichtige Merkmal ist, dass es vom Team sofort umsetzbar sein muss . Sie müssen wissen, was zu tun ist, und sie müssen in der Lage sein, jetzt etwas zu tun.
Wenn Sie keine Untersuchung durchgeführt haben und keine Ahnung haben, wie Sie es tun werden, haben Sie ein Problem.
Die zweite Sache ist, dass das Produkt-Backlog in Scrum [...] als Verhandlung konzipiert ist [...] etwas sein muss, das zwischen PO und dem Team besprochen werden muss, vor der Sprint-Planung .
Sie haben recht damit, dass Sie dafür zu spät planen.
Das nächste [...] ist, schätzbar zu sein. Das Team muss in der Lage sein, ihn klar einzuschätzen und richtig einzuschätzen .
Wenn Sie keine technische Untersuchung durchführen, können Sie in den meisten Fällen keine eindeutige Schätzung vornehmen. Eine Anleitung durch erfahrene Techniker ist in einer solchen Situation von unschätzbarem Wert.
Zusammenfassend lässt sich sagen, dass Sie im Rahmen der Rückstandspflege eine angemessene Untersuchung durchführen müssen, um Unsicherheiten zu beseitigen und Ihre PBI in den Status „Bereit“ zu versetzen.
@Alex Leonov hat eine gute Antwort gegeben, die die Grundlagen behandelt, wie man Geschichten "bereit" macht. Ich habe jedoch eine andere Meinung zu Ihrer konkreten Frage:
An welchem Punkt wäre es angemessen, das Team über ALLE 10 PBIs nachdenken zu lassen, um das Endziel dieser 10 PBI-Bemühungen zu verstehen (vorausgesetzt, alle PBIs sind mit einem gemeinsamen Thema/Epos verbunden)?
Zum Zeitpunkt der Sprint-Planung und während des Sprints, wenn sie in diesen Sprint eingeplant wurden. Aus dem Scrum-Leitfaden :
„Das Entwicklungsteam ändert das Sprint-Backlog während des Sprints, und das Sprint-Backlog entsteht während des Sprints. Diese Entstehung erfolgt, wenn das Entwicklungsteam den Plan durcharbeitet und mehr über die Arbeit erfährt, die zum Erreichen des Sprint-Ziels erforderlich ist.“
Wenn, wie Sie sagen, "während dieser Bemühungen gesammelte Informationen helfen würden, PBIs neu zu strukturieren", dann machen Sie weiter und strukturieren Sie sie während des Sprints neu.
Vor dem Sprint Planning sind diese PBIs nur eigenständige Geschichten. Wenn Sie davon ausgehen, dass diese 10 PBIs zusammenhalten, ist das vergebliche Mühe. Dem Product Owner steht es frei, einige nach oben, andere nach unten zu verschieben und einige ganz zu entfernen. Außerdem aus dem Scrum Guide:
"Der Product Owner ist verantwortlich für das Product Backlog, einschließlich seines Inhalts, seiner Verfügbarkeit und seiner Anordnung."
Wir hatten ähnliche Bedenken mit dem Team und hatten während des zweiwöchigen Sprints zwei Backlog-Grooming-Sitzungen . Unser Zeitplan war folgender:
Das hat ziemlich gut funktioniert.
An welchem Punkt wäre es angemessen, das Team über ALLE 10 PBIs nachdenken zu lassen, um das Endziel dieser 10 PBI-Bemühungen zu verstehen[?]
Niemals. Sie missverstehen die Beziehung zwischen dem Sprint-Ziel und dem Product Backlog.
Teil des Sprint Plannings ist die Definition eines übergeordneten Sprint Goals. Im Allgemeinen sollten alle für den aktuellen Sprint ausgewählten Geschichten auf dieses vereinheitlichende Ziel hinarbeiten. Auf diese Weise kann ein Sprint erfolgreich sein, selbst wenn nicht 100 % der ausgewählten Storys fertig sind, solange das definierte Sprint-Ziel erreicht wird, oder Storys können aus dem aktuellen Sprint gekürzt werden, solange das vereinbarte Sprint-Ziel nicht gefährdet wird . Dies ist Teil dessen, was Scrum zu einem so flexiblen und leistungsstarken Framework macht.
Darüber hinaus ist das Product Backlog eine Reihe von Elementen, denen vom Product Owner ein Ordinalwert und vom Entwicklungsteam ein relatives Maß an Aufwand (z. B. Story Points) zugewiesen wurde. Das Entwicklungsteam holt Artikel nacheinander aus dem Product Backlog, vorausgesetzt, dass innerhalb des Sprints genügend Kapazität vorhanden ist, um diese Story innerhalb der Iteration abzuschließen . Das Team nimmt Stories niemals in den Sprint auf, nur weil sie mit anderen Stories zusammenhängen; Alle diese Entscheidungen müssen auf Folgendem beruhen:
Das Scrum-Team muss in jedem einzelnen Sprint auf ein einheitliches Sprint-Ziel hinarbeiten. Zu keinem Zeitpunkt betrachtet das Team Storys im Product Backlog auf diese Weise. Während der Sprint-Planung muss das Entwicklungsteam jedoch bei der Planung und Organisation des Sprint-Backlogs immer das Sprint-Ziel im Auge behalten, und das Entwicklungsteam sollte bei der Planung des aktuellen Sprints alle akzeptierten Sprint-Backlog-Elemente zusammen berücksichtigen.