Estimating How Many Hours A Project SHOULD have taken

Question

I am the senior developer at a company I work for and we have rapidly added many other developers and contractors. Our company is growing and that is great! Recently however, I have been tasked with code review (which is fine) but also with giving my opinion on how long certain projects most likely took for a particular coder to accomplish. This estimation is then used to compare against the hours the remote coders submitted.

I am a bit uncomfortable in this role, but I understand why they chose me: They have no idea what coding is or how to judge or read it. But my only resources for this is to look over their commits, get an idea of what they were doing and come up with my best guesstimation of how much time each code commit likely took to conceive, develop, debug, test, deploy. I factor all that together and present it in a spreadsheet, commit by commit.

There surely must be better ways to do this? What are some other ways to measure the work of our team members?

Answer 1

If you go down this road, then you will need a weekly or bi-weekly IPM (Iteration Planning Meeting) which everyone on the team attends. Some story tracking software will also be needed.

For every story, every developer votes on the effort until a consensus is reached. If there are differences of opinion, then hash it out until a consensual number is reached. This number represents the effort required to complete the work.

Make sure you define that unit of work. It's not an 8 hour day. Usually, the number represents actual work day which given emails/meetings/etc is sometimes estimated at 6 hours. But, you can decide what that number means. Once you have the unit of work defined and the story estimated, then the story is ready to be worked on.

Furthermore, you can break down this initial number into tasks broken down by the hour. You then simply track estimates versus actuals using the story tracking software. Developers will need to put in there actual time spent on tasks and/or story.

If there are differences on a story (over/under estimated) find out why.

Once this is done for a few months you will have a good idea of the team's and individual's velocity. Also, since everyone is committing to the amount of effort required the numbers should be pretty fair and somewhat accurate.

Also, you may run into situations when no one has done that type of work before. Simply create a spike (research) to measure those efforts.

Answer 2

Don't feel uncomfortable about this. Every company has to try and grade their employees in some way.

But I would suggest you use a less opinionated method.

1. Try to make the tasks a standard size. say approximately 1 day
2. Assign them as randomly as possible amongst the developers
3. Measure each developer by number of tasks completed in 1 "sprint"
4. Measure each developer by defects found.

You won't be able to make all the tasks exactly the same size, but as long as you distribute them randomly every dev should end up with about the same amount of underestimated and overestimated tasks.

You will soon have a spreadsheet showing how fast your developers complete work and how many defects they have from which you can make hiring decisions without having to make an arbitrary judgement.