Long hours and millions of lines of code are not always good indicators on how productive a development team is, especially if they’re working on complex projects. So how does one measure software development productivity ?
AndPlus operations director Jonathan Roger sums it up well: “Software team productivity is an inherently difficult thing to put metrics — at least, quantitative metrics — around.”
Here are a few ways:
- Customer satisfaction: The most important aspect that you need to keep in mind and must ask yourself: Is your customers happy with the work you are doing? Regular check-ins to ensure that the client feels that you are making adequate progress is crucial metrics for your team. The Scrum process that is used need to ensure that it demonstrates progress for clients every two weeks at least as this gives a perfect touch point with them.
- Peer Code Reviews: Every line of code that goes into a project needs to go through a code review, meaning that the most-senior members of the development team will check projects to ensure that code quality is maintained. They also need to compare the amount and quality of code written to the amount of time spent and logged on an issue — this is indicative of how productive (or not) a developer is being.
- QA Kickback Rate: Once a ticket is dev-complete, you need to count on your developers to ensure that the feature actually works. If they are confident with the outcome, they will push the issue to the QA team for review. Kickbacks between the QA and development team are common, but if they see a significant number of issues (especially simple issues) being kicked back more than once, then that will be an indicator of problems with the development team’s effectiveness and productivity.
- Time Logs versus Historical Data: After years of writing agency management software, Chase Software has thousands of completed issues in our JIRA instance, associated with time logs. We can use this data to track historical time records for issue point levels. If we see a large number of issues taking longer than the average, it’s an indicator that the team may not be as performant as they should be. If a team is consistently taking less time to resolve an issue, it indicates either a highly-performant team or a team that is filling estimates.
At the end of the day, the goal is to be fair to the development team and the clients. At Chase Software, we realise that every project and issues within a project are different, and complexities arise even when the team is working on something that should be simple. As an agency management software company, everything we do is in some way novel, and we take that into account as well.