Ich frage, weil wir uns Pivotal Tracker ansehen, von dem ich glaube, dass es ein sehr beliebtes Tool für das Management von Scrum-Projekten ist, und:
Wenn die Verwendung von Aufgaben und die Aktualisierung von Aufgaben mit geschätzten verbleibenden Stunden Scrum Best Practice ist – warum sollte es in einem der beliebtesten Scrum-Management-Tools weggelassen werden und warum sollten sie kein Sprint-Burndown-Diagramm unterstützen?
Ich denke, die Antwort auf Ihre Frage ist ein Widerspruch zu Ihrer Grundprämisse: Das Aktualisieren von Aufgaben mit geschätzten Stunden ist nicht unbedingt eine „Scrum Best Practice“.
Ein Teil des Sinns von Scrum besteht darin, genaue und empirische Daten zu verwenden, um genaue Schätzungen des Arbeitsaufwands zu liefern, der erledigt werden kann. Meiner Erfahrung nach ist es am besten, User Story Points zu verwenden – in meiner Firma verwenden wir eine modifizierte Fibonacci-Folge (1/2/3/5/8/13/20/40/100), um jede User Story zu schätzen. Nach ein paar Sprints bekommt man ein ziemlich gutes Gefühl für die Geschwindigkeit des Teams.
Wir verwenden Story Points, weil sie genau , aber nicht unbedingt präzise sind, während die Schätzung in Stunden eher das Gegenteil ist – Teams versuchen, eine genaue Schätzung vorzunehmen, die normalerweise am Ende nicht sehr genau für eine Aufgabe ist. Wir haben lange versucht, Geschichten mit Punkten und Aufgaben mit Stunden zu schätzen, aber die Zeit, die wir damit verbracht haben, genaue und präzise Stundenschätzungen für jede Aufgabe zu erstellen, hat uns mehr gekostet, als sie uns jemals gebracht hat. Wer braucht eine genaue Stundenschätzung, wenn ein Team zuversichtlich sagen kann: „Wir werden in diesem Sprint 35 User Story Points schaffen“?
In Bezug auf das Burndown-Diagramm haben Sie einige Möglichkeiten:
Meine dringende Empfehlung ist, zu überdenken, wie Sie Dinge einschätzen, und zu einer Story-Point-Methode oder relativen Größenbestimmung überzugehen.
Das Beste an Story Points ist, dass Sie, sobald Sie eine angemessene Menge an Zeiterfassungsdaten erhalten haben, damit beginnen können, Ihre Median- und Standardabweichung der Zeitwerte für jede diskrete Story Point-Bewertung zu ermitteln (z. B. dauert die Median-2-Punkte-Story). n Stunden mit einer Standardabweichung von x). Obwohl ich die Verwendung dieser Kennzahlen als Metriken oder KPIs niemals befürworten würde, verwende ich eine Methode mit diesen Werten, um Schätzungen für Arbeitsumfänge in Verbindung mit anderen Daten und Analysen eines Projekts zu berechnen.
Der Scrum-Leitfaden sagt nichts über das Nachverfolgen und Aktualisieren der verbleibenden Stunden und zwingt Sie auch nicht, einen Burndown zu verwenden, um den Fortschritt zu überwachen. Tatsächlich ist der Stundenverbrauch der schlechteste Fortschrittsindikator, da er gut aussieht, aber keine Unsicherheit zeigt. Du denkst, du bist auf dem richtigen Weg, bis du das Ziel verfehlst und siehst, dass es eine Menge zusätzlicher Arbeit gibt, und jetzt bist du im Rückstand.
Verschiedene projektive Praktiken bei Trendanalysen wurden verwendet, um Fortschritte zu prognostizieren, wie z. B. Burn-downs , Burn-ups oder kumulative Flüsse. Diese haben sich bewährt. Diese ersetzen jedoch nicht die Bedeutung der Empirie. In komplexen Umgebungen ist unbekannt, was passieren wird. Nur was geschehen ist, darf für zukunftsgerichtete Entscheidungen herangezogen werden.
Auf dem Tag der agilen Evangelisten vor einigen Jahren in Amsterdam sagte Jeff Sutherland (Gründer von Scrum), wenn er ein Tool verwenden müsse, dann wäre es PivotalTracker , aber besser wäre gar kein Tool. Außerdem mag er es nicht, Stunden zu verfolgen, und nennt es Zeiterfassungs-Anti-Scrum . Er schlägt vor, dass es das erste ist, was ein Unternehmen verbietet. Er schlägt vor, dass Tracking-Stunden 10% Ihrer Entwicklungszeit kosten, da Entwickler es hassen, weil es verwendet wird, um die falschen Signale zu steuern, wenn es überhaupt verwendet wird.
Wenn es um die Auswahl von Werkzeugen für einen Prozess geht, sage ich immer: Bauen Sie Prozesse um (vorhandene) Werkzeuge auf, finden Sie keine Werkzeuge für Ihren idealen Prozess, weil Sie ihn nicht finden werden. Wenn Sie es als Entwicklungswerkstatt versuchen, könnten Sie sogar sagen, das Tool existiert nicht, bauen wir es selbst! Und jetzt sind Sie in jahrelangen Schwierigkeiten.
Todd A. Jacobs