Personally I think you hit the two big ones.

Couple notes:

• Management said so – “contractual reason” can be “so we know where to send the bill for your time… not a small thing and something the programmer should take note of.
• Issues external to the team – I’ve used time charging to annotate problems coming from external sources that highlight places where the team should get help. Most notable was a Blue Screen of Death issue that came up several times a day – tracking hours of pain and suffering was a good way to make IT take note. I’ve also done this for rework due to faulty interface design from external teams.
• Balance of time within team – is the balance of design, developmentment, bugfix, test, build engine management, etc. correct? Is something taking too long? A good team topic
• Group norms – especially when new people join the team, difference in expectation can cause strife. Someone killing themselves for no reason, some one person working a week with lots of time off while the rest of the team is killing themselves. Who spent what time is not for team consumption, but it’s a good indicator to management that they may need to step in. I’ve actually had to do this more with new college grads killing themselves when the project schedule was NOT in a crunch.

 

bethlakshmi

“As a programmer, are you required to do timesheets?” would be the most similar question that has answers that may be useful though I don’t know if you looked at that question or not.

I’d agree that if one tries to measure things too finely there can be issues with knowing exactly how much time something took,e.g. could anyone time something to the nearest nanosecond well for a few regular work days without being quite frustrated. At the same time, it can be good to know where is work being done,e.g. are developers working mostly on support or are they putting in new features or fixing bugs? While that may seem like a management-only detail, it could also be useful for the team to know what seemed like a time sink while working on something.

 

JB King

There are a number of metrics that can be derived if you know {something} and time.

Just knowing the task and time is useful from a business perspective for tracking cost of a project. At a business level, you would typically know how much you are paying your engineers, so knowing time allows you to compute the cost of people for the project. Typically, people are the most expensive component of a software project, so knowing this is a huge plus to benefit. It’s not the only cost, but it’s useful.

From a developer’s standpoint, like you said, knowing time can be useful for estimation. The best estimates come from engineers, and to continue to provide good estimates, the engineers need to continually refine their estimates. Some engineers track their time well, while others need a little encouragement. Detailed time tracking is a good way to make (or at least try to make) engineers track their time and improve estimates. However, it’s only useful if the engineer wants to continually improve – it’s easy to neglect the data.

You can relate time spent on activities to how effective your process is. For example, let’s say you are following an agile methodology. In a given iteration, you spend 6 man-hours in code reviews and had 35% of your defects make it through to system testing. In the next iteration, you spent 12 man-hours, and now 30% of your defects made it through to system testing. You spent twice as long on code reviews, yet only detected 5% more defects – this raises a red flag that the code review process needs to be reviewed. You can apply the same techniques to requirements engineering, design, testing, and so forth.

Project effort is also typically measured in time. It’s fairly well known that SLOC/time is a poor measure of effort, but measuring some level of output/time (features, story points, earned value) is often used. Sometimes, just the total number of man-hours on the project is tracked. Either way, it lets you know how much time your people are putting into the project.

 

Thomas Owens

If you keep track of time to a relatively accurate level, staff may then watch what they are doing and may be encouraged to manage their own time as well. If I know that my boss will see that I am spending 5 hours in meetings that resulted in nothing significant, I will think of a quicker way to get things done.
I don’t know your team, however, in my experience given a large number of people, you get to see all kinds.

My idea here is not to use this as a threatening tool, but to try to link deliverable with resource cost (time).

To accomplish near accurate time tracking, you need to specify the tasks on a consistent level. For example, Create Report as a task may involve many other sub-tasks, so the team needs to know what level of break down to use so that the data becomes meaningful. This is not trivial work for you!

Another benefit your organization would get is that if you keep good records, it could help you do estimations in the future.

The downside is that I guess that 99% of programmers hate time sheet and I know some people that were almost insulted when they were asked to prepare them!

Another draw back is that you will loose time in collecting time information and in analyzing this information.

 

Emmad Kareem

The most important reason for estimating development hours precise to the level of hours, is

ECONOMY

It’s because stakeholders want to know how much it would cost for them to develop a project, or to implement a feature, or to even doing a task. Our product owner always says:

How many hours would it cost? Tell me that, and I’ll tell you whether to implement it or not.

 

Saeed Neamati

It depends on how accurate you’re talking about.

The best practice as far as I’m concerned is to measure down to approx 15-30 minutes what time you’ve been spending on what project. This time is not just coding or design time, but any bathroom breaks or office chit-chat that occurs. If you do this, it will tell you more than just estimates and billing. It allows you, the programmer, to track your own performance.

You should be asking yourself how long should this project take me? How long should this task take me? Then determine how long it actually took. Did you get done really quickly compared to what you would have estimated? What internal factors changed that seemed to have sped things up? What external factors? Did it take longer? Why? Knowing these things can better prepare you for future projects and maintenance.

However, I will warn about tracking down to fine-grained numbers (1-15 minutes). Its pointless. First of all, any task you work on (where a task is defined as one issue in your bug tracking system) that gets properly documented, recorded and coded will take at minimum 15 minutes, probably closer to 30. I say stick with 30, when you provide for context switches, documentation, bathroom breaks, etc… that should be as fine grained as you need to get.

 

Mike Cellini