Aktueller Arbeitsablauf in unserem Unternehmen:
Ich verstehe, dass die relative Dimensionierung besser funktioniert als die Stundendimensionierung, und deshalb möchte ich zu Story Points übergehen. Aber wie ist es möglich, mithilfe von Story Points eine Budgetschätzung für den Kunden zu erstellen?
Wie kann man das richtige Budget einhalten, aber gleichzeitig Story Points für die Schätzung des Projekts verwenden?
Für agile Projekte lautet eine grundlegende Formel zur Schätzung des Budgets:
(totalStoryPoints / velocity * teamHoursPerSprint) + nonLaborCosts = budgetEstimate
Die Ergebnisse sollten als geschätzter Bereich unter Verwendung statistischer Konfidenzintervalle oder einer "hoch, niedrig, durchschnittlich"-Methode angegeben werden.
Das „Geheimnis“ bei der Schätzung agiler Budgets besteht darin, die Anzahl der Iterationen zu schätzen, die erforderlich sind, um den Rückstand aufzulösen oder einen Release-Meilenstein zu erreichen. Zum Beispiel:
Diese Methode gibt ein vernünftiges Bild des geplanten Budgets und berechnet gleichzeitig den Projektrückstand in Story Points. Diese Methode beruht nicht auf umständlichen oder irreführenden Umrechnungen von Punkten ↔ Stunden .
Angenommen, Sie haben 20 User Stories in Ihrem Backlog und ein Scrum-Team aus 6 Personen, darunter der Scrum Master und der Product Owner. Jede Story wird auf 5 Story Points geschätzt, und Ihre historische Durchschnittsgeschwindigkeit beträgt 10 Story Points pro Sprint.
20 Geschichten zu je 5 Punkten = 100 Geschichtenpunkte
100 StoryPoints / AverageVelocity = 10 Sprints
- Arbeitskosten pro Woche für ein 6-köpfiges Team: 3.200 $
- Arbeitskosten pro Sprint für ein Sechs-Personen-Team: 6.400 $
- Arbeitskosten für das Projekt: 6.400 USD pro Sprint * 10 Sprints = 64.000 USD
- Server und Workstations.
- Softwarelizenzen.
- Monatliche Servicegebühren für die geplante Projektlaufzeit.
- Und so weiter.
104.000 $
- Angemessenes Low-End (80%):
$104k * 0.80 = $83,200- Tatsächlich berechnetes Budget (100 %):
$104k * 1.00 = $104,000- Akzeptables High-End (120 %):
$104k * 1.20 = $124,800
In Ihrem Projektplan geben Sie Ihr berechnetes Budget als Budgetprognose (auch bekannt als Ihr Planungswert), das untere Ende als Ihr „Stretch-Ziel“ und Ihr oberes Ende als den Punkt an, ab dem das Management das Projekt als außerhalb der Toleranz stehend betrachtet. Dies gibt ein vernünftiges Bild der geplanten Kosten und berechnet gleichzeitig den Projektbestand und den Lieferplan aus Story Points.
Ich beginne damit, dass Scrum in einem Beratungsumfeld eine echte Herausforderung ist. Mit Scrum suchen wir ständig nach Feedback vom Product Owner und den Stakeholdern und passen unseren Arbeitsrückstand an, um dies widerzuspiegeln. Dies macht es schwierig, im Voraus eine feste Schätzung abzugeben. Das Ziel von Scrum ist es, den maximalen Geschäftswert zu erreichen, indem das geliefert wird, was der Kunde benötigt. Dies ist nicht immer mit einem festen Umfang vereinbar.
Allerdings ist es möglich, Story Points zu verwenden, um eine Projektschätzung abzugeben. Was Sie tun, ist, das Team Story-Point-Schätzungen für alle Storys im Umfang des Projekts durchführen zu lassen. Dann verwenden Sie die Velocity des Teams, um abzuschätzen, wie viele Sprints es braucht, um das Projekt abzuschließen. Wenn Sie die Kosten pro Sprint kennen, können Sie dann die Projektkosten berechnen.
Bitte beachten Sie, dass es unwahrscheinlich ist, dass Sie für alle außer den kürzesten Projekten eine genaue Projektkostenschätzung erhalten. In der Entwicklung gibt es technische und anforderungsbezogene Unbekannte, die zu Schätzungsfehlern führen, die mit zunehmender Projektdauer zunehmen. Wir nennen dies den „Unsicherheitskegel“, bei dem unsere Gewissheit über die Genauigkeit einer Schätzung mit der Projektdauer abnimmt.
Ein Scrum-Team wird seine Schätzung für ein Projekt oft kontinuierlich überarbeiten. Nach Abschluss jedes Sprints kann das Team seine Geschwindigkeit neu berechnen und den Rückstand (und die Rückstandsschätzungen) überarbeiten. Mit diesem Ansatz werden ihre Schätzungen im Laufe der Zeit besser, aber das nützt nichts, wenn Sie gezwungen sind, eine Schätzung abzugeben, bevor die Arbeit überhaupt begonnen hat.
Ich verwende seit vielen Jahren Story Points und finde, dass sie ein weitaus effektiverer Schätzansatz sind als die Verwendung der absoluten Zeit. Das heißt, Sie müssen ihre Grenzen kennen. Nur weil ein Rückstand besteht, heißt das noch lange nicht, dass ein Team ihn auch mit mäßiger Genauigkeit durchzieht.
Ein Team muss genügend Informationen über eine Geschichte haben, um sie mit etwas in Verbindung zu bringen, das sie in der Vergangenheit getan haben. Einfach nur eine einzeilige Beschreibung einer Story zu haben (als Administrator von System XI muss in der Lage sein ...) liefert einem Team normalerweise nicht genügend Informationen, um die Story zu dimensionieren, es sei denn, es handelt sich um etwas sehr Einfaches.
Backlog Grooming und Sizing ist ein kontinuierlicher Prozess, bei dem das Team, der Product Owner, die Stakeholder usw. das Was und Wie der Story diskutieren. Epen und Geschichten werden aufgeteilt und/oder neue Geschichten hervorgebracht, während die Größen weiter verfeinert werden. Der Punkt ist der Versuch, eine Schätzung auf Projektebene zu erstellen, indem alle Geschichten im Voraus bemessen werden, ist nur eine dünn verschleierte Big Up Front-Planung.
Sie sind viel besser dran, wenn Sie sich Ihren Projektverlauf ansehen und 2 oder 3 Projekte finden, die sich in ihrer Art ähneln, um Ihnen eine Bandbreite an Zeit und Kosten zu geben. Stellen Sie dann fest, ob der Wert, den Sie mit dem Projekt erreichen möchten, kostengerecht ist. Sie können diese Entscheidung weiter validieren, indem Sie eine begrenzte Implementierung einiger Schlüsselelemente über eine Handvoll Sprints durchführen. Das gibt Ihnen echte Informationen, von denen Sie im Gegensatz zu Spekulationen ausgehen können. Zuverlässige Informationen sind nicht kostenlos. Zuverlässigere Informationen erhalten Sie nicht, wenn Sie eine detailliertere Schätzung vornehmen. Zuverlässigere Informationen erhalten Sie, wenn Sie tatsächlich mit der Umsetzung beginnen, was natürlich Geld kostet. Sie können mit diesem Ansatz fortfahren, und wenn Sie zu irgendeinem Zeitpunkt feststellen, dass sich die verbleibende Investition nicht mehr lohnt, beenden Sie das Projekt. Zu viele Unternehmen gehen davon aus, dass ein einmal begonnenes Projekt abgeschlossen werden muss. Projekte zu beenden, wenn sie nicht mehr den notwendigen Wert liefern, ist eine gesunde Sache und sollte als Gewinn und nicht als Misserfolg betrachtet werden. Die meisten Unternehmen gehen davon aus, dass sie den größten Teil des Risikos einplanen können, bevor sie einen Teil der Investition ausgeben. Erraten Sie, was? Das ist einfach nicht die Realität. Es ist, als würde man einen Börsenmakler bitten, einen ROI für eine Aktie zu garantieren, bevor man sie kauft.
Ich verstehe das Dilemma in der Beratungswelt und es ist ein grundlegendes Problem bei der Art und Weise, wie die meisten Unternehmen mit Anbietern/Beratern Geschäfte machen. Auch hier wollen sie eine Garantie für etwas, das extrem schwer vorherzusagen ist, aber Sie sind gezwungen, es zu tun, weil es der einzige Weg ist, das Geschäft zu bekommen. Es ist dysfunktional, weil das Unternehmen, das das Geschäft ausbietet, glaubt, dass es sein Risiko begrenzt hat, indem es den Bieter gezwungen hat, sich auf Preis und Umfang festzulegen. Die Realität ist, dass das Risiko nicht wirklich gemindert wurde. Das Unternehmen, das das Angebot gewinnt, weiß meistens, dass es unterboten hat, und wird versuchen, es auf dem Weg dorthin mit einer Vielzahl verschiedener Methoden wieder gut zu machen. Der Punkt ist, dass das Projekt von Anfang an auf Scheitern ausgelegt ist. Normalerweise gewinnt in dieser Situation keine Seite.
Ewan