Sprint Story Point aus PM-Perspektive

Als Projektleiter interessiert mich der Aufwand (geschätzt und tatsächlich). Während die sprintbasierte Schätzung auf Story Points basiert, wie kann ich sie in Aufwand übersetzen, damit ich sie verfolgen und melden kann.

Immer wieder höre ich, dass wir davon absehen sollten, Stunden mit Storypoints zu verknüpfen; aber als PM muss ich meinen Aufwand als Stunden verfolgen. Übersehe ich hier etwas?

Ich dachte, es wäre gut zu erklären, warum ich das brauchte. Dies aus zwei Perspektiven:

  1. Abrechnung (Kundenabrechnung muss in Stunden erfolgen)

  2. Vergleich der Produktivitätsverbesserungen und organisatorische Basisauskleidung.

Antworten (2)

Zeitbasierte Schätzung und Story Point-Schätzung sind unterschiedliche Konzepte. Es gibt zwei große Unterschiede:

  • Bei der Story-Point-Schätzung schätzt das Team die relative Größe der Aufgaben. Zum Beispiel ist Story A doppelt so groß wie Story B. Das Ziel ist, dass das Team diese relative Dimensionierung auf konsistente Weise durchführt.
  • Die Schätzung von Story Points ist ein auf Metriken basierender Ansatz. Die Idee ist, etwas zu arbeiten und dann zu messen, wie lange es gedauert hat, es abzuschließen. Verwenden Sie dann diese Messung, um die Zeit vorherzusagen, die für zukünftige Arbeiten ähnlicher Größe benötigt wird .

Wenn es eine geschäftliche Anforderung gibt, den Aufwand in Zeiteinheiten zu verfolgen (z. B. wenn Sie einem Kunden die geleisteten Arbeitsstunden in Rechnung stellen müssen), sollte dies durch Protokollieren der Zeit erfolgen, die zum Abschließen von Aufgaben benötigt wird. Dies wäre völlig getrennt von dem Story-Point-Schätzprozess.

Denken Sie daran, dass diese Art der Zeiterfassung einen Overhead darstellt und daher die Leistung des Teams verringert. Das Team kann sich durchaus weigern, die Zeit zu protokollieren, es sei denn, es sieht eine gute Rechtfertigung dafür.

Wenn Sie auch den geschätzten Aufwand in Zeiteinheiten verfolgen möchten, müsste das Team zwei Schätzungsrunden durchführen. Zuerst würden sie die Story Point-Schätzung (für Scrum) durchführen und dann müssten sie eine zeitbasierte Schätzung durchführen (um die Anforderungen des Projektmanagements zu erfüllen).

Dies würde wiederum einen Overhead einführen, der die Leistung des Teams verringern würde. Und wieder einmal müssten diese Kosten gerechtfertigt werden.

Sie können einen Story Point nicht direkt in ein Stundenäquivalent übersetzen. Ein Story Point ist bestenfalls eine kontinuierliche Verteilung, die einen Bereich von Zeitwerten darstellt, in denen eine Story abgeschlossen werden könnte.

Etwas wie 2 Story Points = 3 Tage Aufwand zu sagen ist falsch.

Es könnte jedoch wahr sein, dass eine 2-SP-Geschichte eine durchschnittliche Fertigstellungszeit von 3 Tagen mit einem Minimum von 1 Tag und Maximum von 5 Tagen hat, wenn ein Konfidenzintervall von 95 % verwendet wird.

Wer fordert, Aufwandswerte aus Story Point- oder Velocity-Werten abzuleiten, denkt immer noch in Wasserfall-Begriffen. Wenn Sie unbedingt Aufwandswerte angeben müssen, besteht eine gängige Methode darin, Storys in Aufgaben zu zerlegen und die Teammitglieder ihre geschätzten und tatsächlichen Stunden mit den einzelnen Aufgaben nachverfolgen zu lassen.

Wenn Sie diesen Weg gehen, werden Sie jedoch feststellen, dass sich viele Teammitglieder darüber beschweren, dass dies ein Verwaltungsaufwand ist. Sie werden auch auf Polsterungsverhalten stoßen. Wenn Sie schließlich mit bestimmten Arten von Wasserfallmanagern arbeiten, setzen Sie das Team dem Mikromanagement aus – etwas, das bei agilen Scrum-Teams im Allgemeinen ein absolutes No-Go ist.

Nebenbei bemerkt gibt es in einem Scrum-Team idealerweise keine PM-Rolle. Die 3 Vanilla-Rollen sind PO, Teammitglied und Scrum Master. Ein Großteil der traditionellen PM-Arbeit wird im Allgemeinen zwischen dem PO und dem Scrum Master aufgeteilt, wobei die verbleibenden organisatorischen Aufgaben beim allgemeinen Team liegen, wo Einzelpersonen ermutigt werden, sich selbst zu organisieren und befähigt werden, über die traditionellen Entwickler- oder QA-Rollen hinauszugehen. Allerdings gibt es viele großartige PMs in Scrum-Teams, die in eine dienende Führungsrolle übergehen und der größeren Organisation helfen, agiler zu werden, da traditionelle PM-Verantwortlichkeiten vom Team übernommen werden
Was wäre also ein guter Weg, wenn ein Kunde um eine Schätzung der Gesamtprojektkosten bittet? Es sollte eine Möglichkeit geben, die SP in abrechenbare Stunden umzuwandeln, oder?
Nein, Story Points sind Wahrscheinlichkeitsverteilungen über die Zeit, daher ist es unmöglich zu versuchen, einen Story Point mit einem genauen Stundenäquivalent gleichzusetzen. Sie können Story Points verwenden, um Prognosen abzuleiten, wann ein Projekt abgeschlossen werden könnte. Viele Teams führen eine bereichsbasierte Schätzung durch. Also zum Beispiel 12-16 Wochen mit 80%iger Sicherheit. Teams verbrennen im Allgemeinen einen festen Betrag an Bargeld über einen bestimmten Zeitraum, um eine Kostenspanne abzuleiten. Dies setzt voraus, dass der gesamte Rückstand bekannt ist, was immer falsch ist.
Der Trick besteht darin, mit dem Kunden zusammenzuarbeiten, um ihm verständlich zu machen, dass sich Scrum-Teams auf die inkrementelle Wertschöpfung konzentrieren und nicht davon ausgehen, dass der gesamte Umfang im Voraus bekannt ist. Verkaufen Sie dem Kunden die Fähigkeit des Teams, Prioritäten zu verschieben und im Laufe der Zeit einen Wertrückstand zu entwickeln, anstatt dem Kunden zu erlauben, für einen Kunden nach Wasserfallplanungsprinzipien zu bezahlen.
Nun, ich habe morgen mein erstes Kundenmeeting und bin ziemlich nervös, wie ich es zu ihnen bringen soll. Ich wünschte, es gäbe mehr Ressourcen für diesen Teil der agilen Methoden.
Google für die 5 Ebenen der agilen Planung, das ist der allgemeine Rahmen, der die längerfristige Planung unterstützt und oft verwendet werden kann, um Budgetprognosen voranzutreiben und Ihnen/dem Kunden zu helfen zu verstehen, warum ein fester Umfang bei agilen Projekten nicht funktioniert.
Sprint Story Point aus PM-Perspektive
AntwortenHierDatenschutz-Bestimmungen1y, 0v