The days of lines of code defining developer productivity are thankfully a distant memory for most of us.
That doesn’t mean you shouldn’t measure how productive your developers are. It means you should measure things that make a difference.
What gets measured, gets managed
Peter Drucker
Code in and of itself doesn’t make a difference. It is the features that developers make that matter.
Today we’re going to share seven creative ideas to measure developer productivity that will help you measure things that have a positive impact on your product and your development practices.
Pro Tip: Code faster with TextExpander
TextExpander makes it easy to save commonly-used code snippets, documentation comments, and more — then insert them anywhere you type with a simple shortcut or inline search.
Click here to learn more.
1. Closed Tickets
Most software projects get managed with a ticketing system that logs the work to be done as individual tickets. Counting the number of cards a developer closes over a certain period allows us to see what actual work is getting closed off.
Measuring closed tickets is an excellent metric if the tasks are written well and assigned based on business priority. When more tickets get closed, more good things are happening with the project, be that bugs getting closed off or features made.
How you measure closed tickets will depend on the ticketing system you use, but all modern systems like GitHub, Jira, or Trello will allow you to see closed/completed items.
Not all tickets are equal, which is why many teams opt to score tickets by effort. Scoring makes it easier to see if someone is working through lots of straightforward cards and leaving the longer, harder tickets to someone else.
2. Deploys
A deploy is a unit of work that has made it from development to a live web server. Once something has been deployed, it is available for people to use.
Getting work in front of users is the best way to get feedback and to provide value to them. Measuring deploys works well because you’re measuring changes that are getting shared with your users.
Like measuring closed tickets, the vast majority of modern platforms will have a smooth and automated way to measure deploys and also to see what work went into a deploy. Often many individual changes will make it into one deploy so that a single deploy might get attributed to several developers.
You want to encourage your development team to release code often, but you want to make sure that the quality of the code remains high. So if you’re using this method, be sure that people aren’t deploying poor code just to achieve greater perceived productivity.
3. Documentation Written
Writing documentation is an incredibly under-appreciated skill in development. Documentation can take many forms. When done well, it can have a lasting positive impact on the rest of the development team, often for a longer time than the developer was there.
Because documentation is so important, it’s a great idea to set up a productivity goal with writing documentation in mind.
Measuring documentation written is a bit harder than anything else we’ve talked about, and it depends mainly on how you store your documentation. Most internal tools like Basecamp or Notion have page counts and attribute pages or parts of pages to the people who edited them.
Documentation for documentation’s sake can become burdensome, so look out for developers reinventing the wheel by documenting something that they really should have just linked to instead.
4. Stand-up Items Covered
If your team does daily stand-ups, they often follow a standard pattern: what I got done yesterday, what I’m doing today, what is blocking me. Measuring stand-up items covered involves knowing what they said they were going to do on one day and seeing if they completed those tasks the next day.
This type of measurement shows consistency. Does the developer deliver on what they say they will provide regularly? If you have a team of people who frequently meet or exceed expectations, you know they’re working well together.
If stand-ups happen in person, the best way to measure would be for the person leading the stand-up to take notes. One of the many reasons why we favor text-based stand-ups is that it reduces the need for one person to be on top of record taking.
An issue you might face measuring developer productivity this way is it might slow down the standup to ask people to clarify why things didn’t get done, even if there are perfectly reasonable explanations.
5. Forward Movement
Development teams don’t work in a silo and, depending on what other business processes are in play, measuring things like closed tickets might not apply. In those cases, you can measure forward movement. Forward movement means the change of a card from the left of a Kanban board, to the right.
A ticket might go from “Needs Investigation” to “Doing” to “In Quality Assurance”. Each time the ticket moves to the right, that is a positive movement. If the ticket ends up moving backwards, that is a negative movement.
This type of measurement incentivizes all forms of positive movement. Sometimes tickets get stuck because developers don’t know the complete solution, but they can make positive steps towards finding that solution.
Continually measuring this type of metric would need a project management tool like Jira or some custom analytics on your solution.
6. Code Reviews Completed
One of the easiest ways to improve code quality and ensure your developers are learning is to make sure changes are getting reviewed before they get deployed. Measuring code reviews completed means counting how many code reviews are submitted or reviewed by someone on the team.
Code review is an essential part of mature software development. Measuring how many reviews get completed indicates how much buy-in code review has within the team, and acts as a proxy for a lot of the other metrics we’ve mentioned. You can’t review code that doesn’t exist, so tickets are presumably moving forward.
Measuring this metric can be done in the majority of newer code repositories, like GitLab or GitHub.
Be careful though, code review is a time-consuming process and returns little value if the developers in question go through the motions and don’t take the required time to understand the code correctly.
7. Conversations Had With Others
Developers that spend too much of their time working in silos end up creating mediocre solutions. One way to ensure this doesn’t happen is to make a metric out of a developer having conversations with non-developers. This could mean clients or users of the system, or it could mean people in other teams like Sales or Marketing.
The more people talk, the more they learn from each other and the more context everyone has. This is why being present in meetings is a core developer skill.
Measuring conversations is best done during one-on-one meetings between the developer and their manager. If these are happening as regularly as they should, then checking in about what conversations have occurred should be straightforward.
Conversation count is one of the trickier metrics to measure, and communication isn’t always everyone’s strong suit, so definitely make sure you aren’t making someone feel awkward with this type of measurement.
How do you measure developer productivity?
We’d love to hear your thoughts on measuring developer productivity, and we want to know if you’ve tried any of the techniques in this article. Let us know in the comments below and let’s all learn from each other.
Not so sure about the quality of these. Tickets can regularly vary by a factor of 20x in how much work is required to implement them, thus the reason we included them in our list of “four metrics that agitate developers.”
“Deploys” doesn’t measure individuals, and like commits, they are an eminently game-able metric.
Documentation written is a pretty good metric, but if one isn’t careful, they’ll just be measuring lines of code, which isn’t ideal.
BTW, I started using your product about a week ago on the advice of a friend. It’s an awesome idea, really excited about its potential to reduce busywork.
Thanks for your thoughts Bill!
I completely agree that all tickets aren’t created equal, which is why scoring is so important.
I think with any metric, it should be treated as a data point to help with conversation. There shouldn’t be a black and white “you need to score ’20’ things this month”. When used conversationally the desire to game should be lessened.
Another bit of naunce missing here is knowing what way the team works. If working in a very agile way, then number of tickets is weak because there is often no end in sight.
Great to hear you can see value in TextExpander!