Aufwand für Software – warum eine Schätzung von Anfang an wichtig ist
Wer SCRUM kennt, weiß: Agilität steht bei der Softwareentwicklung an erster Stelle. Nur wer sich einfach an veränderte Bedingungen anpassen kann und während des Entwicklungsprozesses flexibel bleibt, kann hochwertige Software erstellen, die den Anforderungen von Kund*innen genügt oder diese sogar übertrifft.
Das liegt daran, dass sich in unserer Gesellschaft des digitalen Wandels Bedingungen rasant verändern können. Was heute noch modern ist, kann morgen schon wieder out sein. Bedürfnisse der Nutzer*innen entwickeln sich genauso schnell und Softwareprodukte müssen diese erfüllen. Auch ist es oft so, dass zu Beginn eines Softwareprojekts noch gar nicht alle Bedingungen feststehen.
Agilität ist also der Motor einer jeden produktiven Softwareentwicklung.
Das heißt aber nicht, dass deshalb einfach drauf losentwickelt werden kann. Selbst wenn nicht alle Details zu Projektbeginn bekannt sind, muss von Anfang an ein grober Plan her. Sonst ist die Gefahr, sich orientierungslos im Meer aus Möglichkeiten zu verirren, groß. Denn: keine Orientierung, kein erfolgreiches Softwareprodukt.
Zum Plan gehört auch eine Aufwandsschätzung, die Auftraggeber*innen für die Kalkulation brauchen. Softwareentwickler*innen selbst benötigen die Schätzung wiederum, um die eigene Arbeit zu koordinieren und Ergebnisse nach Absprache zu liefern.
Da wir anfangs jedoch nur mit Variablen arbeiten können, können wir den Aufwand nicht genau planen, sondern müssen ihn eben schätzen.
Wie wir bei Ambient Software-Aufwand schätzen
Als Digitalagentur haben wir es tagtäglich mit Unsicherheiten in unserer Projektplanung zu tun. Glücklicherweise haben wir zwei Werkzeuge, die uns helfen, damit umzugehen und trotzdem erfolgreich an unseren Projekten zu arbeiten: das User Story Mapping und die Magic Estimation. Mit beiden in Kombination können wir
- alle Anforderungen definieren und bei Veränderungen den Überblick behalten
- eine realistische Einschätzung des Aufwands vornehmen, den jede Aufgabe erfordert
User Story Mapping: Struktur für jedes Software-Projekt
Auch agile Softwareentwicklung erfordert Struktur: Deshalb setzen wir stets auf eine User Story Map. Diese entwickeln wir gleich zu Anfang jedes Projekts, um einen Überblick über alle Anforderungen zu bekommen und eine grobe Richtung für unsere Projektentwicklung festzulegen.
Beim Meeting für die User Story Map sind immer Entwickler*innen, Designer*innen und auch Kund*innen präsent. Gemeinsam sammeln wir zunächst alle Anforderungen, dann sortieren und strukturieren wir sie.
Das machen wir visuell auf einer großen Karte. Dabei arbeiten wir vor allem aus einer Sicht: der Sicht des*der Nutzer*in. Folgende Fragen sind dabei wichtig:
- Was will der*die Nutzer*in von unserem Softwareprodukt?
- Welche Funktionen benötigt er*sie, um das zu erreichen?
- Welche Bedürfnisse erfüllt unser Softwareprodukt für den*die Nutzer*in?
Diese User Map ist ganz am Anfang enorm wichtig, damit ein Produkt nicht „am Markt vorbei“ entwickelt wird. Oft entstehen hier im Team große Diskussionen, denn jede*r hat eine völlig andere Perspektive auf diese Dinge. Wichtig ist nur, dass sich alle immer die Frage stellen: Will der*die Nutzer*in das wirklich – oder ist das nur eine Idee, die mir gefällt?
Beim User Mapping sollten deshalb folgende Dinge definiert werden:
- User Tasks: Damit sind alle Aufgaben gemeint, die ein*e Nutzer*in mit Hilfe der Software erledigen möchte (z. B. Steuererklärung, Shirt-Design oder Reiseplanung).
- User Stories: Damit sind die einzelnen Schritte gemeint, die zur Erfüllung der o. g. Aufgaben nötig sind.
Bei der Erstellung einer User Map spielen zwei Dinge eine entscheidende Rolle: die User Personas (also, welche Gruppen von Nutzer*innen gibt es und wer sind diese Menschen?) und die User Journey (also die Reise, die der*die Nutzer*in im Laufe der Nutzung der Software unternimmt).
User Personas helfen uns, unsere Zielgruppe zu kennen und User Tasks realistisch zu ermitteln. Die User Journey wiederum hilft uns die einzelnen Features und Funktionen so zu strukturieren, dass der*die Nutzer*in die Software gerne und gewinnbringend nutzt.
Nehmen Sie einen Online-Shop als Beispiel:
Ein*e Nutzer*in gelangt auf Ihre Homepage und möchte etwas kaufen. Wenn er*sie nicht auf Anhieb ein Angebot erkennt, wird er*sie schnell woanders suchen. Was brauchen wir also? – Einen Shop-Button, der gut sichtbar platziert ist.
Auch richtet sich das Angebot Ihres Shops nicht an Einmal-Käufer*innen, sondern an immer wieder kaufende Kund*innen. Diese möchten nicht jedes Mal Ihre Daten neu eingeben, wenn Sie einen Kauf tätigen. Also benötigen wir – einen Log-In.
Usw. Diese Beispiele sind sehr rudimentär. Meist sind User Tasks weitaus vielschichtiger. Sie sollten jedenfalls so genau wie möglich definiert werden.
Nicht jede User Story wird umgesetzt
Meistens erweisen sich in der Entwicklung mehrere User Stories doch als nicht notwendig oder zu kostspielig. Das ist auch völlig in Ordnung. Agiles Projektmanagement besticht durch flexible Anpassung des anfangs gemachten Plans an die realen Bedingungen. Aber: Ohne User Story Map ist eine Aufwandsschätzung für uns kaum möglich. Deshalb ist es so wichtig, am Anfang so genau wie möglich alle Aufgaben festzuhalten und zu ordnen. Auch eine Priorisierung ist dabei bedeutend: Welches Feature muss unbedingt implementiert werden, welches ist dagegen optional?
Die Unsicherheit der Umsetzung kann hier als Schätzfaktor genutzt werden: Mit einer detaillierten User Story Map können wir mehrere Szenarien durchspielen und für jedes davon einen eigenen Aufwand schätzen. Realisieren wir bspw. User Story Map A, beträgt der Aufwand x Stunden. Bei User Story Map B, wo wir jedes optionale Feature weglassen, sind es weniger. Bei User Story Map C liegt der Aufwand ungefähr in der Mitte.
So schätzen wir verschiedene Möglichkeiten ein und können diese mit unserem*unserer Auftraggeber*in besprechen.
Individuelle Beratung zur Aufwandsschätzung einer Software vereinbaren
Magic Estimation: Bodenständiger, als sie klingt
Im Anschluss an die User Story Map erstellen wir unsere Magic Estimation. Wenn Sie davon noch nie gehört haben, klingt das vermutlich ziemlich aufregend – ist es aber eigentlich nicht. Mit „Magic Estimation“ bezeichnen wir eine simple Methode, um schnell große Mengen an User Storys bezüglich ihres Umsetzungsaufwands einzuschätzen.
Im Gegensatz zur Entwicklung der User Story Map, wo viel diskutiert wird, sollte die Magic Estimation nur begrenzt im Team diskutiert werden.
Dabei arbeiten wir mit einer vorher festgelegten Schätzskala: bei uns Shirt-Größen. „XS“ steht dabei für den geringsten Aufwand und „XL“ für den größten. Damit arbeiten wir wie folgt:
- Zunächst entscheidet jedes Projektmitglied für sich, welche Größe, also welchen Aufwand, er welcher Aufgabe beimisst („XS“, „S“, „M“, „L“ oder „XL“). Dies notiert er auf einem Zettel, den er an die entsprechende Stelle der User Story Map hängt.
- Erste Diskussionsrunde: Wir diskutieren im Team die einzelnen Einschätzungen. Jede*r kann seine Zettel jetzt noch einmal neu anordnen.
- Zweite Diskussionsrunde: Nun diskutieren wir noch einmal. Falls neue Einwände aufkommen, können diese hervorgebracht werden. Jetzt sollten nach Möglichkeit eine Einigung erzielt sein und alle (oder die meisten) Zettel mit den Aufwandsschätzungen zu den einzelnen Tasks übereinstimmen.
Dieser Ablauf der Aufwandsschätzung mit User Story Map und Magic Estimation hat sich für uns bewährt. Aber Achtung: Das Ganze funktioniert nur, wenn Auftraggeber*innen schon eine relativ genaue Vorstellung von Ihrem Softwareprodukt haben.
Fehlt diese noch gänzlich, sollte zunächst mit einer Produktvision gestartet werden.
Produktvision als Basis jeder Aufwandsschätzung für Software
Bevor also User Map und Magic Estimation zum Einsatz kommen, muss eine Produktvision her. Diese ist schon gegeben, wenn sich ein*e Auftraggeber*in mit konkreten Vorstellungen an uns wendet. Wenn die Vorstellung noch vage ist, müssen wir dagegen mit der Ausarbeitung einer solchen Vision anfangen.
Im Groben besteht eine Produktvision aus:
- Idee
- Absicht
- und Motivation zur Produkterstellung
Die Produktvision sollte die Frage beantworten, was der*die Auftraggeber*in durch die Produktentwicklung erreichen will – und zwar für Nutzer*innen und für das Unternehmen selbst.
Ein Beispiel für eine Produktvision könnte so aussehen:
„Wir wollen eine Dating-Plattform entwickeln, die Menschen nicht nach Interessen, sondern nach Persönlichkeitstypen matcht, und damit Vorreiter im höherpreisigen Love-App-Segment werden.“
Die Produktvision ist enorm wichtig, nicht nur um den Aufwand für Software zu schätzen, sondern auch um Projektmitarbeiter*innen immer wieder daran zu erinnern, warum sie dieses Projekt überhaupt umsetzen.
Empirische Prozesskontrolle als Basis für Aufwandsschätzung: Die 3 Prinzipien
Alle Methoden, die wir Ihnen hier vorgestellt haben, basieren auf dem Prinzip der im SCRUM bekannten Empirischen Prozesskontrolle. Nur wenn wir bereits Erfahrung mit ähnlichen Projekten haben, können wir neue realistisch einschätzen.
Die Empirische Prozesskontrolle (wie auch SCRUM) fußt dabei auf drei Dingen:
- Transparenz
Nur wenn das Team offen miteinander umgeht, können Softwareprojekte erfolgreich realisiert werden. Das gilt auch schon ganz zu Beginn bei der Aufwandsschätzung. Deswegen ist die Diskussion bei der Erstellung der User Story Map so wichtig. Dadurch wird vermieden, dass schon zu Anfang große Differenzen bezüglich der Aufwandsschätzung zwischen einzelnen Mitarbeiter*innen entstehen bzw. nicht überwunden werden, bevor die Arbeit startet. - Überprüfung
Erfolgskontrolle ist beim SCRUM enorm wichtig, und zwar nicht erst, nach dem Projekt, sondern nach jedem Sprint. Auch bei der Aufwandsschätzung für Software sollte die Überprüfung der ersten Impulse vorgenommen werden. Deshalb legen wir (anders als vielerorts vorgegeben) zwei ganze Diskussionsrunden bei unserer Magic Estimation ein. So können wir sichergehen, dass unsere Einschätzung realistisch und für unsere Auftraggeber*innen nachvollziehbar ist. - Anpassung
Auch die Adaption an veränderte Bedingungen ist ein zentrales Element von agilem Arbeiten. Deswegen haben wir diese schon in die Aufwandsschätzung übernommen: Sobald wir in einem Sprint merken, dass die Realität stark von unserer User Story Map abweicht, schätzen wir neu ei
"Aufwandsschätzung ist und bleibt ein Stressfaktor zu Anfang eines Projekts. Aber – es lohnt sich, clever und strukturiert vorzugehen, um realistisch zu planen."
Mit uns Ihr Softwareprojekt umsetzen
Aufwandsschätzung ist und bleibt ein Stressfaktor zu Anfang eines Projekts. Aber – es lohnt sich, hier clever und strukturiert vorzugehen, um realistisch zu planen und Auftraggeber*innen zufriedenzustellen.
Möchten Sie bei der Umsetzung Ihres Softwareprojekts mit einem rundum kompetenten Partner zusammenarbeiten, der stets fair, transparent und persönlich mit Ihnen kommuniziert? Dann sichern Sie sich jetzt ein unverbindliches Beratungsgespräch – wir freuen uns drauf!
