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.
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.
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. 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.
Writing documentation is an incredibly under-appreciated skill in development. Documentation can take many forms. 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. Measuring documentation written is a bit harder than anything else we’ve talked about, and it depends mainly on how you store your documentation.
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. 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. If stand-ups happen in person, the best way to measure would be for the person leading the stand-up to take notes.
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. 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.
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.
1. Closed Tickets
Counting the number of cards a developer closes over a certain period allows us to see what actual work is getting closed off. Most software projects get managed with a ticketing system that logs the work to be done as individual tickets. 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
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. 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.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. 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.
3. Documentation Written
Most internal tools like Basecamp or Notion have page counts and attribute pages or parts of pages to the people who edited them. 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.Writing documentation is an incredibly under-appreciated skill in development. Documentation can take many forms. 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. Measuring documentation written is a bit harder than anything else we’ve talked about, and it depends mainly on how you store your documentation.
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. This type of measurement shows consistency. If you have a team of people who frequently meet or exceed expectations, you know they’re working well together.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. 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. If stand-ups happen in person, the best way to measure would be for the person leading the stand-up to take notes.
5. Forward Movement
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. 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.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. 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.
6. Code Reviews Completed
Measuring code reviews completed means counting how many code reviews are submitted or reviewed by someone on the team. 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. 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.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.
