Verwenden von agilen Tabellenkalkulationen für die Discovery-Schätzung

Dieser Artikel enthält eine vorformatierte Tabelle, die Ihnen bei der Entwicklung von Agile-Discovery-Schätzungen hilft. Es enthält auch Informationen, die Ihnen helfen, dem vorgestellten Beispiel zu folgen. Sie können hier eine bearbeitbare Kopie (Datei > Kopie erstellen oder Datei > Herunterladen) von der Vorlage erstellen.

Kunden bitten mich oft, Agile-Schätzungen bereitzustellen, bevor ich ein Team eingerichtet habe oder die MVP-Anforderungen kenne. In diesem frühen Stadium habe ich keinen Zugriff auf traditionelle Metriken wie Geschwindigkeit, Anzahl der Sprints oder Teamkosten, um diese Schätzungen zu berechnen. Aber Kunden wollen Antworten. Können sie ein hypothetisches Produkt in zwei oder sechs Monaten auf den Markt bringen? Wird es für ihr (normalerweise niedriges) Budget machbar sein?

Geben Sie die Agile-Tabelle ein.

Tabellenkalkulationen sind eine passende – aber oft übersehene – Wahl für eine agile Denkweise. Sie sind Low-Tech-, High-Touch-Tools, die die Zusammenarbeit fördern. Allerdings ist es Ihrem Kunden wahrscheinlich egal, ob Ihre Tools „für Agile geeignet“ sind, solange die Kosten und die Qualität des Produkts seinen Anforderungen entsprechen. Der wahre Wert von Tabellenkalkulationen liegt in ihrer Zugänglichkeit für Projektmanager und Stakeholder aller Erfahrungsstufen.

Viele spezialisierte Projektmanagement-Tools haben Lernkurven, die für unerfahrene Benutzer bei schnelllebigen Projekten zu steil sind. Je einfacher es also für Kunden, Produktbesitzer und Entwickler ist, Anforderungen und Arbeitskosten zu aktualisieren, desto eher erhalten Sie eine realistische Schätzung. Mit einer vorformatierten Tabelle können Projektmanager Werte und Parameter anpassen, um die Auswirkungen jeder schwankenden Ressource oder sich verschiebenden Zeitachse zu demonstrieren.

Tabellenkalkulationen sind auch eine großartige Möglichkeit, Wissen mit Ihren Kollegen zu teilen. Die Tabelle, die ich verwende, stammt von einem Toptal-Kollegen, und ich habe seitdem eine Kopie erstellt und sie an meine Bedürfnisse angepasst. Ich ermutige Sie, dies auch zu tun.

In diesem Artikel zeige ich, wie man erfolgreiche Discovery-Schätzungen liefert, die es Kunden und Stakeholdern ermöglichen, sich an den Projektzielen auszurichten und mit der Entwicklung fortzufahren. So füllen Sie die Lücken aus und liefern eine frühzeitige Schätzung, hinter der Sie stehen können.

Nehmen Sie zuerst die Produktvision und die Roadmap in Angriff

Angenommen, Ihr Kunde möchte eine Dating-Website mit einem festen Budget entwickeln, aber die Details des Produkts sind unscharf. Ohne die Teamkosten und -geschwindigkeit zu kennen, ist die Produktvision der beste Ausgangspunkt, da sie von den Beteiligten verlangt, sich auf ein Designziel zu einigen, und die Transparenz im gesamten Team fördert.

Ich mag das Produktvisionsformat von Scrum.org wegen seines intuitiven Erzählstils. So sieht es aus:

Sobald die Produktvision festgelegt ist, können Sie die Produkt-Roadmap in einer neuen Registerkarte der Tabellenkalkulation hinzufügen, um dem Kunden einen Eindruck vom langfristigen Projektplan zu vermitteln. Die Roadmap sollte Ziele, Schlüsselfunktionen und Fristen für jede Produkt-Roadmap-Version auflisten.

Roadmap-Versionen sind geplante, verbraucher- oder kundenorientierte Editionen eines Produkts, die seine Marktentwicklung steuern. Die erste Roadmap-Version ist das Produkt, das Sie auf den Markt bringen können. Nachfolgende Roadmap-Versionen stellen Markteinführungen mit überzeugenden neuen Funktionen dar, die mit der Produktvision übereinstimmen.

Um Microsoft als Beispiel zu nehmen: Windows 8 war wahrscheinlich eine Roadmap-Version. Windows 10 war eine weitere Roadmap-Version, die viele neue und wünschenswerte Funktionen enthielt.

Sobald die Produktvision und die Roadmap fertig sind, ist es an der Zeit, den Kunden zu bitten, sich zu einem MVP zu verpflichten.

Verhandeln Sie MVP-Features mit dem Triple-Constraint-Diagramm

Dies ist der Moment, um die Erwartungen Ihres Kunden in Bezug auf Zeit und Kosten mithilfe des Triple Constraint-Diagramms zu gestalten:

Bei einem Wasserfallansatz diktieren festgelegte Funktionen Zeit und Kosten, und die Entwicklung erfolgt gemäß einem detaillierten Projektplan. Umgekehrt bestimmen die Fixkosten und der Zeitplan von Agile die Funktionen des Produkts, und diese Funktionen werden basierend auf der flexibleren Projektvision ständig neu priorisiert.

Das Triple-Constraint-Diagramm zeigt dem Kunden, dass die Integration aller gewünschten Funktionen in die erste Version die Entwicklungszeit und die Ballonkosten erhöhen wird. Arbeiten Sie stattdessen mit dem Kunden zusammen, um nur „must-have“-Features für ein MVP auszuwählen und alle verbleibenden Features für zukünftige Versionen aufzulisten.

Tabellenkalkulationen erleichtern die Gruppierung und Neuzuweisung von Funktionen zu verschiedenen Versionen, Releases und Prioritäten basierend auf den sich ändernden Anforderungen des Kunden, und sie zeigen sofort die Kosten dieser Änderungen an.

Bitten Sie beim Identifizieren von MVP-Funktionen Ihre Fachexperten (KMU) um Hilfe bei der Auflistung der Projektschritte auf der Grundlage ähnlicher Projekte, an denen sie gearbeitet haben. Sie werden diese Schritte verwenden, um später Epics zu erstellen. Sobald Sie diese Eingaben bereit haben, können Sie mit der Erstellung einer Schätzung beginnen.

Beginnen Sie mit der T-Shirt-Größenbestimmung

Um mit dem ersten Backlog zu beginnen, bitten Sie den Product Owner um eine detaillierte Beschreibung der Produktmerkmale und weisen Sie dann jedem Merkmal basierend auf seinem Schwierigkeitsgrad eine T-Shirt-Größe zu.

Die T-Shirt-Größe zeigt die relative Komplexität und Dauer jeder Entwicklungsaufgabe, bevor Sie irgendwelche absoluten Werte haben. Im weiteren Verlauf der Projektplanung werden wir diese relativen Größen in Story Points und Arbeitsstunden umwandeln.

Wenn Ihr Kunde beispielsweise möchte, dass Sie eine Reihe von Pop-ups auf der Dating-Site entwickeln, wäre das zeitaufwändig, aber unkompliziert. Sie könnten diese Aufgabenkomplexität als „klein“ charakterisieren, aber der Aufwand wäre ein „mittel“. Sie könnten dies mit „SM“ abkürzen. Andererseits wäre die Entwicklung einer Backend-Verbindung für eine neue API aufgrund der gesamten erforderlichen Dokumentation und Tests eine komplexere Aufgabe. Die dafür erforderliche Fähigkeit und Aufmerksamkeit könnte es sowohl in Bezug auf den Aufwand als auch auf das Fähigkeitsniveau zu einem „Großen“ machen: „LL“.

Sobald Sie mit der T-Shirt-Größenbestimmung fertig sind, haben Sie ein Gefühl für die relative Arbeitsbelastung und die Qualifikationsanforderungen für jedes zukünftige Teammitglied. Ein technischer Experte des Entwicklungsteams kann Ihnen dann helfen, Ihre T-Shirt-Größe mit Stundenbereichen und Story Points in Beziehung zu setzen.

Stellen Sie Ihre Parameter ein

Jetzt können Sie mit Ihrer Tabelle arbeiten und Ihre Schätzung berechnen. Beginnen Sie mit dem Erstellen einer Parameter-Registerkarte. Dies dient als Schlüssel für Ihre Berechnungen, und die Werte, die Sie hier eingeben, fließen in die Formeln ein, die in Ihren Registerkarten „Backlog/User Stories“ und „Estimate Summary by Release“ verwendet werden.

Hier ist alles, was Sie in Ihrem Parameter-Tab benötigen:

Währung. Hier geben Sie Währungsumrechnungen ein. Wenn das Budget des Kunden beispielsweise in brasilianischen Real angegeben ist, können Sie den aktuellen Umrechnungskurs für Dollar oder Euro eingeben.

Anfangsdatum. Das voraussichtliche Startdatum der Entwicklung wird verwendet, um einen Projektzeitplan zu erstellen. In jedem Beispiel ist unser Startdatum der 25. Oktober.

Anfangsbudget. Das Budget enthält Einschränkungen, die zeigen, ob alle MVP-Funktionen darin Platz finden oder nicht.

T-Shirt-Größe. Geben Sie Ihre T-Shirt-Größen als Tabelle ein und weisen Sie jeder Größenkombination Story Points und eine Reihe von Stunden zu. In diesem Beispiel verwenden wir ein bis zwei Stunden für ein SS und 33 bis 48 Stunden für ein LL.

Denken Sie daran, dass Ihre Sprintdauer die Stunden Ihrer maximalen T-Shirt-Größe begrenzt. Wenn der Sprint nur eine Woche dauert, darf die größte Größe 40 Stunden nicht überschreiten. Deshalb ist es so wichtig, bei der Zuordnung von T-Shirt-Größen zu Aufgaben ein KMU zu konsultieren .

Preise pro Stunde. Verwenden Sie diese Tabelle, um die Gehaltssätze für jede Rolle zu dokumentieren. Wenn Ihre Back-End-Entwickler unterschiedliche Raten haben, verwenden Sie den Durchschnitt der beiden.

Overhead. Ordnen Sie administrativen Aufgaben wie Statusmeetings, Feedbackgesprächen und Projektüberarbeitungen einen Prozentsatz des gesamten Projektaufwands zu. Zehn Prozent (oder vier Stunden der Arbeitswoche jedes Teilnehmers) sind ein guter Ausgangspunkt, aber bei komplexeren Projekten kann der Overhead höher sein.

Kontingenz. Dies gibt die potenzielle Abweichung in Ihrer Schätzung an. Beginnend mit einer Kontingenz von 0 % werden Ihnen das günstigste (d. h. unwahrscheinliche) Budget und der Zeitplan angezeigt, wenn Sie die Werte berücksichtigen, die Sie in die Tabelle eingegeben haben. Später in unserem Beispiel erhöhen wir die Kontingenz auf eine ungefähre Varianz der Größenordnung (ROM) von 50 %, um die potenzielle Obergrenze der Kosten und der Projektdauer aufzuzeigen. Die Kontingenz wird kleiner, wenn Sie genauere Zahlen erhalten.

Größe jeder Veröffentlichung mit Epics

Wir beginnen mit einer groben Dimensionierung des gesamten Produkts, um sicherzustellen, dass wir weder Zeit noch Geld des Kunden verschwenden. Je nachdem, wie nahe die Dimensionierung dem vorgeschlagenen Budget und der Frist kommt, kann der Kunde entscheiden, das Projekt abzubrechen oder in detailliertere Schätzungen zu investieren. Da wir an dieser Stelle nicht viele Details haben, tragen wir die wichtigsten Features als Epics in den Tab Backlog/User Stories ein. Dann geben wir für jedes Epos die Anzahl der Stunden ein, die die KMUs und Entwicklungsleiter für jeden Entwicklungsstapel basierend auf der T-Shirt-Größentabelle auf der Registerkarte Parameter vorgeschlagen haben.

Wählen Sie zunächst die Spalte „EPIC?“ aus. und stellen Sie sicher, dass nur „Epic“ ausgewählt ist.

Schreiben Sie als Nächstes die Epic-Beschreibung aus und geben Sie die Anzahl der Stunden für jede Spalte des Entwicklungsstapels ein. Das epische „Sichere Verbindung und Anmeldung“ wird beispielsweise etwa acht Stunden für die UI-Entwicklung, 40 für das Backend und so weiter dauern.

Beachten Sie, dass die Zellen in der Spalte „Punkt“ in den meisten Fällen „34*“ anzeigen. Wenn Sie zur Registerkarte Parameter zurückkehren, sehen Sie, dass 34 Punkte einem stündlichen Bereich zwischen 33 und 48 Stunden entsprechen. Diese Stundenzahl ist zu groß, wenn unsere Sprintdauer nur eine Woche beträgt.

Sobald wir mehr Details haben, müssen diese Stunden verkürzt oder die Epen in überschaubarere Geschichten aufgeteilt werden. Aus Zeitgründen ignorieren wir jedoch die Punkte-Spalte und fahren mit der groben Schätzung fort.

Wechseln Sie nun zur Registerkarte Schätzungszusammenfassung nach Release. Oben in der Tabelle sehen Sie die Werte „Overhead“ und „Contingency“, wie auf der Registerkarte „Parameter“ definiert. Es gibt auch eine Schaltfläche, die Sie auswählen können, um Schätzungen nach Epics oder User Stories anzuzeigen.

Da wir noch keine User Stories zum Anzeigen haben, aktivieren Sie die Schaltfläche für „Epischer Modus“.

Sie können jetzt die ungefähren Kosten und Zeitpläne für das MVP und die weniger dringenden Funktionen und Updates in zukünftigen Versionen (R3 und R4) sehen. In diesem Beispiel ist die zweite Version (R2) leer, da der Kunde angefordert hat, dass alle MVP-Epics in der ersten Version gestartet werden.

Sie können jetzt die optimistischsten Gesamtkosten sehen: 28.810 $. Diese Zahl ist die Summe der Kosten für jede Version von MVP bis R4.

Wir haben auch eine Schätzung des kürzesten Zeitrahmens für die Produktlieferung, der dem spätesten Fertigstellungsdatum im R4-Entwicklungsstapel entspricht. Projektmanager nennen diese langsameren Entwicklungsstacks „kritische Pfade“, weil sie die Geschwindigkeit der gesamten Veröffentlichung bestimmen.

Der kritische Pfad ist in diesem Fall die Frontend-Entwicklung mit Fertigstellungstermin 31. Januar.

Jetzt ist es an der Zeit, die Parameter anzupassen, um das Worst-Case-Budget und den längsten Zeitplan zu simulieren.

Stellen Sie die Kontingenz auf 50 % ein

Wir wissen immer noch relativ wenig über die Anforderungen an Aufwand und Know-how für das Produkt, daher fügen wir im Parameter-Tab eine ROM-Kontingenz von 50 % hinzu. Die Wahrscheinlichkeit wird sich verringern, wenn wir mehr Details über das Projekt erfahren.

Auch hier ist die Gesamtprojektschätzung bei 0 % Kontingenz.

Und hier ist es bei 50% Kontingenz.

Das bedeutet, dass die ROM-Schätzung für das gesamte Projekt zwischen 28.810 und 41.860 US-Dollar liegt. Im besten wie im schlimmsten Fall reicht das Budget des Kunden von 20.000 US-Dollar nicht aus, um alle Funktionen auf seiner Wunschliste aufzunehmen.

Das Fertigstellungsdatum des vollständigen Projekts bei 50 % Kontingent fällt nun auf den 14. März, sechs Wochen später als das Fertigstellungsdatum bei 0 % Kontingent.

In der Zwischenzeit wird das MVP am 10. Januar fertig sein.

Anstatt das Projekt aufzugeben, fordert der Kunde eine detailliertere Schätzung an, um zu sehen, ob es in einem kürzeren Zeitrahmen näher an seinem Zielbudget landen könnte.

Priorisieren Sie neu, um Fristen einzuhalten

Angenommen, der Kunde legt als Zieldatum den 25. Dezember für das MVP fest, zwei Monate nach dem Kickoff am 25. Oktober.

Um das aktuelle MVP-Fertigstellungsdatum am 10. Januar vorzuziehen, stimmte der Kunde zu, zwei MVP-Epics auf die nächste Veröffentlichung (R2) zu verschieben.

Die Tabelle berechnet den Kaskadeneffekt dieser Anpassung. In diesem Fall verkürzt sich die MVP-Zeitachse auf den 27. Dezember. Die Front- und Back-End-Entwicklung sind die kritischen Pfade in dieser Simulation, da sie am längsten dauern werden.

Basierend auf diesen Informationen entscheiden Sie sich möglicherweise, zwei weitere Entwickler hinzuzufügen, um die Front- und Back-End-Fertigstellungstermine mit den anderen Entwicklungsstapeln abzustimmen. Erhöhen Sie dazu in der MVP-Zeile „Stunden pro Woche“ die Stunden von 40 auf 80.

Sowohl die Front- als auch die Back-End-Entwicklungsstacks werden jetzt im November abgeschlossen, und QA wird zum neuen kritischen Pfad (mit einem Abschlussdatum am 20. Dezember). Beachten Sie, dass sich die Kosten nicht ändern. Das liegt daran, dass die Gesamtarbeitszeit in jedem Stapel gleich bleibt. Statt dass ein Entwickler zwei Wochen (80 Stunden) arbeitet, arbeiten zwei Entwickler eine Woche (80 Stunden).

Die Tabelle berücksichtigt auch Unterschiede zwischen Vollzeit- und Teilzeitbeschäftigung. Nehmen wir an, der UI-Entwickler arbeitet Teilzeit. Wir können die UI „Entwurfsstunden pro Woche“ auf 20 ändern, um die Lieferverzögerung zu simulieren.

Bei einem Vollzeitplan wird UX/UI am 29. November abgeschlossen sein.

Bei einem Teilzeitplan wird UX/UI am 27. Dezember abgeschlossen sein.

Auch hier ändern sich die Kosten nicht, aber UX/UI wird zum neuen kritischen Pfad, wodurch der Zeitplan für das MVP bis zum 27. Dezember verlängert wird.

Sie können diesen Trial-and-Error-Ansatz fortsetzen, bis Sie angesichts Ihrer Ressourcen und der Deadline des Kunden einen akzeptablen kritischen Pfad erreicht haben. Sobald eine angemessene Frist festgelegt ist, ist es an der Zeit, mit der Feinabstimmung Ihrer Schätzung zu beginnen.

Verfeinern Sie Ihre Schätzung mit User Stories

Da die 50 %-Notfallschätzung außerhalb des Budgets des Kunden lag, lohnt es sich, Ihre Variablen zu verfeinern, damit Sie die Eventualität verringern und eine realistischere Schätzung erhalten können.

Arbeiten Sie dazu mit Ihren Entwicklern und KMUs zusammen, um Ihre Epics in detaillierte User Stories aufzuteilen. Geschichten sind besser definiert als Epen, sodass wir sie genauer dimensionieren können.

Passen Sie als Nächstes die Werte auf Ihrer Registerkarte Parameter basierend auf neuen Informationen an. Beispielsweise verfügen Ihre KMUs und Ihr Entwicklungsteam möglicherweise über genauere Tarife für jede Rolle und möchten möglicherweise auch T-Shirt-Größen und Punktezuweisungen anpassen. Mit diesen neuen Parametern haben Sie mehr Vertrauen in Ihre Berechnungen und können die Wahrscheinlichkeit auf 25 % senken.

Sehen wir uns an, wie wir die Epics in kleinere und detailliertere User Stories aufgeteilt haben:

Im Gegensatz zur epischen Schätzung, bei der die geschätzten Stunden für jeden Stapel manuell eingegeben werden mussten, verwendet die Story-Schätzung die T-Shirt-Größe als Abkürzung. Hier sind die T-Shirt-Größen hilfreich, die Sie auf der Registerkarte Parameter eingegeben haben.

Geben Sie unter „T-Shirt-Größe“ auf der Registerkarte „Backlog/User Storys“ die Größenkombination ein, die Ihre Entwickler und KMUs ihren Stacks für jede Story zugewiesen haben. Von dort aus füllt die Tabellenkalkulationsformel automatisch die entsprechenden Stunden aus der Registerkarte Parameter aus. Denken Sie daran, dass die größte Größe, LL, unter 34 Punkten bleiben muss, um sicherzustellen, dass sie innerhalb der vereinbarten Sprintdauer abgeschlossen werden kann. Alle Geschichten, die immer noch 34 Punkte oder höher bewerten, müssen unterteilt werden.

Wenn Sie sichergestellt haben, dass allen Storys weniger als 34 Punkte zugewiesen wurden, deaktivieren Sie die Schaltfläche „Epischer Modus“ auf der Registerkarte „Estimate Summary by Release“, um nur „Story“ anzuzeigen.

Jetzt sehen Sie eine neue Reihe von Zahlen:

Nachdem alle Aufgaben detailliert beschrieben und nur die MVP-Funktionen eingehalten wurden, stimmen Zeitleiste und Kosten jetzt mit den Anforderungen des Kunden überein. Da das Guthaben innerhalb seines Budgets liegt, entscheidet sich der Kunde, mit dem MVP fortzufahren und es zu testen, bevor er sich zu weiteren Releases verpflichtet.

Mach es zu deinem

Tabellenkalkulationen sind einfach zu verwenden und mit einigen Grundkenntnissen in Formeln (keine Makros erforderlich) können Sie sie an fast jeden Bedarf anpassen. Wenn Ihre Excel-Kenntnisse eingerostet sind, helfen Ihnen Online-Kurse auf Udemy und edX, diese Fähigkeiten aufzufrischen.

In diesem Artikel wurde die Entdeckungsschätzung behandelt, aber Sie können dieselbe Tabelle verwenden, um Burnup-/Burndown-Diagramme zu erstellen, Zeitachsen anzupassen und Schätzungen basierend auf Geschwindigkeit und Sprints für spätere Phasen zu berechnen. Ich verwende meine angepassten Tabellenkalkulationen, um Anwendungen wie Jira, Asana und Trello zu ergänzen, und behaupte, dass sie ein leistungsstarkes Tool in meinem Projektmanagement-Kit sind. Ich hoffe, sie erweisen sich für Sie als ebenso nützlich und vielseitig.

Bevorzugen Sie benutzerdefinierte Tabellenkalkulationen gegenüber handelsüblichen Projektmanagement-Tools? Sagen Sie uns warum oder warum nicht in den Kommentaren.