Dimensionierung eines gesamten Backlogs mithilfe von Story Points

Ich bin PM in einem großen mehrjährigen Projekt mit einem beträchtlichen Arbeitsrückstand bei der Implementierung von Scrum in 4-wöchigen Release-Zyklen. Ich halte wöchentliche Backlog-Grooming-Sitzungen mit dem Projektteam und wichtigen Geschäftsinhabern ab, um die User Stories im Backlog zu überprüfen, größere User Stories (Epics) in kleinere aufzuteilen, die das Projektteam im Sprint zu implementieren beginnen kann, und diese kleineren User Stories zu dimensionieren Storypoints verwenden.

Die Verwendung von Story Points, die mit einer User Story verknüpft sind, ist ein ziemlich neues Konzept für das Team und wurde erst in den letzten 6 Monaten des Projekts (das vor 1,5 Jahren begann) implementiert. Der gesamte Rückstand ist also nicht in Story Points bemessen.

Mein Ziel war es zunächst, dem Team Story Points vorzustellen und ein regelmäßiges Treffen für das Team einzurichten, um die User Stories im Backlog zu dimensionieren, damit sie sich daran gewöhnen und dadurch effizienter (schneller lesen) bei der Dimensionierung werden. Allerdings hat das Team in Bezug auf die Geschwindigkeit, mit der User Stories sortiert werden, ein Plateau erreicht, und ich schätze, dass es bei der aktuellen Geschwindigkeit bis zu einem weiteren Jahr dauern würde, um den gesamten Rückstand zu sortieren.

Ist dies ein guter Ansatz, um mit dem Projektteam einen gesamten Rückstand (der sehr groß ist) zu bemessen? Wie kann ich damit vorankommen, um den Prozess zu beschleunigen? Wenn keine gute Idee, was ist der bessere Ansatz für diesen Prozess?

Antworten (4)

Normalerweise ist es keine gute Idee, den gesamten Rückstand häufig mit dem gesamten Team zu überprüfen. Die letzten 2/3 des Backlogs werden sich in Zukunft ändern und die Überprüfung dieser Punkte verschwendet nur die Zeit des Teams und führt zu unnötigen Diskussionen über zukünftige Probleme, die möglicherweise überhaupt nicht implementiert werden.

Die empfohlene Vorgehensweise ist, dass der Product Owner den gesamten Backlog prüft und in Form hält und so viele User Stories vorbereitet, wie das Team in 2-3 Sprints bewältigen kann. Der Rest bleibt in einer Art unbekanntem oder Entwurfszustand.

Der Product Owner kann ein regelmäßiges Meeting einberufen, bei dem der gesamte Backlog besprochen wird und das Team eine grobe Schätzung des gesamten Backlogs abgibt. Wenn der Sprint 2 Wochen dauert, muss dieses Meeting alle zwei Monate einberufen werden. Dieses Treffen gibt einen Gesamtüberblick über den gesamten Fortschritt und bietet. Die Durchführung dieses Meetings unterscheidet sich ein wenig von einem Sprint-Planungsmeeting, da es aufgrund der Anzahl der User Stories länger dauert und es keine Aufschlüsselung der Aufgaben gibt. Wenn Hindernisse oder Probleme auftreten, muss der Product Owner diese beseitigen. Dieses Meeting wird oft als Release Planning Meeting bezeichnet (auf der Scrum Alliance-Website finden Sie möglicherweise einige gute Artikel darüber).

Angenommen, 2/3 des Rückstands sind nicht bemessen, wie verwenden Sie Story Points, um den Abschluss des gesamten Projekts zu prognostizieren? (FYI ... im Wesentlichen verwenden wir SP so, wie Sie es erwähnt haben, um die nächsten 2 Arbeitssprints zu prognostizieren, aber ich habe mich gefragt, wie dies zu einer vollständigen Projektprognose führen würde.)
Sie sollten die Story Points nicht für Prognosen verwenden, da sie nichts mit Zeit zu tun haben. Auf dem Papier tun sie das natürlich, aber im wirklichen Leben sind sie der Komplexität näher.
Ich bin daran interessiert, mehr über Ihre Perspektive hier zu hören. Mein Ziel war es zunächst, die durchschnittliche Geschwindigkeit (in SP) pro Sprint des Teams zu ermitteln und diese dann als Prognosemetrik gegen den Rest des Rückstands zu verwenden (vorausgesetzt, dass dieser ebenfalls in SP gemessen wird). Schlagen Sie einen anderen Ansatz vor?

Stories, an denen im anstehenden Sprint gearbeitet werden soll, sollten viel strenger eingeschätzt werden als Stories, die für viele Monate geplant sind. Manche Leute nennen das „Rolling Wave“-Planung.

So habe ich den gesamten Rückstand in der Vergangenheit geschätzt:

  1. Der Product Owner identifiziert Storys und priorisiert sie.
  2. Bevor ein Projekt beginnt, verbringen der PO und 1 oder 2 Techniker 10 Sekunden pro Geschichte mit der Schätzung. Buchstäblich nur eine kurze Vermutung aus der Überschrift der Geschichte. Nicht sehr genau, aber genau genug, wenn man bedenkt, dass die meisten Geschichten vor der Entwicklung auf irgendeine Weise geändert werden und viele nicht einmal eingeplant werden.
  3. Zu Beginn des Projekts schätzt das gesamte Team die Kandidatengeschichten für den ersten Sprint und möglicherweise für die folgenden (falls Zeit vorhanden ist).
  4. Nehmen Sie sich während eines Sprints etwas Zeit, damit das gesamte Team die nächste Reihe von Kandidatengeschichten für den folgenden Sprint genauer einschätzen kann. (Diese Besprechung ist auf 1 Stunde begrenzt).
  5. Schätzen Sie Storys bei Bedarf während der Sprintplanung neu ein.

Denken Sie daran, dass Scrum eher adaptiv als vorausschauend ist – Sie sollten keine hochgenauen Schätzungen für Arbeiten erwarten, die mehr als ein oder zwei Sprints in der Zukunft liegen. Die Art der Genauigkeit, die Sie durch den obigen Ansatz erhalten, ermöglicht es Ihnen immer noch, Product Backlog Burndown (oder Burnup)-Diagramme zu zeichnen, um eine Vorstellung vom Veröffentlichungsdatum zu geben.

Ein paar Fragen: 1. Oft ist die SP-Größe ein Input für die Priorisierung, wie priorisiert die PO, wenn der Rückstand keine Größe hat? 2. Wie wird der Release-Burn-up auf diese Weise durchgeführt, wenn sich der SP auf User Stories im Laufe der Zeit ändert? Vielleicht verstehe ich Sie falsch, aber ich bin davon ausgegangen, dass sich SP, die mit einer User Story verbunden sind, nicht ändern sollten, es sei denn, es gibt signifikante Informationen, die das grundlegende Verständnis dessen, was die Story aus Sicht der Funktionalität darstellt, ändern (dh - in diesem Fall ist es wirklich eine andere Geschichte).
Hallo, 1. Die Bestellung priorisiert zunächst nach Kundenwert, kann aber neu priorisiert werden, wenn eine Aufwandsschätzung vorhanden ist. 2. Der Freigabeabbrand wird regelmäßig aktualisiert. Wenn sich der SP ändert, ändert sich auch das Diagramm.

Ich bin der festen Überzeugung, dass die Schätzung von Story Points auf Aufgaben beschränkt sein sollte, die Sie in den nächsten zwei bis drei Sprints umsetzen möchten. Wenn Sie mehr versuchen, verschwenden Sie nur die Zeit Ihres Teams. Je weiter in die Zukunft Sie zu prognostizieren versuchen, desto mehr Ungewissheit wird es geben. Das ist einfach so, egal ob mit Scrum oder einer anderen Methodik.

Also was mache ich? Standardmäßig werden neue User Storys auf den durchschnittlichen Aufwandspunktwert abgeschlossener User Storys gesetzt. Sie wären tatsächlich ziemlich erstaunt, wie genau die mit diesem Wert getroffenen Vorhersagen sind, besonders wenn Sie gut darin sind, Ihre Epics in die richtigen Stücke zu zerlegen. Stellen Sie nur sicher, dass Sie nicht in die Gewohnheit verfallen, diesen Wert zu verlassen. Schätzen Sie die Aufwandspunkte mit dem Team während der Sprintplanung (oder wann immer Sie es normalerweise tun), aber konzentrieren Sie ihre Bemühungen auf die Spitze des Rückstands.

Ich sehe den Wert darin, den durchschnittlichen Aufwandspunktwert abgeschlossener Geschichten für neue zu nehmen. Daran habe ich noch nie gedacht, danke! Wie gehen Sie mit einem großen Rückstand an Elementen zu Beginn des Projekts um (oder in meinem Fall mit einem Projekt, das einen großen vorhandenen Rückstand hat, aber keine User Storys mit Story Points dimensioniert hat). Dies sind keine neuen User Stories, und da sie zu Beginn des Projekts formuliert wurden, kann die Annahme, dass User Stories in ungefähr ähnliche Größen unterteilt werden, nicht gelten.
Je nachdem, was Sie zur Verwaltung Ihres Backlogs verwenden, können Massenbearbeitungen möglich sein oder nicht. Wenn dies der Fall ist, würde ich vorschlagen, immer noch den Durchschnittswert zu verwenden und einfach den gesamten Rückstand auf einmal zu aktualisieren. Genau? Nicht wirklich... Genauer als nichts? Ja. Stellen Sie einfach sicher, dass Ihr Team den „Standardwert“ zukünftiger User Stories immer noch regelmäßig überprüft.
Abgesehen davon ist dies nichts, was ich persönlich implementieren möchte. Ich möchte lieber, dass die Aufwandspunkte leer sind, als einen Standardwert zu enthalten. Ich habe diesen Rat basierend auf Ihrer Frage angeboten, die zu implizieren schien, dass Sie Werte für Ihren gesamten Rückstand wollten/benötigten.

Affinitätsschätzung könnte hier eine geeignete Technik sein. Im Wesentlichen ordnen Sie alle Ihre Backlog-Elemente auf Karteikarten und lassen sie von Ihrem Team in der Reihenfolge ihrer relativen Größe an einer Wand aufhängen (z. B. größere Elemente links und kleinere rechts). Sie erstellen ein Kontinuum von Story-Point-Größen. Dann können Sie Trennlinien erstellen, um Ihre unterschiedlichen Größenwerte (1, 2, 3, 5, 8 usw.) darzustellen, und sich darauf einigen, dass sich die Artikel in einer geeigneten Gruppierung befinden.

Dies wird in den folgenden Blogbeiträgen näher beschrieben:

Dimensionierung eines gesamten Backlogs mithilfe von Story Points
AntwortenHierDatenschutz-Bestimmungen1y, 0v