What metrics do you use to assess productivity for developers?

13 points by Jefro118 ↗ HN
Thinking more in a team context here, e.g. how long it takes for PRs to get reviewed on average. Although any individual metrics you use would be interesting also, I just think they're generally less useful.

13 comments

[ 3.1 ms ] story [ 34.4 ms ] thread
What is our accuracy as a team for feature delivery timeline estimations. Is someone consistently off, if so is there a common reason (eg brittle unit tests mean they have to refactor unrelated tests so their PRs are consistently late (or slow to produce). Not all development is equivalent, I’d cut and run if someone evaluated me on time to merge, LOC produced or churn, etc. Those aren’t reliable metrics in my opinion for how a person is doing in your environment, they are just evaluating maximizing me as an asset, not a person.
Productivity to me is a measure of cost vs impact, where cost for developers is almost always time. Time spent is easy to measure - something like time from idea to deliverable is usually good enough. I don't think you need to be precise. You just need a general idea of what kind of work takes ages, and what can be done quickly.

Measuring impact is trickier. It should be a signal of how well you're achieving the goal of your project. If you're working on, say, a budgeting tool, you will want to measure how much money your customers have managed to save, or something along those lines.

Productivity assessment isn’t for people, it’s for things. Devs are people, as such:

1. Do they know what they are doing?

2. Does it work?

Simple enough.

If only I could work for a company that sees me like that.
Basecamp my friend. There are others, but Basecamp is probably the most well known.
I've been subjected (in secret) to story point counting. Agile doesn't advocate for this and the company has a policy against it. But what goes on in reality for some teams is that management compares people by the number of points they delivered. Then to make it kosher they make up some other reason for your rating.
my basic metric, in general terms, is like:

  ( feature_complexity_points - bugs_reported ) / time_spent
time_spent and bugs_reported are collected from the JIRA.

tricky part is defining the feature_complexity_points used ( function points ? cosmic ? business complexity ? story points ? )

I like where your going with this.

How does feature size factor here? Are size and complexity independent variables? Or, is it that, by definition, larger features are more complex?

Do you actually need metrics? It's usually obvious who is very productive and who is not.