Wenn wir ein neues Projekt oder Produkt in einem agilen Umfeld planen, akzeptieren wir, dass zu diesem Zeitpunkt noch nicht alle Anforderungen bekannt sind, dass sich Annahmen ändern, neue Anforderungen entstehen und einige durch das frühe Einbeziehen von User-Feedback nicht mehr relevant sind.
Müssen wir also unser Projekt beginnen, ohne die geringste Ahnung zu haben, wie viel es kosten und wie lange es dauern wird? Wie können Unternehmen Investitionsentscheidungen wie "Soll ich diese Software herstellen oder kaufen?" oder "Wird sich die Investition rentieren" treffen? Könnte dies der Grund dafür sein, dass einige große Unternehmen immer noch Schwierigkeiten haben, "wirklich" agil zu arbeiten?
Bei Ambient Innovation glauben wir, dass es keinen Widerspruch darstellt, ein Budget zu definieren und agil zu arbeiten.
Wie also können wir vorgehen?
Wir schätzen den Aufwand für die zu diesem Zeitpunkt bekannten Anforderungen und nehmen diese Schätzung als Budget für das Projekt. Dann bauen wir mit dem uns zur Verfügung stehenden Budget das bestmögliche Produkt. Das Ergebnis wird höchstwahrscheinlich nicht alle Anforderungen umfassen, die wir ursprünglich geschätzt haben, und das ist in Ordnung. Wir wollen nicht das Produkt bauen, das wir ursprünglich benötigten. Stattdessen wollen wir frühzeitiges User-Feedback einfließen lassen und das Produkt entwickeln, das den Bedürfnissen der Benutzer am besten entspricht (Denke daran: "Wir schätzen die Reaktion auf Änderungen mehr als das Befolgen eines Plans" ;)). Dennoch ist es wichtig, einen ersten Plan zu erstellen und ein Budget zu definieren, auf dem Entscheidungen basieren können und an dem während der Implementierung gemessen werden kann.
Grundsätze agiler Schätzungen
Keep it simple, stupid!
Wie können wir also den Bedarf abschätzen und zu diesem Budget gelangen? Aus der Zeit vor der Agilität haben wir gelernt, dass die Erstellung eines detaillierten Lastenheftes einen immensen Zeitaufwand erfordert. Und dass die meisten spezifizierten Anforderungen nicht in der angenommenen Art und Weise umgesetzt werden (Weil die Anforderung auf Annahmen statt auf Benutzer-Feedback basiert). Mit anderen Worten: Wir wollen die Anforderungen zumindest grob abschätzen, ohne sie allzu detailliert zu spezifizieren.
In unseren Scrum-Backlog-Refinements versuchen wir, die Product Backlog Items "ready to pull" für einen der nächsten Sprints zu kriegen. Wir spezifizieren sie also im Detail, aber nur diejenigen, die mit einer sehr hohen Wahrscheinlichkeit umgesetzt werden. Genau diese Technik können wir nicht verwenden, weil es für alle Anforderungen zu viel Zeit in Anspruch nimmt, aber wir können einige der Prinzipien kopieren, die für diese Schätztechnik gut funktionieren:
- Die Meinungen mehrerer Personen einholen
- Unvoreingenommen schätzen (Aus diesem Grund führen wir in Refinements die erste Runde des Planning Pokers vor der eigentlichen Diskussion durch)
- Diejenigen, die die Anforderungen umsetzen werden, sollten diejenigen sein, die schätzen.
Wie können wir also diese Prinzipien auf eine große Anzahl von Product Backlog Items anwenden, ohne zu viel Zeit zu investieren?
Die "Magic Estimation"-Methode
Entwickler und Product Owner unbedingt gemeinsam schätzen lassen!
Die Antwort ist eine Methode namens Magic Estimation.
Organisieren Sie einen Workshop und laden Sie die zukünftigen Entwickler und den zukünftigen Product Owner ein. Es ist aus zwei Gründen lohnenswert, den Product Owner in diesem Workshop zu haben: Erstens kann er oder sie Fragen zu den Anforderungen beantworten und dem Team einen Eindruck von seinem Qualitätsanspruch vermitteln. Zweitens wird er oder sie sich aktiv an der Schätzung beteiligen und somit viel mehr Buy-in haben. Der Product Owner wird die genannten Diskussionen und Komplexitätstreiber hautnah miterleben und ein Gefühl für das Team bekommen.
Der Zeitrahmen für diesen Workshop hängt von mehreren Faktoren ab: Wie gut sind die Anforderungen bereits formuliert? Wie viele Anforderungen gibt es? Kennen sich das Entwicklungsteam und der Product Owner schon? Ich empfehle für den Anfang einen Zeitrahmen von 4 Stunden.
Halten Sie sich während des Workshops an diesen Plan:
Phase 1: Schätzung aller Product Backlog Items auf einer relativen Skala
- Notieren Sie jede Ihrer Anforderungen auf einer Karte oder einem Post-It. Natürlich können Sie dies auch auf einem Online-Whiteboard wie miro tun. Ich empfehle, die bekannte Vorlage "User Story" zu verwenden, um die Anforderungen zu erfassen und sie auf einer User Story-Map anzuordnen, aber die Form der Anforderungen und wie Sie sie bewertet haben, lassen wir aus dem Rahmen dieses Artikels heraus.
- Zeichnen Sie 4-6 horizontale Flächen mit Komplexitätskategorien auf Ihrem Whiteboard und beschriften Sie sie mit einer relativen Skala. Sie können Story Points verwenden (Ich empfehle dies zu tun, wenn das Team bereits Erfahrung mit der Schätzung in Story Points hat.) oder einfach T-Shirt-Größen wie XS, S, M, L, XL.
- Teilen Sie die Product Backlog Items zwischen den Workshop-Teilnehmern gleichmäßig und zufällig auf, z.B. "jeder Teilnehmer erhält zufällig 5 Post-Its".
- Jeder Teilnehmer platziert seine Product Backlog Items innerhalb der Kategorien, ohne zu schauen, was die anderen tun. Dies kann auch ohne viel technische Erfahrung geschehen. Sie sollten nicht den Zeitaufwand für die Implementierung des PBI bedenken, sondern diese relativ zueinander abschätzen. Stellen Sie sich die Frage "Ist dieses PBI eine der eher einfachen Anforderungen an dieses Produkt (ordnen Sie es in die Kategorie XS oder S ein) oder eine der komplexesten (ordnen Sie es in die Kategorie L oder XL ein). Denken Sie daran, dass die Triebkräfte für die Schätzung die Komplexität (Weiß ich genau, wie man das macht, oder habe ich es schon einmal gemacht?), die Quantität (Muss ich das an vielen Stellen machen?) und die Unsicherheit (Wie sicher bin ich mir über die Details dieser Anforderung?) sind.
- Nachdem jeder Teilnehmer/jede Teilnehmerin seine/ihre Anforderungen gestellt hat und alle Post-Its auf der Tafel sind, nehmen Sie sich etwas Zeit und schauen Sie alle durch (auch Ihre eigenen). Sind die Anforderungen in einer Kategorie etwa gleich komplex, oder fallen einige davon auf? Sind sie komplexer als die in einer niedrigeren Kategorie? Sind sie weniger komplex als die in der nächsthöheren Kategorie? Wenn Sie der Meinung sind, dass eine Anforderung besser in eine höhere Kategorie eingestuft werden sollte, kleben Sie einen Punkt an den unteren Rand des Haftzettels. Wenn Sie der Meinung sind, dass eine Anforderung eher in eine niedrigere Kategorie eingestuft werden sollte, kleben Sie einen Punkt an den oberen Rand. Wenn Sie der Meinung sind, dass sie genau richtig ist, brauchen Sie keinen Punkt zu kleben.
- Besprechen Sie die Anforderungen mit Punkten darauf. Lassen Sie jemanden argumentieren, warum die Anforderung richtig ist, so wie sie ist. Lassen Sie dann jemanden, der einen Punkt gesetzt hat, erklären, warum sie geändert werden sollte. Wenn es in der Gruppe keine klare Tendenz gibt, können Sie abstimmen. Wenn Sie sich dafür entschieden haben, ändern Sie den Haftzettel in die höhere oder niedrigere Kategorie und entfernen Sie die Punkte.
- Wiederholen Sie die beiden vorherigen Schritte, bis keine Punkte mehr platziert sind. Alle Teilnehmer sollten mit den Komplexitätskategorien einverstanden sein.
Phase 2: Umwandlung der relativen Skala in ein Gesamtbudget
Jetzt haben Sie also jedes Product Backlog Item einer Komplexitätskategorie mit einer relativen Skala wie Story Points oder T-Shirt-Größen zugeordnet. Später in der Implementierungsphase des Projekts empfehle ich, nicht zu versuchen, dies in Entwicklungstage oder Geld für jedes Ticket zu übersetzen (Stattdessen verwende ich lieber Burnup-Charts zur Kontrolle und um zu sehen, wie viel Arbeit in jedem Sprint erledigt werden kann.). Wenn Sie jedoch ein absolutes Anfangsbudget für Ihr Projekt veranschlagen müssen, sollten Sie Entwicklungszeit und Geld verwenden. Es gibt zwei Möglichkeiten, dies zu tun:
- Wenn Sie bereits Story Points für die Komplexitätskategorien verwendet haben und die Geschwindigkeit Ihres Teams kennen (Wie viele Story-Punkte das Team im Durchschnitt in einem Sprint absolviert.), ist es ziemlich einfach: Teilen Sie die geschätzten Story Points durch die Geschwindigkeit und Sie wissen, wie viele Sprints Sie benötigen. Bitte bedenken Sie, dass dies nur funktioniert, wenn das Team, das die Schätzung vorgenommen hat, auch die Umsetzung übernimmt (was auf jeden Fall eine gute Sache ist).
- Wenn Sie nicht sicherstellen können, dass das Team, das die Schätzung vorgenommen hat, auch die Umsetzung durchführt, oder wenn das Team seine Geschwindigkeit nicht kennt (z.B. wenn es sich um ein neues Team handelt), müssen Sie noch einen Schritt weitergehen. In diesem Fall bitte ich das Team, eine "niedrige" und "hohe" Anzahl von Tagen zu schätzen, die es für die Implementierung eines Items in jeder Kategorie benötigen wird. Aus den oben genannten Gründen (keine Voreingenommenheit, mehr Kreativität) machen wir dies normalerweise mit "Planning Poker". Nachdem dies erledigt ist, können Sie die geschätzten Tage in jeder Kategorie und insgesamt multiplizieren. Wenn Sie können, verwenden Sie auch Referenzen aus früheren Projekten: Wie lange dauerte eine ähnliche Funktion im letzten Projekt?
Nun sind wir am Ziel:
Jetzt haben Sie eine Schätzung, wie viele Tage oder Sprints Sie benötigen werden, um alle Product Backlog Items zu implementieren und damit die Kosten für das Projekt. Zugegeben, es ist eine grobe Schätzung, aber in meinen Augen ist es ein guter Kompromiss aus investierter Zeit und Schätzgenauigkeit.
"Ja, agile und fixe Budgets passen zusammen! Methoden wie „Magic Estimation“ helfen dabei sich auf das Wesentliche zu konzentrieren und alle Stakeholder mit einzubinden."
Worauf muss man achten?
- Wenn Sie eine höhere Genauigkeit benötigen (und bereit sind, etwas mehr Zeit zu investieren), empfehle ich Ihnen, sich die Tickets in den höchsten Komplexitätskategorien (wie L und XL) anzusehen. Was sind die Treiber für ihre hohe Wertschätzung? Wenn es viele Unsicherheiten gibt, sollten Sie vielleicht einen kleinen Prototyp bauen oder Forschung betreiben. Wenn sie sehr komplex sind, sollten Sie vielleicht nach einer alternativen Lösung oder einer Drittbibliothek suchen.
- Die meisten Backlogs wachsen im Laufe der Zeit, weil sich aus dem Feedback der Benutzer neue Anforderungen ergeben, z.B. in Sprint-Reviews. Während andere Anforderungen obsolet werden, zeigt die Erfahrung, dass die meisten Backlogs wachsen. Möglicherweise sollten Sie bei Ihrer Budgetplanung einen gewissen Spielraum einplanen.
- Natürlich ist das veranschlagte Budget kein "take it or leave it"-Vorschlag. Brauchen Sie wirklich alle Funktionen? Können Sie vielleicht einige der teuren Funktionen entbehren, um alternative Lösungen zu finden? Können Sie Ihr Produkt in mehrere kleine Versionen aufteilen? Eine "User Story Map" ist ein sehr gutes Werkzeug für die Release-Planung.
- Normalerweise schreibe ich ein Product Backlog Item für "Vorarbeiten" oder füge einen absoluten "Sprint 0" zur Gesamtschätzung hinzu. In einer perfekten Welt sollte all dies in den Schätzungen der Anforderungen enthalten sein, und Vorarbeit sollte nur dann geleistet werden, wenn ein Feature dies erfordert. Meiner Erfahrung nach gibt es jedoch in der Regel De-facto-Grundarbeiten, und die ersten Features brauchen länger, um entwickelt zu werden, daher ist es hilfreich, dies zu berücksichtigen.
- Mit Ausnahme des "Sprint 0" empfehle ich, alles, was für den Aufbau eines Features erforderlich ist (Konzeption, UX, Design, Implementierung, Test, Bereitstellung), in Ihre Schätzung einzubeziehen und keine separaten Elemente dafür zu erstellen. Es ist ratsam, benutzerzentrierte Anforderungen und nicht technische Schritte in Product Backlog Items zu beschreiben (die User Story-Vorlage hilft dabei). Sie müssen dies berücksichtigen, wenn Sie die Tage pro Komplexitätskategorie schätzen: Wenn sich die Entwickler nur vorstellen, den Code zu schreiben, schätzen Sie vermutlich zu niedrig.
Ich hoffe, dieser Artikel hat einen Einblick in unseren aktuellen Prozess zur Schätzung vermittelt und freue mich über Feedback aller Art.
Wer lieber schaut, als liest, für den haben wir den Inhalt als Video aufbereitet:
Video Release Burn Up Chart
Zusammenfassung
Im agilen Umfeld akzeptieren wir die Unwägbarkeiten und Änderungen während der Projektplanung. Bei Ambient Innovation glauben wir, dass agile Arbeit und Budgetierung Hand in Hand gehen können. Ein erster Schritt besteht darin, den Aufwand für bekannte Anforderungen zu schätzen und dies als Budget festzulegen. Wir konzentrieren uns darauf, mit diesem Budget das bestmögliche Produkt zu entwickeln, wobei wir frühzeitig auf das Feedback der Benutzer eingehen. Dabei helfen uns agile Schätztechniken wie die "Magic Estimation"-Methode, bei der Entwickler und Product Owner gemeinsam schätzen.
Die Schätzung erfolgt auf einer relativen Skala, ohne zu viel Zeit in detaillierte Anforderungen zu investieren. Die Schätzung wird dann in ein Gesamtbudget umgewandelt, wobei verschiedene Faktoren wie Teamgeschwindigkeit und Komplexität berücksichtigt werden. Diese Methode ermöglicht zwar eine grobe Schätzung, aber sie bietet einen guten Kompromiss zwischen Zeitinvestition und Genauigkeit.
Ihr Projekt erfolgreich umgesetzt
Möchten Sie mehr darüber erfahren, wie Ihre Firma von dieser agilen Budgetierungsmethode profitieren kann? Buchen Sie noch heute einen Beratungstermin mit unseren Expert*Innen, um Ihre individuellen Anforderungen zu besprechen und zu erfahren, wie wir Ihnen helfen können, Ihre Projekte erfolgreich umzusetzen. Lassen Sie uns gemeinsam den Weg zu agiler Arbeit und effektiver Budgetierung erkunden!
Softwareprojekt unverbindlich anfragen!
