Ich bin ein neuer Scrum Master für ein Team, das Story-Point-Schätzungen und -Stunden verwendet. Wir machen Story Points zuerst während der Pflege und dann Stunden während der Planung.
Ich dachte immer, Story Points seien in erster Linie für den Projektmanager und Stunden für die Ingenieure (das war einfach die Art und Weise, wie wir die Dinge gemacht hatten). Ein Kollege und Ingenieur fragte, warum wir beide verwenden.
Während ich Artikel lese wie: Setzen Sie Story Points nicht mit Stunden gleich , was erklärt, warum Sie Story Points nicht mit Stunden verwenden sollten, obwohl sie verwandt sind. Oder Gibt es veröffentlichte Forschungsergebnisse zu Story Points vs. Zeitschätzung? die erklären, dass Story Points genauer für die Schätzung sind.
Ich sehe nicht viel geschrieben über die Verwendung von beiden. Wir schätzen Storys nach Story Points, was uns einen groben Überblick gibt, und dann gehen wir auf die Dauer jeder Aufgabe ein und verwenden die Story Points und Stunden, um uns selbst eine Schätzung zu geben. Ich fange jedoch an, mich zu fragen, ob mein Kollege an etwas dran ist.
Ist die Verwendung von Story Points und Stunden eine Sache? Gibt es einen Rat dafür oder dagegen? Mir ist klar, dass es wahrscheinlich weitere 2 Stunden dauert, um beides zu tun (multipliziert mit jedem Mitglied des Teams), und es kostet viel.
Warum beides verwenden? Hat jemand irgendwelche Erfahrungen damit?
Die Schätzung der Story Points und die Stundenschätzung haben unterschiedliche Zwecke.
Wir verwenden Story Points während des Product Backlog Refinement.
Story Points eignen sich gut für die Planung auf hoher Ebene.
Wenn wir in Story Points eine Schätzung vornehmen, sprechen wir von der Produktivität des gesamten Teams . Bei der High-Level-Planung zählt nur die Produktivität des gesamten Teams.
Die Story Points-Schätzung ist eine relative Messung . Es ist sehr praktisch für die Planung auf hoher Ebene. Wenn das Team seine Produktivität erhöht (z. B. durch die Verwendung von CI), wird das Team im nächsten Sprint einfach mehr SP prognostizieren. Im Fall der Stundenschätzung sollte das Team das gesamte Product Backlog neu schätzen (und die benötigten Stunden reduzieren).
Wir verwenden Stunden während der Sprintplanung.
Stunden sind gut für die Planung auf niedriger Ebene.
Wenn wir eine Schätzung in Stunden machen, sprechen wir von der Produktivität konkreter Entwickler . Es ist unmöglich, SP für Planungsaufgaben bestimmter Entwickler zu verwenden, da (wie ich bereits sagte) SP für relatives Messen sind. Ein Entwickler kann 1 SP in 1 Stunde implementieren, ein anderer kann es in 2 Stunden implementieren.
Die Stundenschätzung ist eine absolute Messung . Es ist sehr praktisch für die Planung auf niedriger Ebene. Sie haben immer 160 Arbeitsstunden in einem Monat und die Produktivität des Teams kann in dieser kurzen Zeit nicht stark steigen oder sinken.
Deshalb schätzen wir die Product Backlog Items in Story Points und Tasks (auf denen wir BPIs zerlegen) in Stunden.
Ist die Verwendung von Story Points und Stunden eine Sache? Gibt es einen Rat dafür oder dagegen? Warum beides verwenden? Hat jemand irgendwelche Erfahrungen damit?
Nehmen wir an, die durchschnittliche Geschwindigkeit Ihres Teams (über die letzten 3 oder mehr Sprints) beträgt 30 Story Points. Nehmen wir an, er hat zwischen 27 und 32 geschwankt. Prognostizieren Sie als Team für den nächsten Sprint 30 Punkte (Durchschnitt), 27 Punkte (konservativ) oder 32 Punkte (optimistisch)? Es gibt keinen objektiven Weg, wie Sie das feststellen können. Sie müssen alle Breakout-Aufgaben und den Urlaub, die Feiertage und so weiter der Teammitglieder berücksichtigen.
In jedem Fall führen Sie während der Sprintplanung eine detailliertere Planung durch, indem Sie detaillierter untersuchen, wie Sie die Geschichte implementieren werden, indem Sie die einzelnen Aufgaben identifizieren. Das Schätzen der Stunden sollte nicht zu viel zusätzlicher Aufwand sein. Es hilft Ihnen, Ihre Sprint-Prognose von Stories auf eine viel solidere Basis zu stellen.
Ich sehe nicht viel geschrieben über die Verwendung von beiden.
Mike Cohns Vergleich mit einem Basketballteam ist wahrscheinlich einfacher zu verstehen: Angenommen, ein Basketballteam befindet sich mitten in seiner Saison. Sie haben in den bisherigen 41 Spielen durchschnittlich 98 Punkte pro Spiel erzielt. Es wäre angemessen, wenn sie sagen würden: „Wir werden wahrscheinlich den Rest der Saison durchschnittlich 98 Punkte pro Spiel erzielen.“ Aber sie sollten nicht vor einem Spiel sagen: „Unser Durchschnitt liegt bei 98, deshalb werden wir heute Abend 98 Tore erzielen.“ Aus diesem Grund sage ich, dass Geschwindigkeit ein nützlicher langfristiger Prädiktor ist, aber kein nützlicher kurzfristiger Prädiktor.
Sie können auch seinen neueren Artikel zu demselben Thema lesen:
Warum Sprints mit Stunden geplant werden sollten, nicht mit Punkten
Beide Artikel haben gute Kommentar-Threads mit weiteren Erläuterungen von Mike.
Es gibt zwei Gründe, warum ich gesehen habe, dass Gruppen sowohl Story Points als auch Stunden verwenden:
1) Jemand kann einfach nicht loslassen. Normalerweise ist dieser jemand ein PM oder Manager und kann sich nicht dazu bringen, die Spezifität der Stunden aufzugeben, unabhängig davon, wie genau sie sein mögen oder nicht. Das ist natürlich kein guter Grund, es ist sogar ein sehr schlechter, aber besser die Dinge beim Namen nennen, als sich selbst darüber zu belügen.
2) Ich habe gesehen, wie Teams Geschichten mit Punkten bewerteten und dann Aufgaben in Stunden schätzten, als eine Art Kontrolle gegen ihre vorherige Schätzung. Dies kann tatsächlich Gespräche darüber auslösen, was in die Erfüllung einer Geschichte einfließt, die das Team sonst möglicherweise nicht führt, insbesondere wenn es seit Jahren Stundenschätzungen durchführt. Zum Beispiel könnte ein Teammitglied sagen „das dauert 2 Stunden“ und ein anderes sagt „ist das mit oder ohne der Zeit, die Sie brauchen werden, um den neuen Server bereitzustellen, auf dem es weitergeht?“ und die erste Person antwortet "Warte, wir brauchen dafür einen neuen Server?!" usw. Gute Gespräche und Mehrwert. Allerdings hätte ich das Ziel, von diesen Stundenschätzungen wegzukommen, sobald das Team diese Diskussionen ohne die Stunden aus zwei Gründen führen kann:
1) Sie haben immer noch das gleiche Problem mit den Stunden, die Sie immer haben. Menschen sind immer noch schlecht darin, Zeit einzuschätzen, Manager werden immer noch versuchen, seltsame Bewertungen von Schätzung zu Ist durchzuführen, und jeder wird eine natürliche Neigung haben, das Team dazu zu bringen, seine Arbeitszeiten zu erfüllen, anstatt Wert zu liefern.
2) Das Hinzufügen von Schätzungen wie dieser verankert Aufgaben. Es erzeugt eine Abneigung dagegen, die Aufgaben zu ändern, sie zu entfernen oder neue Aufgaben hinzuzufügen. Meiner Erfahrung nach sollten Aufgaben ein Werkzeug für das Team sein, um ihre Arbeit so zu organisieren, wie es ihnen am besten hilft, und sollten kein Maßstab sein.
Story Points werden als Maß für die relative Komplexität verwendet und legen im Laufe der Zeit eine Teamgeschwindigkeit fest – eine durchschnittliche Menge an Arbeit, die ein stabiles Scrum-Team während einer festgelegten Iteration leisten kann. Die IMO-Story-Point-Schätzung ist eine Eckpfeiler-Scrum-Praxis, die das Team in die Lage versetzt, seine Iterationsverpflichtungen zu verwalten und zu übernehmen.
Stundenschätzungen werden verwendet, um Diskussionen über einzelne Aufgaben anzuregen, die zum Vervollständigen einer Geschichte erforderlich sind. Sie brauchen Aufgaben? Es hängt von der Reife des Teams ab. Unreife Teams können von Stundenschätzungen profitieren, wenn sie nicht über große Fachkenntnisse verfügen und keine relative Komplexitätsschätzung mit Story Points durchführen können. Die meisten ausgereiften Teams, mit denen ich zusammenarbeite, hören mit der Stundenschätzung auf, weil es viel Zeit in Anspruch nimmt und es auf lange Sicht schwieriger ist, eine genaue Stundenschätzung im Vergleich zur Story-Point-Schätzung und geschwindigkeitsbasierten Planung durchzuführen.
Nebenbemerkung: Ich habe allzu oft gesehen, wie unreife Teams, die sich ausschließlich auf Stundenschätzungen verlassen, sich dem Mikromanagement traditioneller PMs öffnen, die glauben, dass ein Team mit X Stunden Kapazität und Y Stunden Aufgabenschätzungen ihre gesamte Arbeit in einer Iteration erledigen wird wenn X = Y.
Machen Sie also Story Points, Stunden oder beides? Es hängt von der Mannschaft ab. Fragen Sie Ihre Teammitglieder, ob sie Wert in einer der Schätzpraktiken sehen, damit Sie verstehen, was funktioniert, was nicht und in welche Richtung(en) sich Ihr Team verbessern kann.
Story Points und zeitbasierte Schätzungen können in Scrum ergänzend verwendet werden.
Bei Story Points geht es in erster Linie darum, die Kapazität des Sprints zu bestimmen. Sie sehen sich also die Geschwindigkeit Ihres Teams an und verwenden dies als grobe Vorhersage der Kapazität für zukünftige Sprints.
Sobald Sie jedoch Geschichten in Ihre Story-Point-Kapazität geladen haben, ist es manchmal auch nützlich, dann eine zeitbasierte Schätzung vorzunehmen. Die Gründe dafür sind:
Natürlich erhöht die Durchführung sowohl einer zeitbasierten als auch einer Story-Point-Schätzung die Zeit und den Aufwand, die das Team für die Schätzung aufwendet. Ob sich der Mehraufwand lohnt, muss das Team entscheiden.
Sie schätzen die Story anhand von Story Points während des ersten Teils des Sprint-Planungsmeetings – so können Sie schnell bestimmen, wie viele Storys das Team in relativ kurzer Zeit in den Sprint aufnehmen kann
Viele Teams machen das und das war's. Aber wenn Sie den zweiten Teil machen – und die Geschichte in Aufgaben aufteilen – verwenden Sie Stunden für die Aufgaben. Der Sprint-Burndown basiert dann auf den Gesamtstunden aller Aufgaben im Sprint. Der Burndown kann steigen und wird auch steigen - da die zu erledigende Schätzung steigen kann, wenn Sie die Aufgabe besser verstehen.
Zusammenfassend also - Sie verwenden Punkte für die Story - und dann Stunden für die Aufgaben innerhalb der Story.
Persönlich würde ich es vermeiden, Stunden zu verwenden, da es unmöglich ist, genau abzuschätzen, wie lange eine Aufgabe dauern wird. Ich denke, Story Points sind der beste Weg, um Geschichten einzuschätzen, und ich glaube nicht, dass Sie Aufgaben einschätzen müssen, die das Team tun sollte, was auch immer nötig ist, um die Geschichte zu vervollständigen.
Jeff Lindsey
Charlie