5 min on Scrum | Sizing instead of Estimating (2)

I drove from my home to Vienna. I needed around 6 hours. This is a time!  So, to perform the task: Driving from home to Vienna, I needed 6 hours.

In a tactical project plan I can now put an estimate for the next drive to Vienna of about 6 to 7 hours. This tells me nothing about the length from my home to Vienna.  It even tells me nothing about my performance.  Although I have a pretty fast car, I could not utilize its power. Too many cars on the street (impediments), too many road works, too many “id..” oops – sorry.

The problem with measuring performance on a task level is that we do not have a standard task.  Not even such a simple task as Driving from home to Vienna is the king of useful task which I can standardize.  Too many influences.  Taylor could measure the performance of workers because he was able to create standardized tasks.  Everybody who has ever worked on an assembly line knows that most of the tasks are standardized.  Here you can measure the time worker A needs and then you can say worker B is “better” (more productive) or “worse” (less productive).

In any other situation – when you do not have a standardized task, any way to measure the performance based on time will have a result that tells you nothing.

This is the case with software development – no standard tasks, nothing is clear. So we can not say something about the performance of people.

What we need to find is a way to talk about the software instead. So we need to have a measurement for Size. (The distance between my home and Vienna.)

tbc…