Ungenaue Schätzungen gehören zu den häufigsten Problemen im Projektmanagement. Wenn Sie ein neues IT-Projekt beginnen, wollen Sie zwei Dinge wissen: wie lange es dauern und wie viel es kosten wird. Um diese Fragen zu beantworten, müssen Sie die Projekte, die Sie durchführen wollen, schätzen. Es gibt keine magische Regel, die besagt, dass Projekt X 12 Wochen dauert und $150.000 kostet. Oder dass die Entwicklung einer Website wie Y 10 Wochen dauert und $100.000 kostet.
Was Sie aus diesem Artikel lernen werden:
- Wie bereiten sich die Projektmanager auf die Kostenschätzung im Projektmanagement vor?
- Welche Schätzungstechniken sind für die Projektschätzung nützlich?
- Wie sieht die Planung aus, um sich auf eine Kostenschätzung mit Formeln vorzubereiten?
Ohne eine gründliche Schätzung können Sie weder den Zeitplan noch die Kosten eines Projekts abschätzen, selbst wenn der Umfang des Projekts sehr ähnlich zu dem ist, was Sie bisher gemacht haben. Aber es kommt noch schlimmer: Eine Schätzung wird Ihnen auch auf diese Fragen niemals eine 100% genaue Antwort geben. Warum machen wir also Schätzungen? Weil dies die einzige Möglichkeit ist, Annahmen über den Zeitplan und das Budget des Projekts, den Arbeitsaufwand und die erforderlichen Ressourcen für die Durchführung des Projekts zu treffen.
Durch die Schätzung des Projekts sind Sie auch in der Lage, Mitarbeiter mit der richtigen Erfahrung und Kompetenz einzuplanen. Was Sie dagegen tun können, ist, Methoden und Techniken zu verwenden, die es Ihnen ermöglichen, Ihre Schätzungen so genau wie möglich vorzunehmen. Im Folgenden erfahren Sie, wie Sie mit der Agile-Methode und der Planning-Poker-Technik aussagekräftige Schätzungen für Ihr Projekt erstellen können.
James Grenning entwickelte 2002 den für seine Strategie bekannten Planungspoker namens Scrum-Poker. In den frühen 1950er Jahren war seine Schätzmethode, Wide band Delphi, zu zeitaufwändig und hatte andere Einschränkungen. In Grennings Fall ging es bei dem Pokerplan ursprünglich darum, ein Problem zu lösen, bei dem die Spieler zu begeistert und übermäßig fokussiert waren, um zu gewinnen. Mike Cohn, der Begründer von Agile Alliances und Scrum Alliances, verwendete diese Technik später für einen Artikel mit dem Titel Agile Estimation and Planning.
Der Erfolg eines Projekts hängt vor allem davon ab, wie gut man versteht, worum es eigentlich geht. Das schließt ein:
- Verstehen der Erwartungen Ihres Kunden
- Verstehen der Ziele des Projekts und des Hauptziels
- Erstellen einer Liste der erforderlichen Merkmale
Sobald Sie das Briefing des Kunden durchgelesen haben und so viele Informationen wie möglich über die Projektanforderungen haben, können Sie alle Funktionen auflisten und sie an Ihr Team weitergeben.
Erstellen Sie dazu ein Product Backlog, das alle zu erledigenden Funktionen enthält. Anschließend können Sie sie nach Prioritäten ordnen, ihre Komplexität bewerten und abschätzen, wie lange es dauern wird, sie fertigzustellen. Ein gutes Product Backlog sollte aus folgenden Punkten bestehen:
- Benutzergeschichten - beschreiben die Aktionen, die die Benutzer bei jedem Schritt der Produktverwendung ausführen können
- Akzeptanzkriterien - Auflistung der Elemente, die für die Fertigstellung einer Geschichte erforderlich sind
- Story Points - Schätzung des Arbeitsaufwands, der Risiken und der Komplexität in relativen Punktwerten
- Aufgaben für Benutzergeschichten - Liste der Aufgaben, die für die Erstellung einer Benutzergeschichte erforderlich sind
Es ist von entscheidender Bedeutung, das Entwicklungsteam in die Erstellung und Priorisierung des Product Backlogs einzubeziehen, um eine genaue und realistische Einschätzung zu gewährleisten.
Wenn Sie eine Liste von Merkmalen erstellt haben, ordnen Sie jedem dieser Merkmale eine Priorität zu. Sie können die MoSCoW-Analysemethode verwenden, um sie zu sortieren:
- Muss haben
- Hätte
- Hätte
- Wird nicht haben
Konzentrieren Sie sich bei der Entwicklung eines Projekts auf die Dinge, die Sie in erster Linie liefern müssen. Die Erstellung eines MVP gibt Ihnen die Möglichkeit, Hypothesen über Ihre Idee zu testen, bevor Sie das gesamte Projekt abschließen, es Stakeholdern oder Betanutzern zu zeigen und Feedback zu sammeln, das für die weitere Entwicklung der restlichen Funktionen wichtig ist.
Die Zuweisung von Prioritäten kann Ihnen auch bei der Schätzung des Projekts helfen. Wenn Sie sich auf die wichtigsten und zuerst zu erledigenden Funktionen konzentrieren, können Sie genauere Annahmen über deren voraussichtliche Fertigstellung machen. Für "mögliche" Funktionen können Sie mit einer groben Schätzung beginnen, da sie sich weiter im Entwicklungsprozess befinden und sich bis zu dem Zeitpunkt, an dem Ihr Team sie erreicht, noch viel ändern kann (und wenn Ihr Team sie erreicht, da Sie nach dem Sammeln von Feedback zu Ihrem MVP umschwenken und nicht alle ursprünglich geplanten Funktionen einbeziehen können).
Es ist jedoch wichtig, alle Funktionen unabhängig von ihrer Priorität zu schätzen (mit Ausnahme derjenigen, die nicht benötigt werden), da Sie sich einen Überblick über das gesamte Projekt verschaffen wollen. In den nächsten Phasen des Projekts können Sie den Arbeitsumfang neu bewerten, um sicherzustellen, dass Ihre Schätzungen korrekt bleiben.
Nun, da Sie Ihr Product Backlog fertiggestellt haben, ist es an der Zeit, jedes einzelne Element zu schätzen. Zu diesem Zweck verwenden wir Story Points. Dabei handelt es sich um Einheiten, die agile Teams verwenden, um die Arbeit zu bewerten, die für die Fertigstellung der einzelnen Elemente des Backlogs erforderlich ist. Story Points helfen dabei, den Elementen des Product Backlogs einen relativen Wert zuzuweisen. Sie sind nicht zeitabhängig und können für verschiedene Teams unterschiedliche Werte haben, so dass sie keinen emotionalen Wert haben. Daher ist es wahrscheinlich, dass die Teammitglieder die Schätzungen nicht aufpolstern, nur um sicherzugehen. Planning Poker hilft Software-Teams bei der Planung von Arbeitsabläufen und der Verbesserung der Projektabwicklung.
Anhand von Story Points kann ein Team Schätzungen vornehmen:
Die Planungssitzung ist eine der Techniken zur Schätzung auf Bruttoebene, die eine modifizierte Version der Fibonacci-Folge verwendet: 1, 2, 3, 5, 8, 13, 20, 40, 100. Zur Schätzung der Positionen des Produktrückstandes erhalten die Teammitglieder die gleichen Sets von Planungspokerkarten mit Zahlen darauf. Nach einer kurzen Vorstellung des Product Backlog Items durch den Product Owner (der nicht abstimmt) und der Diskussion ziehen sie privat die Karte mit der Anzahl der Story Points, die sie für den Arbeitsaufwand zur Fertigstellung dieses Items für relevant halten, und decken sie gleichzeitig auf.
Wenn die Zahlen voneinander abweichen, diskutieren die Teammitglieder, warum sie sich für eine solche Anzahl von Story Points entschieden haben, und stimmen dann erneut ab. Dies ist Teil des Planungspokers, einer konsensbasierten Schätzungsmethode, die in Agile verwendet wird, um den Aufwand für User Stories zu schätzen. Sie tun dies so lange, bis sie einen Konsens erreicht haben, und gehen dann zum nächsten Punkt des Product Backlogs über. Wenn die vereinbarte Zahl hoch ist, sagen wir 20, 40 oder höher, bedeutet dies, dass eine Story möglicherweise zu viel Arbeit für einen Sprint erfordert und in kleinere Aufgaben aufgeteilt werden muss. Idealerweise sollten die Präsentation des Themas, die Diskussion und die Abstimmung etwa zwei Minuten dauern, was eine Schätzung des gesamten Backlogs in einer kurzen Zeitspanne ermöglicht. Da es hier aber darum geht, das gesamte Backlog auf einmal zu schätzen, sollten Sie sich Zeit lassen und sich nicht wundern, wenn einige Stories etwas länger brauchen, um bewertet zu werden.
Die Team-Velocity zeigt Ihnen, wie schnell die Projektentwicklung verläuft. Sie hilft dabei, zwei Dinge zu verstehen:
- Wie viel Arbeit Ihr Team in einem Sprint erledigen kann
- Wann wird der gesamte Geltungsbereich voraussichtlich abgeschlossen sein, vorausgesetzt, er ist festgelegt?
Die Geschwindigkeit ist bei jedem Team anders. Sie können sie nach den ersten Iterationen bewerten, wenn Ihr Team bereits an einigen Funktionen gearbeitet hat. Wenn Sie beispielsweise in der ersten Iteration vier Product-Backlog-Elemente mit einer Gesamtzahl von 20 Story-Points aufgenommen haben und das Team drei davon fertiggestellt hat, was 15 Story-Points entspricht, ist dies die aktuelle Velocity Ihres Teams. Denken Sie daran, dass nur abgeschlossene Elemente zählen. Selbst wenn das vierte Element zwar begonnen, aber noch nicht fertiggestellt wurde, zählt es nicht.
Der Scrum Master spielt eine entscheidende Rolle bei der Erleichterung des Schätzungsprozesses und der Sicherstellung genauer Bewertungen während dieser Sitzungen.
Nach dem Aushandeln der Story Points und der Bewertung der Team-Velocity können Sie den Zeitplan für das Projekt bestimmen. Dazu addieren Sie die Teamgeschwindigkeit der letzten drei Iterationen und teilen sie durch drei. Wenn die Geschwindigkeit in diesen Iterationen beispielsweise 20, 23 und 17 betrug, würde die durchschnittliche Geschwindigkeit etwa 20 Punkten entsprechen. Wenn der Gesamtarbeitsaufwand auf 100 Story Points geschätzt wurde, würde es bei einer durchschnittlichen Geschwindigkeit von 20 Punkten 5 Iterationen dauern, um das Projekt abzuschließen. Unter der Annahme, dass eine Iteration zwei Wochen dauert, sollten Sie das Projekt in 10 Wochen abschließen.
Um das Budget für Ihr Projekt zu ermitteln, können Sie diese Grundformel verwenden: (Gesamtzahl der Story Points / Geschwindigkeit * Teamstunden pro Sprint) + Nicht-Lohnkosten = geschätztes Budget. Wenn Sie die Gesamtzahl der Story Points durch die durchschnittliche Geschwindigkeit dividieren, multiplizieren Sie die Anzahl der Sprints mit 40 Wochenstunden pro Teammitglied, um Ihre Arbeitskosten zu erhalten. Dann addieren Sie die Lohnnebenkosten wie Kapitalkosten, Ausrüstungskosten, Wartungskosten, Schulungskosten usw. Ein Beispiel: Wir haben ein Projekt mit geschätzten 100 Story Points und die durchschnittliche Geschwindigkeit unseres Teams beträgt 20. Wenn wir dem Projekt ein 5-köpfiges Team mit Stundensätzen von $50 zuweisen, sind die Teamstunden pro Sprint $20.000 und $100.000 für 5 Sprints wert. Bei hypothetischen Lohnnebenkosten von $50.000 würde sich das geschätzte Budget für unser Projekt auf $150.000 belaufen. Unter Berücksichtigung der Konfidenzintervalle für beispielhafte Werte von 80-120% beträgt die angegebene Spanne unseres Budgets nun $120.000 bis $180.000.
Denken Sie daran, dass keine Schätzung 100% genau ist. Es ist am besten, Ihr Projekt alle paar Iterationen neu zu schätzen, da sich Dinge wie die Verfügbarkeit von Ressourcen, die Geschwindigkeit des Teams oder der Projektumfang im Laufe der Zeit ändern können. Durch die Neuschätzung stellen Sie sicher, dass Ihre Schätzung auf dem neuesten Stand ist. Die Verwendung von Zeiterfassungs- und Ressourcenplanungssoftware hilft Ihnen außerdem, die Verfügbarkeit Ihres Teams zu verwalten und es bei Bedarf neu zuzuweisen. Mit den richtigen Techniken und Tools können Sie Ihre Schätzungen zuverlässiger machen und Ihr nächstes Projekt besser planen.
Eine genaue Projektschätzung ist entscheidend für ein erfolgreiches Projektmanagement. Durch das Verständnis der Erwartungen und Ziele, die Erstellung eines detaillierten Product Backlogs, die Priorisierung von Funktionen und den Einsatz von Techniken wie Story Points und Planning Poker können Sie die Genauigkeit Ihrer Schätzungen verbessern. Regelmäßige Neuschätzungen und der Einsatz von Tools zur Zeiterfassung und zum Ressourcenmanagement erhöhen die Zuverlässigkeit Ihrer Projektzeitpläne und -budgets zusätzlich. Wenn Sie diese Praktiken befolgen, können Sie die Herausforderungen ungenauer Schätzungen überwinden und bessere Projektergebnisse sicherstellen.
Verwenden Sie die Planning Poker Schätztechnik mit Leichtigkeit
Prüfen Sie, warum unsere Ressourcenmanagement-Software von Projektmanagern von Hill-Knowlton oder Stormind Games gewählt wird
Eine effektive Ressourcenplanung ist für Unternehmen aller Größenordnungen von entscheidender Bedeutung, unabhängig davon, ob sie online oder in traditionellen Branchen tätig sind. Angesichts der großen Vielfalt an Unternehmen, die eine Ressourcenplanung benötigen, ist es schwierig, eine pauschale Empfehlung zu geben...
Unternehmen geben sich in der Regel viel Mühe bei der Ressourcenzuweisung. Sie wollen alle Mitarbeiter beschäftigen und gleichzeitig sicherstellen, dass ihre Aufgaben für das Unternehmen wertvoll sind (was oft bedeutet, dass sie in Rechnung gestellt werden können). Richtig knifflig wird es, wenn Ihr Team...
Teams auf der ganzen Welt stehen vor ähnlichen Herausforderungen, wenn es darum geht, den Zeitplan für ihr Team zu planen. Die Erstellung eines Projektplans ist an sich schon schwierig, und ihn auf dem neuesten Stand zu halten und auf Änderungen zu reagieren, ist noch...