Das Team schätzt die Story-Punkte, das Geschäft möchte die tatsächliche Zeit

Ich bin sicher, dass dies kein ungewöhnliches Thema ist. Wir haben zwei Scrum-Teams, die das Abschätzen von User Stories mithilfe von Story Points in Ordnung bringen (die aktuellen Team-Konstellationen sind nur etwa 8 Monate alt, obwohl die Teammitglieder über mehrjährige Scrum-Erfahrung verfügen). Für den Geschäftsbereich des Unternehmens ist es jedoch schwierig, sich auf User Stories zu beziehen. Sie möchten tatsächliche Zeiteinheiten (oder "eine Formel zum Umwandeln von Story-Punkten in Stunden"), damit sie einen Plan erstellen können, wann die Dinge fertig sind ( "wir müssen wissen, bis wann wir den Kunden mitteilen können, dass Feature X in Produktion sein wird " ).

Ich und meine Scrum-Master-Vorgänger haben natürlich erklärt, dass "es keine eindeutige Beziehung zwischen Story-Punkten und tatsächlicher Zeit gibt" und dass "Story-Punkte verwendet werden, um zu bestimmen, wie viel das Team in einen Sprint passen kann", und ich Sie können sich sicher vorstellen, wie zufrieden sie mit dieser Antwort waren. Sie möchten in der Kalenderzeit immer noch wissen, wann wir die 27. User Story im Backlog erreichen.

Auf jeden Fall habe ich einige Statistiken erstellt, und unsere SP-Schätzungen führen zu völlig unterschiedlichen Ergebnissen in Bezug auf die tatsächlich aufgewendete Zeit (gemessen mit unserer Scrum-Board-Software, die protokolliert, wie viel Zeit Tickets in der Spalte "Arbeiten an" ausgeben ). Für 1-SP-User-Stories gibt es natürlich eine starke Tendenz zu sehr kurzen Zeitspannen (mit gelegentlichem Aufblähen), aber besonders für 2-SP-Stories sind sie weit verbreitet: Es gibt einen Faktor von 20 zwischen den "schnellsten" und "langsamsten" Abschlüssen. Für 3, 5 und 8-SP-Storys ist der Spread auch mehr als ein Faktor von 2.

Dies weist darauf hin, dass (a) das Team bei der Schätzung von User Storys mit (wie sollte) ähnlicher Komplexität wesentlich konsistenter sein muss und (b) die Genauigkeit der Zeitberichterstattung verbessern muss (dh daran denken, Tickets aus dem System zu verschieben) "Arbeiten", wenn sie in einer Besprechung sind, beim Mittagessen oder beim Tischfußball spielen).

Ich habe vor, sowohl (a) als auch (b) zu verbessern, aber ich bin der Meinung, dass dies nicht ausreicht, da das Unternehmen "mehr Konkretheit" erwartet, als diese Initiativen bringen werden.

Was sind einige gute Strategien, um die Geschäftsseite zu beschwichtigen , damit sie sich nicht zu sehr in unsere Arbeitsweise einmischt (z. B. durch die Einführung einer separaten Zeiterfassung, was meiner Meinung nach dumm wäre, weil es auf jeden Fall weniger genau wäre als das aktuelle "automatische" Tracking), während sie gleichzeitig ein gewisses Maß an Konkretheit darüber erlangen können, wann Geschichten geschrieben werden?

(In der Vergangenheit haben wir während der Planung User Stories in Arbeitselemente zerlegt, die dann individuell in der tatsächlichen Arbeitszeit geschätzt wurden. Ich spreche hier jedoch von User Stories im Hintergrundprotokoll, die nicht so detailliert oder unvollständig sind -Nieder.)

Update: Mein Manager hatte die Vermutung, dass es eine Art Glockenkurvenverteilung von Stunden pro Story-Punkt gab, aber die Daten, die ich zusammenstellte, und die Grafiken, die er erstellte, ließen ihn von dieser Vorstellung völlig unberührt. :-)

Sie haben Recht, es gibt keine Formel, um Story Points in Stunden umzuwandeln. Sie können eine ziemlich verlustfreie Umrechnung von Metern in Fuß und umgekehrt erzielen, aber Sie können nicht sagen, dass eine 3-Punkte-Story X Stunden dauert, sodass eine 5-Punkte-Story Y Stunden dauert (für Y lösen).

HorusKol ging auf diesen nächsten Teil ein. Ihre Sprintgeschwindigkeit als Team kann Ihnen bei den längerfristigen Ergebnissen helfen. Angenommen, Ihr Team hat 50 Punkte pro Sprint und jeder Sprint dauert 2 Wochen. Also 50 Punkte pro Sprint multipliziert mit 50 Wochen pro Jahr (vorausgesetzt, die Leute haben 2 Wochen Urlaub), dann kann Ihr aktuelles Team maximal 2.500 Punkte in 12 Monaten erzielen.

Das Geschäft wartet also mit Geschichten und Epen im Wert von 170 Punkten auf. Teilen Sie dies durch die historische Geschwindigkeit des Teams von 50 Punkten (Durchschnitt aller bisherigen Sprints) und Sie erhalten 3,4 Sprints. Da wir eine Schätzung durchführen, runden Sie diese auf 4 Sprints ab: 8 Wochen. Im Grunde genommen zwei Monate. Ich nehme auch gerne die letzten 3-4 Sprints und nehme eine andere Schätzung. Angenommen, Ihr Team hat in den letzten drei Sprints 53, 67 bzw. 55 Punkte erzielt. Das ergibt 58 Punkte, was 2,9 Sprints entspricht - also im Grunde 3 Sprints. Ihre Zeitleiste für diese 170 Punkte sieht nach 6 bis 8 Wochen aus.

Sagen Sie das Geschäft 2 Monate. Sagen Sie ihnen nicht 6-8 Wochen, weil sie nur "6 Wochen" hören werden. Sagen Sie ihnen nicht einmal 8 Wochen, denn die meisten Monate haben ungefähr 4,5 Wochen, und wenn die Leute "4 Wochen" hören, denken sie sofort "1 Monat". Sobald eine Schätzung ungefähr 4 Wochen erreicht, wird es 1 Monat. Dann arbeiten Sie einfach in Monaten. Wenn Sie ein Jahr oder mehr schlagen, dann schätzen Sie diese Arbeit ehrlich gesagt einfach nicht ein. Es hat keinen Sinn. In einem Jahr kann sich zu viel ändern.

Ich habe festgestellt, dass dies eine ziemlich genaue Methode ist, um Story Points in Stunden umzuwandeln ... na ja, auf jeden Fall.

Sie werden eine Abweichung in der Zeit bekommen, die es dauert, einzelne Geschichten zu vervollständigen. Einige Entwickler arbeiten schneller als andere. Wenn Sie alle Story Points in eine Schüssel geben und den Mixer einschalten, um mit Durchschnittswerten zu arbeiten, können Sie diese Inkonsistenzen beseitigen.

Oh, und vergessen Sie nicht den wichtigsten Teil:

Zusammenfassen. Immer.

Wahrscheinlich haben Sie bereits einige inhärente Umrechnungen von Story-Punkten in Zeitschätzungen vorgenommen. Wie stellen Sie fest, dass Sie genug Arbeit für Ihren Sprint ausgewählt haben? Sie haben wahrscheinlich etwas gesagt wie "das Team kann 20 (oder 40 oder was auch immer) Punkte pro Woche verarbeiten". Nach ein paar Sprints sollten Sie in der Lage sein, dies nach Abschluss zu korrigieren - jetzt sind es 15 oder 25 (oder 35 oder 50 oder ...) Punkte für einen Sprint - dies ist die Geschwindigkeit Ihres Teams .

Für 1-SP-User-Stories gibt es natürlich eine starke Tendenz zu sehr kurzen Zeitspannen (mit gelegentlichem Aufblähen), aber besonders für 2-SP-Stories sind sie weit verbreitet: Es gibt einen Faktor von 20 zwischen den "schnellsten" und "langsamsten" Abschlüssen. Für 3, 5 und 8-SP-Storys ist der Spread auch mehr als ein Faktor von 2.

Eine gewisse Variation der Zeit zum Abschließen bestimmter Geschichten ist innerhalb der Punktewerte in Ordnung. Die Geschwindigkeit berücksichtigt diese Unsicherheit, indem sie einen Durchschnitt der jüngsten Geschichte darstellt.

Möglicherweise müssen Sie sich jedoch genau ansehen, wie Sie Punkte zuweisen, insbesondere bei 2-Zeigern, wenn Sie eine so große Schwankung feststellen. Übergeordnete Aufgaben sollten unsicher sein (und aufgeschlüsselt werden), aber Aufgaben, die so klein wie ein 2-Zeiger sind, sollten ziemlich konsistent sein.

Da alle Aufgaben, denen derselbe Punktewert zugewiesen wurde, einen ähnlichen Aufwand erfordern sollten, ist es nicht sinnvoll, eine solche Zeitspanne zu definieren.

Schauen Sie sich also den 2-Zeiger an, der in Ihrer Retrospektive am längsten gedauert hat. Warum hat sich aus etwas, das wahrscheinlich einen Morgen hätte nehmen sollen, eine 10-Tage-Parodie entwickelt? Konnte an diesem ersten Morgen etwas angekündigt worden sein, das besagt, dass dies episch werden und in kleinere Aufgaben aufgeteilt werden muss? Sobald dies geschieht, sollte natürlich die zusätzliche Arbeit in den Rückstand gesteckt werden und den Rest des Sprints nicht beeinträchtigen.

Versuchen Sie auch herauszufinden, wie das Team diesen Artikel unterschätzt hat. Können Sie künftige Artikel besser bewerten, wenn Sie ihn überprüft haben?

Ja, der Liefertermin wird entsprechend verschoben, oder die Liste der Funktionen für ein Update kann überarbeitet werden, sodass die Lieferung nicht beeinträchtigt wird. Ziel ist es jedoch, zukünftige Punktschätzungen zu verbessern und einen genaueren Zeitplan zu erhalten.

Es ist wie bei der Wettervorhersage: Je weiter entfernt, desto weniger zuverlässig. Das ist eine Analogie, die jeder verstehen würde. Fehler in Schätzungen summieren sich.

Der Vertrieb muss lernen, Scrum-konform mit den Kunden zu sprechen. Für sich genommen macht Scrum keinen Sinn, es soll vertikal im gesamten Unternehmen angewendet werden und erstreckt sich vorzugsweise bis in den Kundenbereich.

Sie als Entwicklerteam sollten diesbezüglich fest sein. Sie können ihnen Erwartungen und Vermutungen geben, aber nicht zulassen, dass Verpflichtungen einen einzelnen Sprint verlängern.

Ich mache ein paar Dinge, wenn ich solche Fragen bekomme.

Zunächst beantworte ich Fragen zur Zukunft, indem ich die Vergangenheit beschreibe. Ich würde sagen, dass wir ungefähr zwei dieser Geschichten pro Woche durchstehen. Wenn sich also nichts ändert, werden wir voraussichtlich in ungefähr 14 Wochen mit Story 27 fertig sein.

Zweitens möchte ich, dass die Kunden die Verantwortung für den Handel zwischen Zeitplan und Risiko übernehmen. Ich würde so etwas sagen: Denken Sie daran, das Engineering-Team arbeitet auf der Grundlage von 50/50 Schätzungen. Wenn sich nichts ändert, besteht eine 50/50 Chance, dass Feature 27 in 14 Wochen fertig ist. Vermutlich möchten Sie einem Kunden nichts mit diesem Risikograd melden. Möchten Sie, dass ich eine Schätzung erarbeite, auf die wir beispielsweise zu 90% vertrauen? Dann müssten Sie Ihre historischen Beweise überprüfen und Folgendes sagen: Die Wahrscheinlichkeit, dass Story 27 in 25 Wochen fertig ist, liegt bei 90% .

Erinnern Sie Ihren Kollegen zum Schluss daran, dass das Unternehmen, sobald er eine externe Verpflichtung eingegangen ist, fixiert ist. Externe Versprechungen zu Story Nummer 27 beeinträchtigen die Agilität des Unternehmens. Sie wären dann einer bestimmten Vorgehensweise verpflichtet. Wann immer jemand mit einer Änderungsanforderung zu Ihnen kommt, müssen Sie jetzt antworten. Wir haben uns verpflichtet, Story 27 vor dem x-Datum zu beenden. Ich kann diese Änderung nur vornehmen, wenn Sie den Kunden kontaktieren und ihm mitteilen, dass unsere Verpflichtung nicht mehr gültig ist. Grundsätzlich ist es mit vielen Problemen verbunden, bestimmte Verpflichtungen für Arbeiten einzugehen, die länger als etwa einen Monat in der Zukunft liegen.

Sie haben bereits eine (sehr grobe) Umstellung:
Scrum-Sprints dauern (in der Regel) zwei Wochen.
Sie wissen, dass Sie in diesen zwei Wochen Features im Wert von etwa 20 Story Points fertig stellen können (oder wie bestimmen Sie sonst, welche und wie viele Features in einen einzelnen Sprint gepackt werden?), Und Ihre vorherigen Sprints bestätigen diese Schätzung (sagen wir mal) Sie haben in den letzten fünf Sprints 18, 21, 23, 19 und 20 Story Points erreicht.

Angenommen, Feature X (und all seine Abhängigkeiten) wurden auf 47 Story-Punkte geschätzt.
Sie können also abschätzen, dass Sie, wenn Sie die Implementierung auf höchste Priorität setzen, ungefähr 3 Sprints, dh 6 Wochen, ausführen sollten (aber stellen Sie sicher, dass Ihre Schätzungen berücksichtigen, wer was tun kann - wenn 35 dieser Punkte DB-Arbeit sind und Sie nur haben Bei DB müssen Sie Ihre geschätzte Geschwindigkeit ändern, um dies zu berücksichtigen.

Das heißt - fest zu kommunizieren, dass dies grobe Schätzungen sind - es gibt einen Grund, warum Sprints zwei Wochen und nicht sechs sind. Je mehr Dinge Ihre Prognose abdecken muss, desto mehr Unsicherheit und Fehler treten auf. Kommunizieren Sie auch die Kosten fest - dh, dies würde bedeuten, dass die Aufgabe an oberster Stelle steht und keine anderen Aufgaben bearbeitet werden. Andernfalls könnten Sie in das Szenario laufen:

"Wann wird Feature Y fertig sein?"
"Wenn wir uns das nächste Mal darauf konzentrieren ... 12 Wochen"
" 12 Wochen?!? Sie sagten, es würde 4 dauern."
"Ja, aber Sie haben uns gesagt , dass wir Feature X priorisieren sollen. Wir haben Ihnen mitgeteilt , dass wir alle Ressourcen binden und 8 Wochen brauchen würden."
"Können Sie nicht gleichzeitig an Feature X und Feature Y arbeiten?"
" stöhnen "

Sprint ist definierte Zeit, sagen wir 2 Wochen. Sie können nicht vorhersagen, dass eine Story länger als zwei Sprints dauern wird, so wie Sie Ihren aktuellen Sprint und den nächsten Sprint haben. Ich gehe davon aus, dass Sie Geschichten vorbereitet haben, die mit dem Team für den nächsten Sprint besprochen werden und von der Wirtschaft priorisiert wurden. Das Beste, was Sie mit Sicherheit sagen können, sind die nächsten 4 Wochen Arbeit.

Alles, was länger als 4 Wochen dauert, kann sich ändern und Unternehmen können eine Roadmap erstellen, die nicht in Stunden festgelegt ist. Das sollte pro Sprint geplant werden, sagen wir mal epic1 (epic wie in jira bunch of grouped stories) und epic2 sollte in sprint 47 und 48 und epic3 sollte in sprint 49 gemacht werden Mal sehen, ob einer oder zwei in einen Sprint passen, die Zeitleiste wird trotzdem verrutschen. Wenn Funktionen nicht funktionieren, muss das Unternehmen den Umfang reduzieren oder nicht perfekte Lösungen akzeptieren, die später bei Bedarf verbessert werden können (das sollte agil sein, die Realität einbeziehen, anstatt den Plan zu befolgen).

Sie können ein schönes Gantt-Diagramm (so läuft das Geschäft) mit zukünftigen Sprints und Hauptthemen / -epics für diese erstellen.

Ich mag es, jeden Sprint zu veröffentlichen und dann bereite ich die Veröffentlichung mit dem vor, was im Sprint fertig war (oder Sachen, die für die Veröffentlichung durch das Geschäft unterschrieben wurden, obwohl sie nicht perfekt waren). Unfertige Sachen gehen zum nächsten Sprint. Auf diese Weise habe ich eine vorhersehbare Lieferung in ungefähr 2-3 Wochen (eine Woche für eventuelle Korrekturen am Release Candidate).

Das ist meine Erfahrung mit kleinen Teams, wenigen externen Abhängigkeiten und dem, was ich für vernünftig halte. Ihre Laufleistung kann variieren.

Für neue Funktionen ist es nahezu unmöglich, die erforderliche Zeit zu schätzen.

Die Erfahrung mit der Softwareentwicklung zeigt, dass es in den meisten Fällen Details gibt, die Sie nicht sehen können, bevor Sie mit der Entwicklung beginnen. Im besten Fall benötigen diese Teile zusätzliche Zeit, aber im schlimmsten Fall kann das Projekt auch scheitern. Der Grund dafür ist die Komplexität der Softwareentwicklung.

Aus diesem Grund schätzt SCRUM nur die Komplexität des Problems (Story Points), nicht aber die Zeit. Die einzige Chance, die Sie haben, besteht darin, Features mit hoher Komplexität in kleinere zu unterteilen. Auf diese Weise können Sie das Risiko minimieren.

Da eine Zeitschätzung nahezu unmöglich ist, gibt es keine Formel, mit der Story Points in Zeitschätzungen umgewandelt werden. Die Geschwindigkeit kann nur eine sehr grobe Schätzung sein, nicht mehr.

In SCRUM kann der Product Owner die Prioritäten der Backlog-Elemente vor jedem Sprint ändern. Daher kann der SCRUM-Master für mehr als einen Sprint keine Schätzungen abgeben. Er weiß nicht, welcher Rückstand im nächsten Sprint wichtig werden könnte.

SCRUM ist keine Methode, um Unmögliches zu tun (Unplanbares planen) oder die Entwicklung zu beschleunigen. Es ist ein Frühwarnsystem, wenn die Entwicklungszeit knapp wird. So kann schnell auf neue Anforderungen reagiert werden.

Zum ersten Beitrag:

Sie sind bereits sehr gut darin, die meisten Ihrer Aufgaben in 1 bis 5 SP-Storys aufzuteilen. Die Geschwindigkeitsschätzungen werden möglicherweise besser, wenn die Aufgaben ähnlich sind und Ihr Team mehr Erfahrung hat. Aber wenn es immer neue, unbekannte Teile in neuen Gegenständen gibt, muss man mit der Ungenauigkeit leben.

Da Ihre Entwickler normalerweise einige Zeit mit nicht entwicklungsbezogenen Arbeiten (z. B. Besprechungen) verbringen, sollten Sie nicht 8 Stunden für jeden Tag einplanen, sondern weniger, z. B. 6 Stunden. Dann erhalten Sie eine Reserve für andere Aufgaben oder für Arbeitselemente, die mehr Zeit in Anspruch nehmen.

Wenn Ihre Geschäftskollegen genaue Schätzungen wünschen (was an sich ein Widerspruch ist), erklären Sie ihnen die inhärenten Probleme der Softwareentwicklung. Dann zeigen Sie ihnen die Vorteile agiler Methoden.