Geschwindigkeitsberechnung basierend auf der Anzahl der in einem Sprint abgeschlossenen User Stories

In einem der Projekte erfolgt die Velocity-Berechnung basierend auf der Anzahl der User Stories, die das Team in jedem Sprint liefert.

Sie verwenden Story Points, um die Größe zu bestimmen, aber die Geschwindigkeit wird immer noch durch die Gesamtzahl der gelieferten Storys bestimmt und basiert nicht auf den Story Points.

Der Kunde wollte auf dieser Grundlage nachverfolgen, um sicherzustellen, dass wir die bereits festgelegte Freigabefrist für das Projekt einhalten.

Wie geht man damit um?

Ist das Kunden- oder Team-Tracking anhand von Stories abgeschlossen? Wenn die Veröffentlichungsfrist festgelegt ist, ist der Umfang flexibel? Oder ist das ein Wasserfall-Projekt mit agilen Buzzwords darüber gestreut?
Wenn nicht alle Storys genau die gleiche Größe haben, ist das Verfolgen von abgeschlossenen Storys an sich keine nützlichen Daten.
@Erik Scope ist auch flexibel; in dem Sinne, dass sie innerhalb eines Sprints einige zusätzliche User Stories machen. Die Freigabefristen werden im Voraus definiert und die Entwicklungslieferung erfolgt in Iterationen.

Antworten (2)

Sie müssen zuerst verstehen, inwieweit die Anzahl der Geschichten hilfreich ist, und wir tun dies mit Standardabweichung. Wenn wir uns die durchschnittliche Story-Größe über eine Version hinweg ansehen und die Standardabweichung gering ist, werden Sie feststellen, dass die Trends, die zwischen der auf der Story-Größe basierenden Geschwindigkeit oder der auf der Anzahl basierenden Geschwindigkeit erzeugt werden, identisch sind. Wenn die Standardabweichung hoch ist, entwickeln sie sich unterschiedlich. Wenn Sie kein großer Mathe-Fan sind, gibt es eine einfache visuelle Möglichkeit, dies zu tun. Zeichnen Sie in demselben Diagramm (2 verschiedene y-Achsen-Skalen) beide Geschwindigkeiten. Sehen die Linien gleich aus? Wenn ja, können Sie beides verwenden. Wenn nicht, bleiben Sie bei der Story-Größe, nicht beim Zählen.

Es gibt eine ziemlich große „Noestimates“-Bewegung, die viel Erfolg damit hat, alle Geschichten in der richtigen Größe zu gestalten, sodass sie ungefähr die gleiche Größe haben, und dann nur auf die Zählung zu achten. Sie müssen nicht genau gleich sein. Um eine konkrete (wenn auch hypothetische) Regel zu geben: Ein Team, das Punkte mit einer durchschnittlichen Geschwindigkeit von 40 verwendet, würde wahrscheinlich die meisten Geschichten um eine 3 und eine kleine Anzahl von ihnen um eine 1 oder 5 herum haben wollen, bevor sie die Story-Punkte fallen lassen könnten. (Dies ist ein zutiefst fehlerhaftes Beispiel, verwenden Sie es nicht wirklich zur Implementierung, sondern versuchen Sie nur, etwas Konkretes zu geben.

Jetzt sollten wir auch über das letzte Stückchen darüber sprechen, dass wir für einen aktuellen Liefertermin in der Schlange stehen. Aus Ihren Kommentaren geht hervor, dass Umfang und Zeit festgelegt sind, was fast immer problematisch ist. Unabhängig davon, welche Metrik Sie verwenden, muss jedes weniger als wünschenswerte Bild, das die Prognose zeichnet, verwendet werden, um den Rückstand zu verwalten, nicht das Team, oder Sie werden eine Menge dysfunktionales Verhalten bekommen und wahrscheinlich die Sichtbarkeit Ihres Fortschritts verlieren.

Wenn Sie Storys unterschiedlicher Größe haben , müssen Sie die Geschwindigkeit basierend auf dieser Größe verfolgen, unabhängig davon, ob es sich um Story Points oder eine andere Metrik handelt.

Es gibt nichts, was Sie tun können, um eine völlig fehlerhafte Metrik von Stories pro Sprint zu reparieren, wenn sie nicht die gleiche Größe haben. Werfen Sie es weg und fangen Sie von vorne an. Generieren Sie nach Möglichkeit frühere Geschwindigkeiten für die neue Metrik basierend auf Ihren alten Geschichten.

Dies ist meiner Erfahrung nach nicht der Fall. Ich habe viele Teams gesehen, die mit Story Count im Gegensatz zu Story Points erfolgreich waren. Tatsächlich basiert die gesamte No-Estimates-Bewegung auf solchen Erfolgen. Es kann in diesem Fall gut gemacht werden oder nicht, aber es ist sicherlich möglich.
Bei 19 Geschichten mit 1 Punkt und einer Geschichte mit 20 Punkten sagt eine Metrik, die besagt, dass die Hälfte der Geschichten abgeschlossen ist, genau nichts über die Fähigkeit aus, die andere Hälfte in der gleichen Zeit fertigzustellen. Also ja, jedes Projekt kann mit jeder Metrik erfolgreich sein. Ich war in einem Projekt, in dem der PM einfach gelogen und farbenfrohe Diagramme erstellt hat, um Kunden unabhängig von Zahlen zur Zahlung zu bewegen. Aber wenn Sie mathematisch fundierte Zahlen für Prognosen liefern wollen, ist die Anzahl der Geschichten ungefähr so ​​wertvoll wie das Bauchgefühl. Manche Menschen haben ein tolles Bauchgefühl. Das bedeutet nicht, dass es eine großartige Methode ist.
Eine Million Upvotes dafür - das ist eine kaputte Metrik und bietet keinerlei Wert.
@Daniel: In der No-Estimates-Bewegung muss alles verfeinert werden, bis es ungefähr die gleiche Größe hat. Wenn Sie diesen Punkt erreichen, können Sie genauso gut sagen, dass jede Geschichte 1 SP ist. Der Fallstrick beim blinden Zählen von Geschichten (ohne sicherzustellen, dass sie gleich groß sind) besteht darin, dass Sie zählen, wie viele Äpfel und Melonen in einen Korb passen.
Geschwindigkeitsberechnung basierend auf der Anzahl der in einem Sprint abgeschlossenen User Stories
AntwortenHierDatenschutz-Bestimmungen1y, 0v