Display time period/duration in hours/minutes and man-day in web project management tool

Question

We're building an in house project management Web tool. Our tool is based on Redmine where time duration is set in hours.

It isn't acceptable for our needs.

We need granularity in minutes. Really to add 20 min as spent time you must enter 0.333333333 - ugly, isn't it?

Also mostly all employees have 8 hours work day, so long duration (like total time for all tasks in version) naturally presents in man-days. If sprint requires 20 man-days and your team has 2 developers then you're going to be done in 2 weeks. It's hard to make this conclusion if you see 160 hours.

So my question - what format is best to use for specifying spent time, time periods, duration both in hours, minutes and man-days.

Some requirements:

• Setting exactly in minutes doesn't solve the problem. It's hard to imagine how long 1440 min is, it's 24 hours or 3 man-days.
• Usual time format hh:mm also is not good because you show 140:30 like strings.
• Duration format must be persistent across all UIs.
• Users can enter duration. Users may get frustrated learning how to enter duration, it's possible to type 2:40, 2h, 1h15min, 35m. Also we have Russian speaking users, so they naturally enter 3 часа 30 минут.
• UI already have many input elements, so splitting duration into several <input> seems bad for appearance.
• The UI should work for both desktop and mobile.

I've done a search and found some related questions:

• Best way to present time durations in a list?
• Time (duration) entry in webapp - pros/cons of various designs
• Approaches for setting a time period
• Best way to create a timespan GUI element?

where 20d 5h, 2h 30m seems acceptable to me. For man-day I haven't found any standard format.

Answer 1

As your primary focus seems to be tracking working hours, you could easily assume that 8 hours are one day. E.g. the popular issue tracking tool JIRA does so: if someone logs e.g. 9 hours, 1d 1h will be displayed for easier readability.

This way you wouldn't run into a problem as long as you don't want to track "real" (= 24h days) separately; and could get around your problem of inventing a new acronym.