Wir verwenden ZenHub für Scrum und führen punktbasierte Schätzungen durch.
Wenn es ein zu schätzendes Problem gibt, können wir mit GitHub keine stundenbasierten Schätzungen durchführen? Wie ich sehe, ist nur eine punktbasierte Schätzung verfügbar.
Gibt es dort auch eine Möglichkeit, die geleisteten Stunden / verbleibenden Stunden anzugeben? Weil der Fortschritt auf dem Burndown-Diagramm erst angezeigt wird, wenn wir das Problem schließen.
Ich stimme allem zu, was Todd gesagt hat, und möchte ein paar Punkte hinzufügen:
Das merken Sie
Weil der Fortschritt auf dem Burndown-Diagramm erst angezeigt wird, wenn wir das Problem schließen.
Dies ist beabsichtigt. Die Idee hinter Scrum ist, dass wenn Sie eine Story haben, an der Sie 3 Tage gearbeitet haben und die noch nicht fertig ist, diese Story zu 0% fertig ist. Der Grund dafür ist, dass Sie, da eine nicht abgeschlossene Story keinen (oder negativen!) Geschäftswert bietet, vermeiden, dass das Team viele „90 % fertig“-Storys im Spiel hat, indem Sie sie als 0 % erledigt behandeln.
Sie bemerken auch:
Wir machen [...] punktbasierte Schätzungen. [...] können wir mit GitHub keine stundenbasierten Schätzungen machen?
Vielleicht verstehe ich etwas falsch, aber wenn Ihre Teams in Story Points schätzen, warum versuchen Sie dann, ein Tool zu bekommen, das eine rechtzeitige Schätzung ermöglicht? Was ist Ihre Überlegung, warum Sie eine Zeitschätzung vornehmen möchten? Unter der Annahme, dass die Antwort lautet „weil wir vorhersagen müssen, wann bestimmte Features fertig sein werden“, dann können Sie die geschätzte Punktzahl nehmen und durch die durchschnittliche Geschwindigkeit (des Teams ) dividieren. Wenn es einen anderen Grund gibt, überlegen Sie zunächst, ob Sie die Zeit überhaupt wirklich erfassen müssen oder ob Sie Ihr Problem auf andere Weise lösen können.
Ein auf Story Points basierendes Burndown-Diagramm misst nicht die verbleibende Zeit. Es misst den verbleibenden Arbeitsaufwand, und Sie müssen zusätzliche Metriken verwenden, um Ihren Zeitplan basierend auf dem aktuellen Umfang zu prognostizieren.
Ein auf Story Points basierendes Burndown-Diagramm misst nicht die Zeit, sondern die verbleibende Arbeit. Ich werde nicht auf die Tatsache eingehen, dass es kanonisch keine 1:1-Zuordnung von Story Points zu Arbeitsstunden gibt, obwohl einige Leute und Frameworks die Metrik auf diese Weise missbrauchen. Tatsächlich geht ZenHub selbst das Thema wie folgt an:
Das ist die Grundlage der Story Points. Sie sind einheitslose Messskalen, die in Bezug auf andere Aufgaben bemessen sind. Im Gegensatz zu Stunden, die auf konsistenten Werten basieren, basieren Story Points auf willkürlichen Messungen. Ihr einziger Zweck besteht darin, eine Aufgabe in Bezug auf die Größe Ihrer anderen Aufgaben zu vergleichen.
Mit anderen Worten, wenn Sie Ihre Schätzungen kontinuierlich aktualisieren und die abgeschlossene Arbeit "abbrennen", können Sie jederzeit feststellen, wie viel Arbeit noch übrig ist. In ZenHub und bei User Stories im Allgemeinen ist diese Arbeit ein relatives Maß für den Aufwand, nicht für die Zeit. Sie müssen dann Ihre Timeboxing-Methodik und historische Messwerte wie Geschwindigkeit verwenden, um vorherzusagen, wann die verbleibende Arbeit für die Iteration oder das Release voraussichtlich abgeschlossen sein wird .
nvoigt
Alan Larimer
Todd A. Jacobs