Scrum geeft de voorkeur aan het schatten in complexiteit in plaats van in uren. Dat klinkt lastig, want je wil toch graag weten hoeveel tijd een taak in beslag neemt en hoeveel taken je kan plannen in een werkweek. Er is echter een goede reden om te schatten in complexiteit.
Wij mensen zijn erg slecht in het schatten in uren. Tijd is een absolute eenheid en daar zijn wij eenvoudig genoeg niet zo goed in. Wij kunnen slecht inschatten hoeveel een stadsbus weegt of wat het gewicht is van een elektrische fiets in kilo’s. Wij kunnen wel in een oogopslag zien of een flatgebouw drie keer zo hoog is als een normaal huis, maar de absolute meters zijn dan weer moeilijk.
Als men zich laat verleiden tot het schatten in uren schuilt daar ook nog het gevaar in dat een opdrachtgever daar zelf conclusies aan gaat verbinden. Een taak van 16 uur is met 4 man toch te realiseren in ’n halve dag? Maar absolute effectiviteit op een dag is niet per definitie 8 uur. Mensen zijn ook nog eens geneigd om optimistisch te schatten als het om tijd gaat, daarom is het beter om te schatten op basis van in het verleden behaalde resultaten.
Als je op basis van resultaten uit het verleden schat heeft dat ook nog eens als voordeel dat onverwachte verstoringen, afhankelijkheden, scopewijzigingen en eventuele andere invloeden impliciet worden meegenomen in de schatting. De punten bieden houvast in de zin van grootte en zijn hiermee losgekoppeld van de tijd. Mocht er toch een wens ontstaan om doorlooptijd te relateren aan punten is het altijd mogelijk om de punten te delen door het aantal beschikbare punten per sprint.