A few months ago, our team switched over to Scrum, a fairly modern software development framework. Scrum is an implementation of the agile methodology that focuses on roles, sprints, backlogs, and meetings.

Lots and lots of meetings...

Anyways, besides the large spike in meetings, the basic principles of Scrum actually ended up fitting in quite well with how we were currently managing all of our software development. However, now that I've had a fair amount of experience with Scrum (and as a part-time Scrum Master), I feel that there are certain parts of the methodology that I don't quite buy into. Particularly, using hours to estimate tasks.

The Scrum Task

In Scrum, a task is a defined unit of work, usually estimated in hours. It is commonly believed that hourly estimates are more accurate and provide the most transparency. I believe this is true; however, not in software development. In a professional environment, a software engineer has far more responsibilities besides programming. A lot of these responsibilities cannot be estimated, as they are out of the engineer's control. Even more so in a start up environment.

Some people recommend the use of 'ideal' (5-6) hours over 'real' (8) hours when estimating their tasks. Theoretically, this should account for distractions and various other activities (lunches, breaks, emails) for the day. However, these distractions are often too sporiadic in when and where they occur, and also the duration of the distraction.

A Solution?

After a few sprints, I begin to notice that most of my tasks usually ended up occupying a whole day. When I become aware of the pattern, a bit more thought provided me with a reasonable assumption as to why this was happening.

See, in any given day, a reasonably sized task (4 hours) would be completed. In a perfect world and an 8 hour workday, this would leave 4 hours left. In our world, remove 2-3 hours for lunch, emails, communication, and everything else, you are left with 1-2 hours in the day. Starting anything smaller than 2 hours brings in too much task management overhead and/or requires a substantial amount of ramp up time. Of course, anything larger and it is better off to start working on it another day. Eventually, a 4 hour task ended up being a day's worth of work and that led me to my new conclusion:

I believe that the ideal base unit of time for software estimation is a day. It is appropriately sized and it works along a Maker's schedule. A day provides a more reasonable and realistic estimate to software development, and the activities that revolve around it. It allows for common workplace distractions, as well as actual non-coding work.

I do not believe hourly estimates provide much value. A software project's success or failure has never come down to the hour, and it never should.