Wir verwenden verbleibende Zeit für Sprint Burndown - Teams können jeden Tag Fortschritte sehen. Wenn es flache Teile gibt, dann sind sie wirklich passiert.
Im release burndown verwenden wir Story-Punkte . Bei der Release-Planung geht es mehr um die vollständige Funktionalität, die Zeit wird auf der Sprint-Ebene verfolgt. Produkteigentümer interessiert sich für abgeschlossene Geschichten.
Anzahl der Aufgaben ist nutzlos . Diese Zahl kann jeden Tag geändert werden, besonders wenn Sie den Entwicklern eine "Freiheit" geben. Sie können die Aufgabe ohne Änderung der Gesamtzeit in einen kleineren Teil aufteilen. Eine solche Statistik ist nutzlos. Was zeigt es an? Beeinflusst es das Ziel des Sprints?
Normalerweise müssen wir die Stunden (Schätzung vs tatsächlich vs Schätzung, um abzuschließen) gegen Geschichten für die Kunden verfolgen, die danach gefragt haben. Dies ermöglicht uns, ein paar Dinge zu tun:
Wir verfolgen auch abgeschlossene Geschichten für unseren eigenen Burndown, aber wie gesagt wurde, kann dies zu einem Plateau-Effekt am Anfang des Sprints führen, der dazu dient, uns sehr wenig nützliche Informationen zu erzählen (abgesehen davon, dass wir es nicht tun) genug parallel).
Es gibt mehrere Möglichkeiten, Diagramme in Scrum zu brennen.
Manche Leute schlagen vor, die Story Points von unvollendeten Storys zu verwenden, die in Scrum als Burn Down Charts übrig sind.
Pro : Nur fertige Geschichten senken das Diagramm
Kontra : Diagramm bewegt sich nicht am Anfang nach unten und fällt dann schnell ab
Andere schlagen vor, die Anzahl der verbleibenden Aufgaben zu verwenden
Pro : Das Diagramm wird nach unten verschoben, Sie können sehen, ob es über der Ziellinie liegt
Contra : Du könntest nach unten gehen, um am Ende 10 Aufgaben (harte Aufgaben) zu sagen, und hast noch immer keine Geschichte beendet. Sie haben versagt, weil nur fertiggestellte Daten für Ihren Produktbesitzer gut sind.
Ist die Lösung sowohl ein Point-of-not-Fertig-Stories als auch ein nicht-fertiggestelltes Task-Diagramm?
Burndowns (oder sogar "Burn-ups") sollten nur auf verbleibende Arbeit hinweisen.
Wenn Sie die Hälfte der Geschichte gemacht haben, können Sie sie nicht versenden, und sie zählt nicht. Wenn du den Frühling mit einer halben Geschichte beendest - Aufgaben, die darin gemacht wurden, zählen nicht, wenn du die Geschwindigkeit misst.
Zeigen Sie einfach Stories links an, um abgeschlossen zu werden.
Das ist eine härtere Maßnahme, aber es ist sinnlos, die Zahlen zu massieren - Scrum soll schlechte Nachrichten vermitteln, damit die Dinge behoben werden.
Das Nachverfolgen der Anzahl der verbleibenden Aufgaben ist nicht sehr hilfreich, da die Aufgaben wahrscheinlich unterschiedliche Größen haben.
Sie sollten sich nicht in einer Situation befinden, in der das Team zehn Aufgaben und kein Rückstandsobjekt erledigt (eigentlich ist dies bei zehn Entwicklern möglich): Jeder Entwickler sollte keine Aufgaben von einem anderen Rückstandsobjekt (Story) übernehmen, bis er vervollständigt das Backlog-Item die ersten Stories, die er auch gehört hat - Event, wenn die Aufgabe der anderen Story härter ist als die restlichen Aufgaben aus der gestarteten Sotry.
Ich habe viel Zeit für das Burndown gebraucht. Das Team merkt immer, dass das Tracking-Burndown nach der Zeit dem Time-Tracking-System nahekommt, den Verwaltungsaufwand erhöht und wirklich nicht korrekt ist, es sei denn, wir verwandeln Menschen in Roboter.
Ich verwende Aufgaben burndown (Gesamtaufgaben, neue Aufgaben, fertiggestellte Aufgaben). Viel besser. Es stimmt, dass Sie die Größe der ausgeführten oder neuen Aufgaben nicht sehen. Aber das Team trifft sich jeden Tag und da fängt man Probleme. Außerdem trainiere ich das Team, um keine großen Aufgaben zu machen (4 bis 6 Stunden). Außerdem habe ich ein anderes Diagramm mit neuen Aufgaben und Erledigt Aufgaben am Tag hinzugefügt. Das Team fand heraus, dass das Burndown nach Aufgaben sinnvoller ist als Stunden.
Nachdem das Team die Werte des Aufschlüsselns von Stories in Aufgaben verstanden hat, möchte ich Burndown anhand von Stories versuchen. Also kleine Stories mit maximal 5 oder 8 Story Points. Aus dem Blog von Jeff Sutherland ist dies ein großer Schritt, um ein Team zu Höchstleistungen zu bringen.
Außerdem möchte ich erwähnen, dass ein Burndown nur eine "Auf einen Blick Darstellung des Fortschritts" ist. Am wichtigsten und noch relevanter für das Team und die POs sind: Was wird täglich über die Aufgaben erwähnt + Fortschritt der Geschichte + Liste der Hindernisse. Nach einer Weile kümmern sich Management und Teammitglieder nicht mehr um den Burndown (oder verbrennen).
Wir machen beides, als ob wir keine Aufgaben hätten, die unsere Linie auf eine Weise plateauieren würde, die es so aussehen lässt, als würde nichts getan.
Wenn eine Geschichte 2 Tage dauert, um zu beenden, dann haben Sie eine flache Linie für 2 Tage, und es gibt keine Möglichkeit zu sagen, ob das Team auf ihren Daumen sitzt, oder dass die Arbeit zugenommen hat (also einen Sprung in den Arbeitsstunden).
Natürlich kann die Task-Line abstürzen, ohne zur Fertigstellung von Stories beizutragen. Dies ist ein Anti-Pattern, das auftreten kann, wenn Entwickler Aufgaben nach Belieben auswählen können.
Meiner Meinung nach sind Tracking-Aufgaben ein eher suboptimaler Tracking-Ansatz. Meiner Erfahrung nach ist eine Geschichte selten wirklich die Summe ihrer Aufgaben - und oft finde ich bei der Umsetzung einer Geschichte, dass die Aufgabenaufteilung ohnehin nicht optimal war.
Und während ich bei der Schätzung einer Geschichte Wert auf Brainstorming-Aufgaben lege, bevorzuge ich Geschichten, die klein genug sind, dass es keinen Drang gibt, sie überhaupt zu verfolgen. In der Tat ist es sehr irreführend, Kredite für abgeschlossene Aufgaben zu bekommen, da sogar die Hälfte aller identifizierten Aufgaben noch nicht abgeschlossen ist, ist keine Garantie dafür, dass der Sprint überhaupt irgendeinen Wert liefern wird. Und daran interessiert sich am Ende auch die Stakeholder: Wie viel wird der prognostizierte Wert tatsächlich liefern?
Das Nachverfolgen von Stories und das Arbeiten an weiteren Stories führt zu einem genaueren Feedback und verringert das Risiko, dass kein Wert geliefert wird.
Tatsächlich, wenn ich mit kleinen Geschichten arbeite, sehe ich keinen großen Wert in Sprint-Charts herunterbrennen - nur das Anschauen von Geschichten an der Wand von Karten bewegt sich von "tun" zu "in Arbeit" zu "fertig" geben Sie alle Informationen, die Sie brauchen. Ein Release-Burn-Down ist jedoch nach meiner Erfahrung sehr wertvoll.
Verbleibende Stunden für Sprint Burndowns - Berücksichtigen Sie bei der Sprint-Planung alle Arbeiten, um eine Geschichte gemäß Ihrer Definition von "erledigt" zu erstellen - Entwickler und Tester berechnen jeden Tag die verbleibenden Stunden für ihre gesamte Arbeit neu (Wechsel nach oben oder nach unten) - verfolgen Sie den Sprint-Burndown über verbleibende Stunden - ein guter Indikator dafür, wie gut oder schlecht ein Sprint läuft
Dies ist nicht für Releaseburndowns geeignet, da Sie nicht alle Stories im Backlog aufschlüsseln, sondern nur diejenigen für den nächsten Sprint im Sprintplanungsworkshop. Verwenden Sie also Story burndowns (relative Größen- und Komplexitätswerte, die vom gesamten Team bei der Planung von Poker-Sessions abgeleitet wurden). Dies ist ein guter Indikator für Fortschritte in Richtung Ihrer Veröffentlichung.
Wir verwenden Aufgaben, weil sie so viel mehr Granularität bieten. Wenn wir nur die Fertigstellung von Stories grafisch darstellen (was wir 5-10 pro zweiwöchigem Sprint tun), wird nur jeden Tag oder jeden Tag eine Änderung angezeigt, und, wie Sie erwähnen, wird sich während des Sprints nicht viel bewegen.
Eine weitere nützliche Sache, die mein Team gefunden hat, ist die Verwendung eines gestapelten Liniendiagramms mit jeweils einer Zeile für "Aufgabe", "In Bearbeitung", "Bereit für Qualitätssicherung" und "Validiert". Auf diese Weise ist es einfach, jede Phase in dem Prozess zu sehen, der ein Backup erstellt.