Es klingt wie eine einfache Frage: Wenn Ihr Team Aufwandseinheiten zur Aufwandsschätzung verwendet und Sie die Teamkosten kennen, können Sie dann einen Preis pro Aufwandseinheit berechnen?
Seit über einem Jahrzehnt versuchen Menschen genau das. Die Antworten reichen von $200 bis $2.000 pro Punkt. Einige Agenturen haben ganze Geschäftsmodelle darauf aufgebaut. Beschaffungsstellen der öffentlichen Hand haben Verträge darauf basierend geschrieben. Und Ron Jeffries — die Person, die Aufwandseinheiten möglicherweise erfunden hat — sagte schließlich, er wünschte, er hätte es nicht getan.
Dies ist die Geschichte aller, die es versucht haben, was sie gelernt haben und warum es eines der am meisten diskutierten Themen in der Softwareentwicklung bleibt.
Die einfache Rechnung
Die Berechnung selbst ist unkompliziert. Mike Cohn, Gründer von Mountain Goat Software und eine der meistzitierten Stimmen in der agilen Schätzung, beschreibt es einfach[1]: Nehmen Sie die Gesamtkosten Ihres Teams und teilen Sie sie durch die Anzahl der gelieferten Aufwandseinheiten.
Ein Team, das über 14 Wochen $160.000 kostet und 167 Aufwandseinheiten liefert, hat Kosten pro Punkt von etwa $958. Ein Team, das $50.000 pro Entwicklungszyklus kostet und 25 Punkte abschließt, kommt auf $2.000 pro Punkt. Ein günstigeres Team, das mehr Punkte liefert, landet vielleicht bei $200.
Die Mathematik funktioniert. Die Probleme beginnen, wenn man versucht, die Zahl zu verwenden.
Wer es tatsächlich versucht hat
PR 20/20: Die Marketing-Agentur, die es zum Laufen brachte
Die erfolgreichste Implementierung punktebasierter Preisgestaltung kam überhaupt nicht aus der Software. Paul Roetzer, Gründer der Marketing-Agentur PR 20/20 (heute ReadyNorth), investierte über 600 Stunden in den Aufbau eines Leistungskatalogs, bevor er im Januar 2014 die punktebasierte Preisgestaltung einführte[2].
Sein Modell wies Marketing-Leistungen feste Punktwerte zu — ein Blogbeitrag war vielleicht 3 Punkte, ein Whitepaper 8 Punkte — zum Preis von $165 pro Punkt. Kunden kauften monatliche Punktpakete und konnten Prioritäten verschieben, ohne Verträge neu zu verhandeln.
Der entscheidende Unterschied zu Software-Aufwandseinheiten: Roetzers Punkte maßen den Lieferwert, nicht die vom Team geschätzte Komplexität. Ein Blogbeitrag war immer 3 Punkte, unabhängig davon, wer ihn schrieb oder wie lange es dauerte. Das eliminierte die Subjektivität, die Software-Schätzungen plagt.
Roetzer berichtete von Verbesserungen bei Effizienz, Produktivität und Kundentransparenz. Andere Marketing-Agenturen übernahmen Varianten mit Preisen von $165 bis $175 pro Punkt[3].
Die US-Regierung: Punktebasierte Beschaffung
2017 experimentierte das Digital-Services-Team der General Services Administration (18F) mit punktebasierter Beschaffung für ihre Agile Delivery Services-Verträge[4]. Die Idee war, Teamkapazität gemessen in Aufwandseinheiten zu kaufen, was flexible, ergebnisorientierte Verträge statt starrer Festumfang-Vereinbarungen ermöglichte.
Eine detaillierte Analyse von Deloitte untersuchte, wie punktebasierte Beschaffung im öffentlichen IT-Bereich funktionieren könnte[5], und stellte die Attraktivität fest: Behörden konnten Lieferkapazität kaufen, ohne jedes Feature vorab zu spezifizieren.
Die Herausforderung war erheblich. Beschaffungsteams der Regierung mussten Liefergeschwindigkeit, Feature-Schätzung und Zyklus-Mechaniken verstehen — Konzepte, die der traditionellen Beschaffung fremd waren. Und Aufwandseinheiten, die teamspezifisch sind, machten es schwierig, Angebote verschiedener Anbieter zu vergleichen.
Der Festpreis-pro-Punkt-Vertrag
Christiaan Verwijs schlug auf The Liberators auf Medium ein strukturiertes Modell vor[6]: einen Festpreis pro Aufwandseinheit festlegen (er verwendete $500 als Beispiel) mit Mindest- und Höchststundenbereichen pro Punkt, um das Risiko zwischen Kunde und Anbieter zu teilen.
Wenn das Team schneller fertig wird als erwartet, behält der Anbieter den Effizienzgewinn. Dauert die Arbeit länger, ist das Risiko des Kunden begrenzt. Es war ein eleganter Versuch, agile Flexibilität mit Vertragssicherheit zu vereinbaren.
Das Modell erkannte eine Wahrheit an, die die meisten Befürworter der Aufwandseinheiten-Preisgestaltung vermeiden: Die Kosten eines Aufwandseinheiten sind nicht stabil. Sie schwanken mit jedem Entwicklungszyklus, jedem Teamwechsel, jeder Veränderung der Codebasis.
GData Software: Das Transparenz-Argument
GData Software veröffentlichte eine Argumentation für aufwandseinheitenbasierte Kostenschätzung[7] und behauptete, sie sei einfacher als zeitbasierte Erfassung. Ihre Begründung: Wenn Entwickler ständig den Kontext wechseln und regelmäßig Pair Programming betreiben, ist es nahezu unmöglich, genaue Stunden pro Aufgabe zu erfassen.
Ihre Formel war einfach: Zykluskosten durch gelieferte Punkte teilen. Sie präsentierten das Ergebnis als Transparenz-Werkzeug, das Vertrauen zwischen Teams und Stakeholdern aufbaut.
Warum es immer wieder scheitert
Für jedes Unternehmen, das Aufwandseinheiten-Preisgestaltung ausprobiert hat, gibt es eine längere Liste von Gründen, warum die breitere Branche sie abgelehnt hat.
Das Bedauern des Erfinders
Ron Jeffries, Co-Schöpfer von Extreme Programming und die Person, der am häufigsten die Erfindung von Aufwandseinheiten zugeschrieben wird, veröffentlichte ein bemerkenswertes Eingeständnis[8]: „Ich sage gerne, dass ich Aufwandseinheiten möglicherweise erfunden habe, und wenn ja, tut es mir jetzt leid.“
Seine Sorge galt nicht dem Konzept der relativen Größenbestimmung selbst, sondern dem, was passierte, wenn Organisationen es in die Hände bekamen. Das Management würde sich darauf konzentrieren, Schätzungen zu verbessern, anstatt Wert zu liefern. Teams würden die Zahlen manipulieren. Das Maß wurde zum Ziel.
Seine Empfehlung: Aufwandseinheiten nach Möglichkeit ganz aufgeben und sich stattdessen darauf konzentrieren, Feature-Anfragen klein genug für einen reibungslosen Lieferfluss zu schneiden.
Die Vergleichsfalle
Cohn selbst identifizierte die größte Gefahr[1]: Sobald man Kosten pro Punkt berechnet, wird jemand Teams vergleichen. Team A kostet $800 pro Punkt, Team B kostet $1.200 — Team A ist offensichtlich effizienter, oder?
Falsch. Aufwandseinheiten sind per Design teamspezifisch. Was für ein Team eine 5-Punkte-Feature-Anfrage ist, könnte für ein anderes Team eine 8-Punkte-Feature-Anfrage sein. Die Liefergeschwindigkeit zweier Teams ist nicht vergleichbar, es sei denn, sie haben bewusst eine gemeinsame Baseline etabliert und pflegen diese — und das tut fast niemand.
Doch die Versuchung ist unüberwindlich. Das Management sieht eine Zahl, und Zahlen verlangen nach Vergleich.
Manipulation ist unvermeidlich
Wenn Aufwandseinheiten gleich Geld sind, folgt Inflation. Accenture Federal Services veröffentlichte einen Artikel mit dem Titel „Hören Sie auf, Aufwandseinheiten zu kaufen“[9], der davor warnte, dass Teams Schätzungen absichtlich aufblähen könnten, um die Liefergeschwindigkeit — und damit den Umsatz — zu steigern.
Das Muster ist gut dokumentiert. Mountain Goat Software beschrieb Fälle, in denen Teams ihre Liefergeschwindigkeit innerhalb von Monaten fast verdoppelten[10] — nicht weil sie schneller wurden, sondern weil Schätzungen unter Managementdruck nach oben krochen. Ein Scrum Master berichtete von einer Kultur, in der „wenn du niest, bekommst du einen Aufwandseinheit.“
Das ist kein Fehler in der menschlichen Natur. Es ist eine vorhersehbare Konsequenz daraus, ein internes Planungswerkzeug an externe finanzielle Anreize zu knüpfen.
Das Stabilitätsproblem
Diskussionen in den Scrum.org-Foren bringen ein fundamentales mathematisches Problem ans Licht[11]: Aufwandseinheiten-Kosten schwanken jeden Entwicklungszyklus. Ein Team schließt vielleicht 24 Punkte in einem Entwicklungszyklus und 37 im nächsten ab. Der „Preis“ eines Punktes ist nicht fest — er ist bestenfalls ein gleitender Durchschnitt.
Mehrere Forumsteilnehmer bezeichneten die Verwendung von Aufwandseinheiten zur Berechnung monetärer Kosten als „grobe Zweckentfremdung“ des Konzepts. Aufwandseinheiten wurden für relative Planung entwickelt, nicht für absolute Preisgestaltung.
Das Messproblem
Scott Logic veröffentlichte eine detaillierte Analyse[12], die darauf hinwies, dass Aufwandseinheiten ordinale Unsicherheitskategorien sind, keine kontinuierlichen Maße. Fünf Punkte sind ungefähr doppelt so unsicher wie drei Punkte — nicht exakt 1,67-mal. Preismodelle, die Punkte als lineares Kontinuum von Pseudo-Stunden behandeln, verwenden die Skala mathematisch falsch.
Die Fibonacci-Folge existiert genau deshalb, weil die Präzision bei höheren Größenordnungen abnimmt. Jeden Punkt als gleichen Dollarbetrag zu behandeln, ignoriert diese grundlegende Designentscheidung.
Verborgene Arbeit verschwindet
Die Scrum.org-Analyse hob einen weiteren Fehler hervor[11]: Aufwandseinheiten-Preisgestaltung ignoriert all die Arbeit, die nicht gepunktet wird. Architektur-Diskussionen, Code-Reviews, DevOps, Mentoring, Bug-Triage, Meetings — echte Arbeit, die echte Kosten verursacht, aber nie in der Liefergeschwindigkeit auftaucht.
Die effektiven Kosten eines Teams pro gepunkteter Feature-Anfrage beinhalten all diesen Overhead. Aber das Preismodell sieht nur die Punkte, was eine systematische Unterschätzung der tatsächlichen Lieferkosten erzeugt.
Was die Branche stattdessen wählte
Die Dominanz von Stunden- und Projektpreisen im Software-Dienstleistungsmarkt spricht für sich. Trotz jahrzehntelanger agiler Adoption lehnte der Großteil der Branche Aufwandseinheiten-Preisgestaltung zugunsten von Alternativen ab.
Time and Materials mit Obergrenze
Das gängigste agile Vertragsmodell: Stunden- oder tageweise abrechnen, mit einem maximalen Budgetlimit. Der Kunde erhält Flexibilität; der Anbieter faire Vergütung; beide teilen das Risiko der Scope-Unsicherheit.
Festkapazitäts-Entwicklungszyklen
Kaufen Sie ein dediziertes Team für eine feste Anzahl von Entwicklungszyklen. Der Scope innerhalb jedes Entwicklungszyklus bleibt flexibel, aber die Kosten sind vorhersehbar. Das ist, was die meisten agilen Agenturen und Outsourcing-Firmen tatsächlich verkaufen.
Feature-Anfrage-Zählung
Martin Fowler dokumentierte eine Alternative, die die Schätzdebatte vollständig umgeht[13]: einfach Feature-Anfragen zählen. Sein Team bei ThoughtWorks stellte fest, dass Burn-up-Charts mit Anfrage-Anzahlen im Wesentlichen identisch mit denen waren, die Aufwandseinheiten verwendeten — weil Teams über die Zeit natürlicherweise Arbeit in ähnlich große Stücke aufteilen.
Wenn alle Feature-Anfragen ungefähr gleich groß sind, brauchen Sie gar keine Punkte. Sie brauchen Durchsatz: wie viele Feature-Anfragen pro Entwicklungszyklus.
Flow-basierte Metriken
Moderne Engineering-Teams messen zunehmend Zykluszeit (wie lange Arbeit von Anfang bis Ende dauert), Durchlaufzeit (Gesamtzeit von Anfrage bis Lieferung) und Deployment-Frequenz. Diese Metriken verbinden sich direkt mit Geschäftsergebnissen, ohne die Abstraktionsebene der Aufwandseinheiten.
Wo Aufwandseinheiten-Preisgestaltung tatsächlich funktioniert
Trotz der Probleme funktioniert Aufwandseinheiten-Preisgestaltung in engen Kontexten:
Interne Produktentscheidungen. Cohns ursprünglicher Anwendungsfall ist stichhaltig[1]: Wenn Ihr Product Owner weiß, dass ein Punkt ungefähr $2.000 kostet, kostet ein 10-Punkte-Feature etwa $20.000. Das hilft bei ROI-Entscheidungen und Feature-Queue-Priorisierung — solange die Zahl intern und approximativ bleibt.
Standardisierte Liefergegenstände. Roetzers Marketing-Modell funktioniert, weil Liefergegenstände wiederholbar und definiert sind. Ein Blogbeitrag ist ein Blogbeitrag. Software-Features sind selten so einheitlich, aber Teams mit hochstandardisierter Arbeit (z.B. wiederholter Aufbau ähnlicher CRUD-Oberflächen) können es annähern.
Budgetprognose. Historische Kosten-pro-Punkt zur Prognose zukünftiger Projektbudgets zu verwenden ist vernünftig — wenn man die Zahl als grobe Schätzung behandelt, nicht als vertragliche Verpflichtung.
Die fundamentale Spannung
Aufwandseinheiten-Preisgestaltung liegt an der Schnittstelle konkurrierender Bedürfnisse:
- Verkäufer wollen Vorhersehbarkeit — Festpreise machen den Verkauf einfacher
- Käufer wollen Kostensicherheit — ein bekannter Preis pro Einheit fühlt sich sicher an
- Teams brauchen Flexibilität — Schätzungen erfordern Raum für Lernen und Irrtum
- Aufwandseinheiten sind relativ — sie wurden nie als absolute Währung konzipiert
Das fundamentale Problem ist, dass Aufwandseinheiten als teaminternes Planungswerkzeug konzipiert wurden, aber Preisgestaltung externe, vergleichbare, stabile Werteinheiten erfordert. Diese Anforderungen sind inkompatibel.
Jeder Versuch, diese Lücke zu überbrücken, schränkt das Modell entweder so stark ein, dass es seine agile Flexibilität verliert (Festpreis-pro-Punkt-Verträge), oder hält es so lose, dass der „Preis“ als Verpflichtung bedeutungslos ist (nur interne Prognosen).
Was das für Ihr Projekt bedeutet
Wenn Sie Anbieter bewerten, die nach Aufwandseinheiten bepreisen, stellen Sie diese Fragen:
- Wie kalibrieren sie Punkte? Ohne eine Referenz-Baseline ist die Zahl willkürlich.
- Was passiert, wenn sich die Liefergeschwindigkeit ändert? Wenn das Team langsamer wird, steigen die Kosten pro Feature?
- Welche Arbeit wird nicht gepunktet? Architektur, Code-Reviews und DevOps kosten Geld, ob sie in der Liefergeschwindigkeit-Zählung sind oder nicht.
- Wie verhindern sie Inflation? Wenn Punkte gleich Umsatz sind, ist der Anreiz zur Aufblähung strukturell.
- Können Sie mit anderen Anbietern vergleichen? Sofern Teams keine identischen Baselines verwenden (tun sie nicht), ist ein anbieterübergreifender Vergleich der Kosten pro Punkt bedeutungslos.
Der ehrlichste Ansatz ist Transparenz: Verstehen Sie, was das Team kostet, verstehen Sie, was es liefert, und bewerten Sie, ob der Output die Investition rechtfertigt — ohne so zu tun, als ob eine einzige Zahl das vollständige Bild erfasst.
Transparente, aufwandseinheitenbasierte Projektpreisgestaltung gewünscht? Jetzt Schätzung erhalten →
