Scrum Burn Down Charts: Aufgaben oder Geschichten? [geschlossen]

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?

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.

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:

1. Verfolgen Sie den Fortschritt für die Bedürfnisse des Kunden, damit der Projektmanager Einblick in die Vorgänge hat.
2. Überarbeiten Sie die Schätzungen anhand der tatsächlich erforderlichen Arbeiten, um unsere Schätzfähigkeit zu verbessern.
3. Rechnung Kunden für die Zeit tatsächlich ausgegeben, falls es Teil eines Stundensatzes Job ist.
4. Geben Sie Entwicklern Feedback zu ihren Fortschritten, damit sie Ablenkungen entsprechend steuern können.

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).

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.

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.

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.

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.