In fast jedem Projekt stellen Stakeholder früher oder später die Frage, wie viel Aufwand die Umsetzung einer Anforderung erzeugt. Oftmals wird dafür auf die vertraute Schätzung in absoluten Zeiteinheiten (Stunden/Tagen/Wochen) zurückgegriffen. Das ist nachvollziehbar, da Zeitintervalle eine leicht verständliche Metrik darstellen, die kaum weiteren Erklärungsbedarf erfordert. Hinsichtlich der Praktikabilität weist dieses Vorgehen jedoch deutliche Nachteile zu alternativen Schätzmethoden auf. Die Schätzenden tun sich oftmals schwer, einen konkreten Zeitwert zu nennen. Haben doch viele bereits die Erfahrungen gemacht, aufgrund des Ankereffekts auf diesen einmal kommunizierten Wert für die restliche Projektlaufzeit festgenagelt zu werden, unabhängig davon, wie sich Anforderungen und Umstände ändern oder welche zusätzlichen Erkenntnisse man im Laufe des Projektes sammelt.

Eine Schätzung verliert somit ihren vorgesehenen Charakter und entwickelt sich von einem Ausblick auf den ungefähr zu erwartenden Aufwand zu einem fix angenommenen Kostenblock.
Hinzu kommt der Irrglaube, dass sich die Entwicklungszeit von Software exakt vorhersagen lässt. Neben dem Handwerk ist Software-Entwicklung auch ein kreativer Prozess, bei dem verschiedene Wege ans Ziel führen können.
Um diesem Trugschluss in gewissem Maße zu entfliehen, aber auch um die Durchführung der Schätzung für das schätzende Team zu erleichtern, sollten Anforderungen daher relativ geschätzt werden.