2

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?

Improve this question
5
  • 8
    Sounds like an awful situation where management doesn't trust the remote workers. Even for senior people, it can be very difficult to judge the effort required until you actually do the work. It could be that the requirements are late or not well-defined. Management should trust the people they hire, or hire different people. This is not a metrics issue.
    – Dan Wilson
    Oct 17, 2018 at 13:23
  • Thanks Dan. We have had issues in the past where coders have clearly over-billed us. Ferreting out those and finding the ones that don't, has actually been a great way to find good employees to bring into the company. Generally with contractors, we have to just accept their submitted hours, so we are trying to find ways to quantify them better.
    – Jafo
    Oct 17, 2018 at 13:27
  • 1
    The better way is to copy the remote workers values, and paste them to the new sheet. There is no possible way for you to look at a solution and guess how long someone else took to do it.
    – Jack Aidley
    Oct 17, 2018 at 13:51
  • 3
    The most exhausting work I ever did ended with me reporting a faulty harddisk on the server, not committing a single line to the bug report that was "super top stay-all-night priority". Judging workers by commits is not very accurate.
    – nvoigt
    Oct 17, 2018 at 15:27
  • Best to measure work effort as a combination of actual vs estimate. You have to do post work review of estimates (i.e. estimate x, took y, were they lazy or was it bigger than expected). Last thing you want is punishing the people taking on riskier work.
    – mattnz
    Oct 18, 2018 at 22:27

2 Answers 2

Reset to default
3

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.

Improve this answer
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.