Sollte ein Burndown-Diagramm auf Storys oder abgeschlossenen Aufgaben basieren?

TL;DR; Wie der Titel schon sagt: Basieren Sie Ihr Burndown-Diagramm auf abgeschlossenen Storys oder auf abgeschlossenen Aufgaben?

Einige Hintergrundinformationen, warum ich das frage: Ich arbeite derzeit in einem Softwareentwicklungsteam von 4 Entwicklern und mache Sprints, die 2 Wochen dauern. In diesen zwei Wochen bekommen wir im Allgemeinen Geschichten im Wert von etwa 50 bis 70 Storypoints bis „Fertig“. Wir haben regelmäßig Geschichten, die 50 % oder mehr dieser Punkte ausmachen, sagen wir 25 bis 40 Punkte. Das Messen von Geschichten im Vergleich zu Aufgaben führt zu den folgenden Situationen:

Stories: Die großen Stories werden lange „in Arbeit“/„ausgecheckt“/„in Bearbeitung“ sein. Der Burndown verläuft flach, wenn die Geschichte fertig ist, fällt er aufgrund der großen Anzahl verbrannter Story-Punkte ab. Dies ergibt ein gezacktes Diagramm, das den Anschein erweckt, als wäre plötzlich viel getan worden. Außerdem verstärkt das Flatlining-Diagramm nicht das "Wir erledigen Sachen!" Moral. Zu guter Letzt könnten externe Stakeholder/andere Teams die Stirn runzeln, wenn der Burndown ins Stocken gerät (Nebensache, es könnte mich weniger interessieren, solange wir am Ende liefern).

Aufgaben: Das Niederbrennen von Aufgaben innerhalb von Stories vermittelt einen besseren Eindruck von der geleisteten Arbeit. Es wird eine glattere Linie geben und wahrscheinlich die Moral steigern. Mein Hauptziel ist: Es zeigt nicht die tatsächlich geleistete Arbeit an . Die Arbeit ist standardmäßig nur verwendbar, wenn die vollständige Story „FERTIG“ ist. Es ist großartig, dass wir eine Aufgabe für die Geschichte erledigt haben, aber selbst diese letzte kleine unvollendete andere Aufgabe kann die Geschichte daran hindern, fertig zu werden und den Sprint zu schaffen.

Mein Bauchgefühl neigt dazu, Geschichten niederzubrennen , vor allem aufgrund der Tatsache, dass Aufgaben ein trügerisch glückliches Bild zeichnen können, das sich am Ende des Sprints nicht bewahrheiten wird. Ich bin eher skeptisch und angenehm überrascht, wenn sich herausstellt, dass es besser wird. Was macht Ihr Team?

Nachdem Sie zwei weitere Sprints mit dem Team abgeschlossen und Erkenntnisse aus den Antworten unten verwendet haben, ist die Aufteilung in kleinere Stories die nützlichste Antwort. In unserem speziellen Fall ist es immer noch ziemlich schwierig, aber ich stimme zu, dass es in jedem Normalfall die vernünftigste Antwort ist. Ich werde detailliertere Erfahrungen und Rückmeldungen zu den gegebenen Antworten liefern.

Antworten (5)

Um das Burndown-Diagramm für den Product Owner (oder den Kunden oder den Benutzer oder einen anderen Stakeholder) nützlich zu machen, ist das Abbrennen auf der Grundlage von Geschichten die bessere Option. Da eine Story etwas darstellen soll, das für den Stakeholder nützlich und bedeutsam ist, ist es hilfreich zu wissen, wie viele in Bezug auf Ihre Definition von Done to date im Sprint abgeschlossen wurden.

Allerdings scheinen mir deine Geschichten zu umfangreich zu sein. Wenn Ihre Storys zwischen 25 und 40 Punkten liegen und Sie 50 bis 70 Story Points in einem Sprint absolvieren, bedeutet dies, dass Ihre Sprints aus 2-4 Storys bestehen. Sie sollten nach Wegen suchen, Stories in Epics oder Themen zu gruppieren (die sich über mehrere Sprints erstrecken können) und kleinere Stories haben, die zeigen, dass Sie bestimmte (aber immer noch nützliche und sinnvolle) Teile der Funktionalität implementiert und gemäß Ihrer Definition von erledigt abgeschlossen haben.

Als erster und prägnanter, der „Spaltgeschichten“ vorschlägt, werde ich dies als Antwort markieren. Es wurden Variationen Ihres Vorschlags gegeben, aber diese Antwort trifft den Kern der Dinge. Erfahrung aus den letzten beiden Sprints: Es ist wichtig, den tatsächlichen Fortschritt bei fertiggestellten Artikeln und gelieferten verwendbaren Produkten zu zeigen. Wenn die Geschichten groß sind, ist es der richtige Weg, sich zu bemühen, einen Weg zu finden, sie aufzuteilen.

Basierend auf früheren Erfahrungen mit vielen verschiedenen Ansätzen würde ich Ihrem letzten Absatz zustimmen - alles andere als den gelieferten wahren Wert zu zeigen (Aufzeichnung von Aufgaben, Stunden, Punkten usw.) führt oft zu Sprints, bei denen viele Elemente fast fertig sind und sehr wenig Wert haben geschaffen.

Sie könnten auch nach Möglichkeiten suchen, die Elemente in kleinere Elemente (nicht Aufgaben) aufzuteilen, damit Sie immer noch einen Mehrwert liefern, aber nicht so viel „flatlinen“. Beispielsweise werden einige meiner Teams ein Element mit einer neuen Benutzeroberfläche oder einer benutzerorientierten Komponente zusammen mit der Implementierung haben, und sie werden es nach den Grundsätzen „Papiermodell und Benutzertests/Feedback“ und „Implementierungsergebnisse nach Benutzertests“ aufteilen ", weil das Team weiß, dass Benutzertests einen Mehrwert (Wissen) bieten.

Sehr guter Vorschlag, andere Akteure in Geschichten als menschliche Benutzer zu definieren. Dies ermöglicht mehr Flexibilität beim Schreiben von Geschichten, dh „als Front-End-Controller möchte ich in der Lage sein, eine Liste von Admin-Benutzern aus der Datenbank abzurufen“. Das nutzen wir jetzt. Der Nutzen für andere hängt vom Kontext und insbesondere vom Product Owner ab.
Es gibt sicherlich gelegentlich einen Grund, eine Geschichte aufzuschlüsseln, ohne den Kundenwert zu nutzen, aber das ist ziemlich selten. User Stories sollen den Customer Facing Value artikulieren, der fast immer vorhanden sein wird. Es ist wichtig, sich daran zu erinnern, dass der Kunde nicht immer ein Endbenutzer ist. Es kann ein interner Benutzer sein. (dh "Als Moderator möchte ich in der Lage sein, eine Liste von Admin-Benutzern aus der Datenbank abzurufen") Brechen Sie eine Geschichte nicht willkürlich herunter, nur um Ihre Zahlen aufzublähen. Das konzentriert die Energie weg von der Teamverbesserung. Fokus: Wer will diese Daten und warum.

Die Antwort hängt davon ab, wer Ihr Publikum ist.

Wenn es für die Feature-Crew (dh Product Owner / Entwickler) ist:

Der Hauptzweck des Burndown-Diagramms besteht darin, zu zeigen, wie sich das Team in Richtung Abschluss der einzelnen Aufgaben bewegt, die für den Sprint vorgesehen sind. Es hilft dem Team auch zu verstehen, wie es mit Schätzungen (Storys und Aufgaben) umgeht, und sollte auf Aufgabenebene angezeigt werden . Das Team sollte sich dies mehrmals pro Woche ansehen, wenn nicht sogar täglich.

Einige wichtige Dinge, auf die Sie achten sollten:

  1. Burning Up: Dies bedeutet, dass die Aufgaben zu weit im Sprint erstellt werden. Ein Symptom dafür ist, dass entweder zu Beginn nicht genügend Zeit für die Erstellung von Aufgaben eingeräumt wird oder die Personen ihre Arbeit nicht richtig planen.
  2. Langsamer Abwärtstrend: Dies kann ein Fehlalarm sein, wenn das Team seine Daten nicht täglich aktualisiert. Wenn das der Fall ist, zeigen Sie das Diagramm jeden Tag während des Aufstehens als Erinnerung. Der wirklich positive Grund dafür ist, dass zu viel Arbeit in den Sprint gesteckt wird, als dass das Team sie bewältigen könnte. Wenn dies der Fall ist, konzentrieren Sie sich bei der Planung mehr auf die Schätzung. Das Erlernen der genauen Schätzung ist ein iterativer Prozess, an dem das gesamte Team zusammenarbeiten muss. (Die Planung von Poker und Kumpels für Aufgaben ist eine gute Möglichkeit, dabei zu helfen.)

Wenn es für die Stakeholder ist:

Burndown-Diagramme auf Aufgabenebene können für sie dennoch sehr nützlich sein. Die Ansicht, an der sie jedoch am ehesten interessiert sein werden, sind die Titel der User Stories (da diese den Kunden, den Wert und die Wirkung umrahmen sollten) und ihr aktueller Status. Ein Burn-Down-Chart der User Stories ist für die Stakeholder Persona weniger informativ.

Ich bin eher skeptisch und angenehm überrascht, wenn sich herausstellt, dass es besser wird. Was macht Ihr Team?

Als Product Owner / Scrum Master ist es Ihre Aufgabe, dem Team zu helfen, genauer zu sein. Verwenden Sie diese Tools zusammen mit anderen (z. B. Retrospektiven), um dem Team zu helfen, besser zu werden .

Ich arbeite derzeit in einem Softwareentwicklungsteam von 4 Entwicklern und mache Sprints, die 2 Wochen dauern. In diesen zwei Wochen bekommen wir im Allgemeinen Geschichten im Wert von etwa 50 bis 70 Storypoints bis „Fertig“. Wir haben regelmäßig Geschichten, die 50 % oder mehr dieser Punkte ausmachen, sagen wir 25 bis 40 Punkte.

Es hört sich so an, als wären Ihre User Stories zu groß. Mein Rat ist, einen Blick auf die logische Gliederung der Geschichte zu werfen und sicherzustellen, dass sie sich darauf konzentriert, den richtigen Wert zu liefern. Storys können unter Features oder Epics zusammengefasst werden, die sich über mehrere Sprints erstrecken. Es gibt viele kostenlose Ressourcen dazu, aber dieses Buch hat mir gefallen:

http://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909

'Helfen Sie dem Team, besser zu werden' Sie haben sehr recht. Schlechte Wortwahl und einige Missverständnisse meinerseits. Gute Vorschläge in Ihrer Antwort, wir teilen die Geschichten jetzt in der Tat so weit wie möglich auf. Unser Burndown basiert nach wie vor auf Stories, sprich: basierend auf gelieferten brauchbaren Produkten. Alles, was nicht vollständig getestet und verwendbar ist, schafft keinen Wert, also bleiben wir bei Geschichten (obwohl ich denke, Sie könnten Ihre Aufgaben so anordnen, dass vollständig verwendbare Produkte geliefert werden, aber dann treten wir aus der Praxis heraus und in die Semantik ein).

Warum basiert das Burndown-Diagramm nicht auf beiden?

Geben Sie hier die Bildbeschreibung ein

Es hat den Vorteil, dass es Ihnen einige Einblicke darüber gibt, was in Bezug auf Ihre Aufgaben passiert (so dass es den tatsächlichen Aufwand deutlich zeigt ), ohne es aus dem Kontext der Geschichten zu reißen (da es den Wert obendrauf setzt ).

Der interessanteste Punkt scheint zu sein, dass es die Beziehung zwischen Anstrengung und Wert zeigt : Zum Beispiel zeigen die ersten beiden Geschichten in diesem Diagramm einen schnellen Anfang und dann etwas Schmerz gegen Ende. Sogar ein Plateau im Aufwand findet sich im zweiten Stock. Auf der anderen Seite zeigt die dritte Geschichte am Anfang etwas Schmerz, aber am Ende zeigt sie eine schnelle Fertigstellung.

Diskussionsgegenstand für das End-of-Sprint-Meeting. Wie können wir das verbessern? Was bedeutet das? Sind Geschichten, die schnell beginnen, auf lange Sicht am Ende schmerzhaft? usw.

Ich mag den Pragmatismus! Ihr Vorschlag, beides zu tun, wird wahrscheinlich für einige Teams von Nutzen sein. Unser Team hat festgestellt, dass es viel wichtiger ist, sich auf fertige, brauchbare Produkte zu konzentrieren, als sich über teilweise Fortschritte zu freuen. Wir haben uns daher entschieden, das Burndown auf Story-Ebene zu belassen. Sie haben sehr recht mit der Rolle der Retrospektive bei all dem. Seitdem hatten wir zwei Retrospektiven, die beide viele Einblicke in die eigentliche Ursache des Problems und Möglichkeiten zur Verbesserung in der Zukunft geben.

Verwenden Sie niemals Aufgaben mit Zeitschätzungen. Je. Dafür gibt es viele Gründe.

  1. Zum einen ist es nicht agil. Wir verwenden "funktionierende Software" und nicht "erledigte Aufgaben" als primäres Maß für den Fortschritt

  2. Eine Abschätzung in absoluter Zeit ist unmöglich. Selbst wenn es nicht so wäre, Ihre Zeit ist nicht gleich meiner Zeit

  3. Es ist ein Rezept für altes Befehls- und Kontrollverhalten

  4. Es unterscheidet sich nicht von einem Gantt-Diagramm

  5. Es ermutigt, einem Plan zu folgen, anstatt auf Veränderungen zu reagieren.

  6. Die Arbeit WIRD erweitert, um die Timebox zu füllen.

  7. Die Entwickler sprechen von Aufgaben und nicht von Wertlieferung.

  8. Es täuscht – wenn 90 % der Arbeitsstunden erledigt sind, denkt jemand, dass nur noch 10 % übrig sind, obwohl es tatsächlich weitere 90 % von 150 % sein könnten.

  9. Ergebnisse in Regelkarten, die falsch interpretiert werden können

  10. All dies UND es kostet uns viel zu warten

  11. Es fördert die Spezialisierung

Und weiter und weiter und weiter.

Einfach nicht.

Sollte ein Burndown-Diagramm auf Storys oder abgeschlossenen Aufgaben basieren?
AntwortenHierDatenschutz-Bestimmungen1y, 0v