· Torsten · 3 min read
Rapid Estimation: In wenigen Minuten zu einer groben Projektschätzung
Du brauchst für dein Projekt früh eine Schätzung, willst aber nicht viel Aufwand hineinstecken. Trotzdem soll sie strukturiert, nachvollziehbar und transparent sein. Genau dafür gibt es die Rapid Estimation Methode.

Du brauchst für dein Projekt früh eine Schätzung, willst aber nicht viel Aufwand hineinstecken. Trotzdem soll sie strukturiert, nachvollziehbar und transparent sein. Genau dafür gibt es die Rapid Estimation Methode. Sie liefert dir ganz am Anfang eine grobe Abschätzung, wenn noch sehr wenig Wissen über das Projekt da ist — und beantwortet damit die zwei wichtigsten Fragen im Projekt: wie lange dauert es und was kostet es.
Was du dafür brauchst
Viel ist es nicht. Du brauchst Papier und einen Taschenrechner, denn wir rechnen ein bisschen. Und du brauchst eine User Story Map. Aber keine Panik, nicht die ganze. Es reicht ein kleiner Teil, eine sogenannte F-Shaped User Story Map.
Die F-Shaped User Story Map
Diese Map ist eine minimale Version einer User Story Map, gerade so groß, dass du damit die Schätzung machen kannst. Sie hat die Form eines F. Auf der obersten Ebene, bei den Initiativen oder Goals, gehst du in die Breite. Du willst wissen, was grundsätzlich im Projekt steckt. Auf der zweiten Ebene schaust du dir nicht mehr alle Epics an, sondern nur die Epics einer einzelnen Initiative. Auch hier achtest du auf Vollständigkeit, ohne jedes Detail zu verstehen. Erst auf der dritten Ebene gehst du für ein einziges Epic in die Tiefe und definierst alle User Stories aus. Diese müssen so gut verstanden sein, dass du sie schätzen kannst.
Wie die Methode rechnet
Du fängst unten an. Die User Stories eines Epics rechnest du zusammen, im Beispiel sind das acht Punkte. Dann legst du eine Referenz fest, also das Epic, dessen Stories du geschätzt hast, mit dem Wert drei. Daraus ergibt sich der E2S-Faktor. Er sagt dir, wie viele Story Punkte in einem Epic Punkt stecken. Damit kannst du die anderen Epics relativ zueinander schätzen. Im Beispiel kommen zwölf Epic Punkte zusammen, was rund 32 User Story Punkten entspricht.
Das gleiche Prinzip wendest du eine Ebene höher an. Du legst eine Referenzinitiative fest, hier mit dem Wert zwei, und schätzt die Initiativen relativ zueinander. Daraus berechnest du den E2E-Faktor, der angibt, wie viele Epic Punkte in einem Initiativenpunkt stecken. Mit den Faktoren und Punkten rechnest du alles zusammen und landest im Beispiel bei 80 Story Punkten für den ganzen Backlog.
Vom Punkt zum Preis
Jetzt wird es konkret. Nimm an, du arbeitest in Iterationen von zehn Tagen mit einem Team, das pro Tag etwa 5000 Euro kostet. Eine Iteration kostet dann 50.000 Euro. Du setzt dich mit dem Team zusammen, besprichst die User Story Map und fragst nach dem Bauchgefühl, wie viele Stories in einer Iteration zu schaffen sind. Sagen sie zum Beispiel zwölf Story Punkte, teilst du die Gesamtsumme und kommst auf sieben Iterationen. Bei 50.000 Euro pro Iteration sind das rund 350.000 Euro für das Gesamtprojekt.
Fazit
Du bekommst schnell eine erste grobe Schätzung auf Basis einer kleinen Story Map, ohne viel Aufwand und mit viel Nutzen. Du kannst mit dem Kunden prüfen, ob alles Wichtige drin ist, eine Ebene tiefer schauen, ob ein Ziel gut verstanden ist, und in die Tiefe gehen bis zur einzelnen User Story. Das ist transparent und nachvollziehbar für Kunde und Team und eine gute Grundlage für den Start deines Backlogs. Denn bei Schätzungen zählt der Weg mehr als das Ergebnis — und die F-Shaped Story Map macht diesen Weg sichtbar.
Ein Hinweis bleibt: Per Hand gerechnet ist das fehleranfällig. Deshalb ist die Methode in Betterplan eingebaut. Wie das im Tool aussieht, zeige ich in Projekte schätzen, auch wenn du noch wenig weißt.



