One cannot spend a week in software development without hearing how many days are left before some milestone, be that a release or just a sprint demo. Yet, I cannot remember ever hearing that there is only 120 hours left until the upcoming release. Sometimes 24 or 48 hours are being tossed around to deliver the same message, but that's just saying that the release is in 1 or 2 days and that the team is expected to work around the clock to get there.

Most issue tracking systems, on the other hand, tracks work in hours and one cannot help but wonder how work hours translate into days until that milestone. The simple answer is that they don't, even though most teams keep trying to have that cake and eat it too.

Not all days are created equal

Anyone who plans sprint work in hours ends up with most tasks underestimated just a couple of days into the sprint. The math here is simple. A task estimated as 3 days of work is immediately converted into 3 * 8 = 24 hours by the issue tracking system configured for regular work days. In software development, people rarely work 8 hours a day, so a developer working on this task will most likely spend 9-10 hours a day and when they finish in 3 days, they will log 28.5 hours, adding 4.5 hours to the original estimate.

Scrum masters deal with this by adding 25-50% to all developer-provided estimates or just demand "better" estimates from developers, which ends up in adding some arbitrary amount of time to estimated work hours to bring them closer to the actual work time for each task, averaged across all team members. Another way to remedy this, of course, is by configuring the work day length using some average of actual hours for the team, but having a plan for 10-hour days visible to everyone makes the place look like a sweatshop, so scrum masters tend to stick with extra "contingency" hours.

The real problem here is not with the estimates, but in that estimated time and logged time use different time units and one cannot be derived from the other using simple hours-per-day math. This does sound counter intuitive, but a regular work day in software development may be anywhere between 8 and 11 hours long, while a part of a calendar day people are expected to work amounts to some fixed number of hours for a given company, such as 8 hours.

Imagine two brilliant developers in two competing companies working on the same feature. One of them finished coding and testing in 8 hours and second developer took a slightly different approach and finished their work in 10 hours, maybe with extra documentation or a few more unit tests or with some minor technical advantages that do not make the second product stand out, but are still useful in development.

The first developer didn't cut corners and even though they could add more tests or documentation, their feature works just as well as the one implemented by the second developer. That second developer, on the other hand, had a choice of either spending those 2 extra hours to add those extra unit tests, etc, or just leaving it working as it came out after 8 hours of work, which still would do a good job by any measure. It is unlikely that they would start another task in those 2 overtime hours, unless the they are in a release crunch.

All in all, while each developer spent different number of hours working on their feature, each of them will report at the next stand-up, one day after the work started, that they are done with the feature and the hours they spent won't even come up in those reports. One day is all that matters.

Reliable planning

Planning work in days allows one to even out different daily work styles and focus on how those estimated work days stack up into calendar days until the next milestone. It also allows team members to adjust their work days to accommodate minor cases of underestimated work without disrupting the original estimate and provide better estimates for the next sprint.

Estimating in days does not mean that a day is the minimum amount of time for any work. Any fraction of a day is just as valid as a whole day and follows the same logic - 0.5 day may be anywhere between 4 and 6 hours long, so one can still accomplish two 0.5 day tasks or four 0.25 day tasks in one day, even if they have to redistribute hours between tasks or add some overtime.

For example, a developer who completed 2 tasks in 8 hours and a developer who completed 2 tasks in 12 hours, all in one day, each completed two 0.5 day tasks that day. These numbers accurately indicate how well planned work was delivered and are not intended for gauging how hard each developer worked on their tasks, which is something a development manager should keep their eye on using other tools.

Evaluating quality of estimates is also more straightforward with days because all numbers use the same units. Completing a 3-day task in 4.5 days indicates that it was underestimated. Having 2.5 days logged against the same task after 3 days indicates that time was spent elsewhere, perhaps in some meetings. Having 1.5 days logged and a completed task indicates that the work was overestimated. Needless to say that the original estimate must never change to make it useful for these comparisons.

My hours are bigger than yours

One aspect of using actual work hours in sprint boards that does not receive enough attention is that work logs are visible to all team members, which creates unhealthy competition when people start comparing work hours.

For full-time employees overtime hours are meaningless without additional context and somebody working 8-9 hours a day may yield more usable output than somebody logging 10-11 hours. Issue tracking can provide valuable input for performance reviews, but development managers should use other tools to figure out how hard people worked to complete their tasks.

Hourly engagement

Contractors present another interesting aspect in that for sprint planning purposes there is no difference whether some work will be done by a full time employee or a contractor. A task estimated in 3 days requires the same amount of work to be done, regardless whether it will be assigned to a contractor or a full time employee, and will be completed in the same amount of time, assuming both have the same skill level.

Time tracking for contractors is between them and the person who signed their contract and has nothing to do with sprint planning and tracking. Just like with performance reviews, contract hours should be tracked in a separate subsystem that can track actual work hours or using separate tools.

They like it in hours

From the practical standpoint, some issue tracking systems are better than others, but the desire to log work hours runs deep in all implementations and even those that are designed to allow days in sprint planning and tracking, may still push hours where they don't belong.

For example, Azure DevOps describes that all effort fields can contain hours or days, but the implementation uses hard-codes phrases, such as Hours, in sprint boards and work item labels. Microsoft considers this so unimportant that they wouldn't even consider this as a bug, despite their own documentation saying otherwise. Some of those labels may be edited in the agile process settings, which makes it usable if one is willing to overlook the letter h in some places in agile boards that cannot be changed.

Jira makes it even more complicated because it can only work in hours and 2d is immediately converted to 16h internally or whatever number of hours is configured for work day length, so, in practice, I try to adjust actual work hours to reflect a part of a normalized day, which has limited application.

For example, if a work day is configured as 8 hours, 1d will be tracked as 8h and will indicate one normalized day, regardless of the overtime within that one day. In other words, 8 hours or 10 hours are logged as 8h. A fraction of the day would then be normalized against those 8 hours, so 4 hours of an 8-hour day or 5 hours of a 10 hour day would both be logged as 4h, which is a half of the normalized day. This way one can always divide the resulting hours by 8 to get accurate days for estimated and logged time or just configure some of the reports in days, which will produce accurate day counts. Recent versions of Jira make this a bit easier in accepting fractions of a day in time values, such as 1.5d, but will display it as 1d 4h, which may be misleading. Nevertheless, this is still is easier to work with than trying to normalize 6 hours of an 11-hour day to an 8-hour normalized day.

However, this approach works only if the entire team uses it or otherwise those who normalize their hours will look like they work less than other team members and that their tasks require much less work to complete.

Conclusion

Comparing one planned work day against one actual work day, regardless of overtime hours, is just common sense, no different than comparing apples to apples, and yet, the entire industry seems to be determined to fit that square peg into a round hole.

Wouldn't it be nice if the likes of Atlassian would realize that they are missing a separate subsystem that not only would track actual work hours in a way that would keep them between each team member and their manager, but would also intelligently translate those work hours into work days for sprint boards and backlogs?... Well, maybe one day.