I just started a project with a team of coders working remotely. I trust that they will get the job done, but I want a way to track their progress day to day. I know they are using a Git repository to keep a history of their changes, but I don't fully understand how to use it or how to get relevant information about their daily activity.

Is there a way to track their changes visually and simply?


8 Answers 8



You can use tools like gitk, GitStats, or the GitHub graphs tab for a visual representation of repository activity. However, this is usually a bad idea from a project management perspective.

The Wrong Metrics

In general, measuring lines of code (LOC) or commit activity is the wrong way to measure a software project. You get what you measure, after all; if you assess your team members based on volume, then you get volume, regardless of quality or usefulness.

Just as an example, consider the following Ruby code:

a = b = c = 1
a + b + c
# => 3

However, if my performance review is based on lines of code, you will get:

a = 1
b = 1
c = 1
sum = a
sum += b
sum += c
# => 3

and most likely one commit per line of code. That's a 350% increase in verbosity, a significant decrease in productivity, and no discernible impact on functionality. You will have measured your way to reduced productivity!

The Right Metrics

Generally, you will want to measure the quality and timeliness of your deliverables, rather than changes to the code base itself. From a project management point of view, it's the deliverables that matter most; your key metrics should reflect that, rather than falling prey to the 100% utilization fallacy or mistaking busy-work for progress.

Agile methodologies like Scrum treat tasks as done or not-done. You may want to consider adjusting your work breakdown structure to measure features or tasks that can be treated as checklist items, and assessing the team as a whole based on how often they meet the agreed-upon targets.

As a single example, it would be better to measure "add a function to sum three variables" rather than "write at least 200 lines of code per day." The first will get you a working function; the second gets you some very pretty graphs that you can proudly display on your wall after the project fails.

  • 1
    +1 The one thing worse than someone who doesn't know anything about a subject is someone who thinks they know and proceeds to use their judgement. Unless the OP is a developer they should should be consulting one.
    – MrFox
    Commented Mar 27, 2013 at 17:01

Rather than track code, track deliverables. Set deadlines for specific items being done and track against that.


It's a good thing you asked on a public site where people can respond truthfully rather than telling you what you want to hear.

The correct metric is:

Knowing what you are doing

There just isn't a simple metric that works, and trying to use one will mislead you, and if you act on it then it will drive the team in the wrong direction.

Saying "Oh, I know, I know, but I just want a quick overall picture" doesn't work either. Quick but wrong will only make things worse.

You need to know the people on the team, and what their problems are, and understand the code they checked in and how it relates to the overall project, and who was responsible for it. Or, you need to be able to figure out who to trust to tell you about those things.

If you can't, for whatever reason, do either of those things then you don't have the ability to measure the project. Period. If that means that you can't manage the project, then you can't manage the project. Try to look busy, stay out of the way, and hope they do well without you.

Of course, you can manage the project without measuring it. Find out what people need. Solve their problems. Don't create a new one - trying to get a project done while measuring up to silly metrics.


Unit tests.

I believe (I have not yet implemented this) that unit tests would be the basis of EVM if I were supervising.

Break the work down to unit tests and then measure completion of the unit test against the anticipated outcome and the error outcomes. (if there are notable errors, they get EVM credit).

I don't care how many Lines of Code you check in or out. I care whether Unit Test 4479 can handle 70% of the cases thrown against it.
(abbreviated for time)

Update Mr. Fox made a comment that is correct (and that matches a realization I had over lunch). I wouldn't want to measure single unit tests, I would want to measure some aggregation of them. Depending on the size of the project and the level of insight needed, I might measure tens or hundreds of unit tests. I'm not suggesting this is trivial, but in my opinion this is the best compromise that allows me to measure % complete against a standard that is closely tied to the software's eventual functionality. I'm kind of obsessive about measuring in terms of customer's value. Unit tests also re-uses a metric that is already being captured & measured.

  • 3
    If your single metric is unit tests, you will end up with a bunch of (perhaps superficial and needless) unit tests. Thereby, you will actively discourage spending time on other things like code quality or actual feature implementation.
    – MrFox
    Commented Mar 27, 2013 at 17:04

If they are using a git repository a good idea could be to use GitHub. In GitHub you have tools like charts in which you will see the process, commits, adds, deletions and so on that your group of coders is doing.

For using it you don't need any knowledge of how git works.

Another good tool we use is Pivotal Tracker. This is an online tool in which you have your backlog and sprintbackloog. The coders should start, comment and close the tasks they are working on. So taking a look at those tasks you will see what are they actually doing


Might I suggest using a service like CodeGraphite? (disclaimer: I am one of the creators of the site). While I completely agree with some of the other answers in measuring code does not necessarily measure productivity, it certainly can help give you an idea of overall progress when looked at over a period of time.

CodeGraphite shows you the basic metrics you may need:

  • Lines of Code per Day
  • Commits
  • Files added or Removed
  • Coder progress

Have a look at klin and fogbugz developed by fogcreek software. With tool you can see who is working on what and what is the progress. I suggest to have a look at the referenced fogbugz page and the embedded video by Joel (it was a real eye opener for me).


Simple: ask them to tell you what they are working on and got done, every day.

This can be annoying but there are tools that automate this with the minimum hassle for everyone involved, like Dutyful. It sends a mail to everyone in the team asking what they got done, they just have to reply in a few lines directly from their mail client. The next morning, you (or the whole team, which is even better for motivation) get a digest with everything that got done.

All that info is stored so you can keep them accountable on what they said. For that:

Ask them to do new deploys to a staging server as often as possible, so you can see the progress being done directly. Continous delivery is a good dev practice anyway, they should be doing it. In this way, you can see that what they are telling you about in the daily report is really getting done, and call them out for further clarification in case it isn't.

The best tracking is seeing the product evolution first-hand and keeping people accountable to what they say they are doing.

Your Answer

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

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