This post will explore different ways of measuring software development productivity and guide you on how to improve it.
How to measure software development teams’ productivity has been a controversial topic, especially since the emergence of the agile methodology. Before agile, the waterfall model offered a simpler, if not imprecise, way to measure productivity. Back then, it made sense to measure software development productivity through the different phases as it moved from analysis to deployment. But we all know that this is a poor model for real-life projects, with their ever-changing requirements.
To understand how to measure software development productivity, let’s start by exploring what is useful and not useful to track. Then, we’ll see how to use the data we collect to improve software development productivity.
Table of Contents
- How to Measure Development Productivity
- How Not to Measure Software Development Productivity
- How to Improve Software Development Productivity
- Get Started Increasing Productivity
How to Measure Development Productivity
First, let’s see some useful metrics for development productivity.
Do Track Cycle Time
The time taken to complete a task from start to finish is the cycle time. When applied to software development, cycle time is the time spent on a story from first commit to deployment to production. This could be bug fixes, new features, or code refactoring. This should not be confused with lead time, which is the time taken from when a story is created to when it is complete.
Working on a software development task generally includes four phases:
- in progress (coding)
- idle time (waiting for pickup)
- in review (pull request)
- released (deployed to production)
Throughout these phases, there could be many inefficiencies that slow a team’s cycle time, such as idle time the pull request is waiting to be reviewed, the time taken to review a pull request, and the time making corrections. Reviewing a team’s cycle time gives us an opportunity to identify and improve these inefficiencies in the engineering process and team performance. LinearB offers a great way to measure your team’s cycle time with zero manual inputs once you connect your Git and project systems. It also adapts to your current agile process.
Do Measure Deployment Frequency
Deployment frequency is the frequency of code deployment to production. This varies across teams, with some deploying to production many times a day, once a week, once a month, or once a year (please no!) The higher the deployment frequency, the smaller and faster the deployments. And smaller deployments are easier to test, which leads to fewer bugs.
Measuring deployment frequency gives insight into your continuous integration and deployment process and DevOps efficiency within the team. Using this data will help you understand your software development workflow and identify areas for improvement.
How Not to Measure Software Development Productivity
Now, let’s take a look at some ways of measuring software development productivity that aren’t helpful.
Don’t Rely on Story Points as Accurate Estimations
Earlier in my career, estimation meetings were a pain to me because I was often asked, “How many story points do you think the story is?” Unfortunately, lots of stakeholders and project managers have taken how many story points the team has completed in a sprint or iteration as a good measure of development team productivity.
However, Scrum.org quite nicely explains why story points should not be used as a measure of productivity: “Story points are for helping teams forecast how much work can be taken on in a sprint. The tracking of story points is not to measure productivity, but rather to show how much work remains in a backlog.” Estimation is very difficult to do and often takes time to get right, so it should never be considered 100 percent accurate.
So, you see, story points are simply used to explain complexity, not time taken for a task. It’s all well and good to compare similar stories to come up with realistic story points, but most engineers who lack domain knowledge and experience often default to guesstimates, which should never be used.
Don’t Use Burndown Charts
A burndown chart represents how quickly a team works through all user stories. Typically, the burndown chart isn’t a straight line; it shows the overall progress of work over a period until the project’s deadline.
Burndown charts are bound to have varying results based on uncontrollable factors such as scope creep, delays caused by engineers on holiday, etc. As such, burndown charts should simply be used as visual representations of work remaining in the project and to keep project team members on the same page. According to ProjectManager, “Burndown charts are ideal for agile project managers as they allow them to keep track of the work remaining, compare performance against a baseline and quickly determine whether they’re behind schedule.”
So, a burndown chart represents progress, but it may not show if team is working on the right tasks. This makes it an imperfect tool for measuring development productivity.
How to Improve Software Development Productivity
Now that you understand how to measure software development productivity and, just as important, how not to, let’s see how to improve it.
Use Metrics to Improve Processes
You can use the data you gather from monitoring metrics such as cycle time and deployment frequency to find inconsistencies in your software development workflow. You can then use those metrics to implement changes to your processes. If you do so, you should expect to see positive changes over time.
Stories can be broken down into smaller chunks to help speed up pull request reviews and deployment times. Even better, adopting continuous delivery by automating the test, build, and deployment phases in the software development life cycle improves development productivity.
Improvements such as an increase in the number and frequency of deployments, reduced failures after deployment, and quicker recovery from failures show a high level of agile maturity for the company or team. When engineers are able to quickly deploy to production, it boosts morale. Most important, improvements and new features keep customers happy and satisfied.
Allow Flexible Time and Work
Another way to improve software development productivity is to give your team flexible work hours to allow them to schedule tasks for when they are most productive. I’ll use myself as an example of how this can be beneficial.
I’m good at planning what to do for a development task, thinking ahead, and making note of potential pitfalls. But I don’t know how to organize my time without distractions. So, I took about 20 seconds every hour to log my daily activities for one week. I went through my time audit, analyzed it, and created a concentration curve. Using this, I was able to understand when I was most able to concentrate on a single task.
This is important because I can leave mundane tasks that don’t require much concentration to the morning and late evenings. Likewise, I can schedule any development tasks between the times 10 a.m. and 2 p.m. when I am most productive.
Engineers are more productive at different times of the day, and companies should recognize this. As such, it’s a good practice to offer flexible time and work as a benefit by default.
I have seen firsthand in my company how engineers have a boost in morale when they’re able to have a good work-life balance. And this comes from being able to work when they’re most creative as opposed to a typical 9 to 5.
Provide Allocated Study Time
In a fast-paced industry with new technologies and frameworks emerging every day, engineers need to keep up to date by learning. Having a dedicated day or time at work to be able to learn by taking a course, reading a book, or watching a video about relevant subject matter is invaluable.
In my current team, we have every Friday afternoon from noon to close of business to work on any course we want. This benefit is provided by the company. Companies should give engineers dedicated study time so they don’t always have to use their personal time for learning.
Get Started Increasing Productivity
“The truth is, there’s no good way to measure software development efficiency and productivity. But you can measure things that have a positive or negative effect on productivity.”—Vlad Giverts
There may not be an ideal metric to measure software development productivity with the aim of improving it. But tracking cycle time and development frequency are good metrics to start with. We get measurable data we can use to improve our software development process.
These improvements include breaking user stories into small chunks for easier pull requests and improved deployment times. Additionally, you should automate tests, builds, and deployment using continuous integration and deployments development practices. Further, you should give your engineers time for learning and encourage flexible work schedules. There are many benefits to implementing these changes:
- The team will have improved moral, which leads to low employee turnover.
- With the steps completely automated, deployments are less complex.
- Increased number and faster deployments means customers get new shiny features often.
- It’s quicker to recover from and reduce failures after deployment with smaller stories and releases.
- Automated testing means reduced costs since the team can focus on other important tasks such as code quality improvements.
Get a free-forever account from LinearB to help you measure your team’s software development productivity.
