Schätzen Sie abhängige Arbeitselemente in Scrum

Szenario: Nehmen wir an, es gibt zwei Einträge A und B im Product Backlog eines Scrum-Teams. Aus PO-Sicht hat B mehr Kundenwert als A und wird daher höher eingestuft. Wenn man einen Entwickler nach der geschätzten Zeit für die Arbeit an diesen Elementen fragt, gibt er die folgenden Angaben:

  • A dauert 2 Tage
  • B dauert 2 Tage; aber wenn A vorher erledigt ist, dauert B nur 1 Tag (da einige Vorarbeiten auch in A erledigt werden)

Das bedeutet, dass, wenn zuerst B und dann A erledigt wird, die Gesamtzeit für diese beiden Arbeitsaufgaben 4 Tage beträgt. Aber wenn A vor B fertig ist, beträgt die Gesamtarbeitszeit 1 Tag. Dies wird jedoch gegen die Prioritäten verstoßen, da B höher eingestuft wird als A.

Bitte gehen Sie davon aus, dass beide Workitems nicht im selben Sprint erledigt werden können. Ansonsten erübrigt sich diese Frage :)

Aktuelle Frage: Sollten Schätzungen solche Informationen enthalten?

Unsere Überlegung: Wir haben gestern darüber diskutiert, ob die Schätzungen für Arbeitsaufgaben dies berücksichtigen sollten. Sollte ein PO über diese Informationen verfügen, um das Produkt-Backlog basierend auf diesen Informationen neu zu ordnen? Wir kamen zu dem Schluss, dass Schätzungen diese Informationen nicht enthalten sollten, dh B nimmt 2 Tage Zeit, Zeitraum.

Die Gründe dafür sind:

  • Das Product Backlog ist nach Kundenwert geordnet
  • Wenn B eine Aufgabe mit A teilt, was ist mit den anderen Gegenständen? Es wird wahrscheinlich noch mehr solcher Aufgaben geben, die angegangen werden müssen. Dies führt zu langwierigen Diskussionen ohne verlässliches Ergebnis.

Vermissen wir etw. oder ist unser Denken richtig? Es gibt wahrscheinlich noch mehr Gründe, diese Liste zu ergänzen.

Antworten (3)

Ich würde sagen, dass Ihre Überlegungen richtig sind.

Ihre Schätzungen sollten auf der derzeit vorhandenen Codebasis und nicht auf „Was-wäre-wenn“-Szenarien basieren. In Ihrem Beispiel wird Story A möglicherweise nie fertiggestellt und würde weiterhin in der Prioritätenliste nach unten verschoben, sobald neue Informationen verfügbar werden.

Darüber hinaus liegt es auch nahe, dass A vor B zu tun B schneller macht, weil die Grundlagenarbeit abgeschlossen ist, dass B vor A zu tun A aufgrund dieser gemeinsamen Grundlagenarbeit schneller machen würde.

Idealerweise sind Backlog Items unabhängig voneinander, dann würde sich diese Frage nicht stellen.

Wo es technische Abhängigkeiten gibt, liegt es am Entwicklungsteam und dem Product Owner, über die beste Vorgehensweise zu entscheiden.

Einige Dinge, die Sie bei der Entscheidung für einen Ansatz beachten sollten:

  • Wenn ein höherwertiger Artikel später in den Rückstand verschoben wird, verzögert sich auch der Zeitpunkt, an dem er beginnt, einen Geschäftswert zu liefern. Es obliegt dem Product Owner, über die Auswirkungen dieser Verzögerung zu entscheiden.
  • Es ist in der Regel besser, einen Mehrwert geliefert zu haben, als in Arbeit zu sein. Daher kann es manchmal ein Fehler sein, die Lieferung von Werten zu verzögern, um die Gesamteffizienz der Lieferung zu erhöhen.
  • Die Wirksamkeit, mit Punkt B vor Punkt A zu beginnen, setzt voraus, dass beide Punkte abgeschlossen werden. Es besteht immer die Möglichkeit, dass sich die Prioritäten ändern und Punkt A dadurch möglicherweise nicht erledigt wird.

Es sei daran erinnert, dass der agile Ansatz eher die Optimierung der Bereitstellung von Geschäftswert als die Optimierung der Entwicklungseffizienz betont.

Diese beiden Dinge mögen gleich klingen, aber wenn sie auf Veränderungen reagieren, sind sie es möglicherweise nicht. Manchmal ist es effektiver, Kompromisse bei der Effizienz der Entwicklung einzugehen, um schneller auf Veränderungen reagieren zu können.

Ich habe gerade meine Frage aktualisiert, da ich die Abhängigkeiten nicht klar genug war. Das tut mir leid. Ich spreche eigentlich nicht von Abhängigkeiten, sondern von geteilten Aufgaben/Voraussetzungen (irgendwie).
Das kann unangenehm sein. Wenn Sie beispielsweise mit Geschäftsberichten arbeiten, gibt es eine Menge Klempnerarbeit, bevor das erste Stockwerk fertig ist. Die Teams, mit denen ich zusammengearbeitet habe, hatten typischerweise eine „Bootstrap-Geschichte“. Das ist eine Geschichte, die einen kleinen Geschäftswert bietet (sagen wir, sie liefert eine kleine Kennzahl in einem Bericht), und diese Geschichte wird am Ende ziemlich groß, da wir davon ausgehen, dass wir bei der Fertigstellung eine Menge Klempnerarbeit leisten werden. Nachfolgende Geschichten sind einfacher und haben daher kleinere Schätzungen. Auch dieser Ansatz ist fragwürdig. Die Gefahr besteht darin, dass wir mit Geschichten enden, die nicht aus der Reihe gehoben werden können.

Wir würden dies in der Sprintplanung entscheiden. Wenn B wirklich von A abhängt, ist die Antwort einfach.

Wenn das Erledigen von A B weniger „schmerzhaft“ macht, versuchen Sie, sie in denselben Sprint zu versetzen, behalten Sie dies im Hinterkopf und reduzieren Sie den Aufwand für B entsprechend.

Also ja, die Abhängigkeit würde meiner Meinung nach in die Schätzung einfließen.

Wenn A und B gleich bleiben... nun, mach was du willst.

Ich habe gerade meine Frage aktualisiert, da ich die Abhängigkeiten nicht klar genug war. Das tut mir leid. Ich spreche eigentlich nicht von Abhängigkeiten, sondern von geteilten Aufgaben/Voraussetzungen (irgendwie).
Schätzen Sie abhängige Arbeitselemente in Scrum
AntwortenHierDatenschutz-Bestimmungen1y, 0v