Measuring Software Team Productivity

Productivity of a software development team is a bit tricky to measure without falling int one or more fallacy beliefs.

Traditionally the IEEE has set the number of code lines as a measure of productivity using the KLOC units that refers to a thousand lines of code being generated by developers. Using this method in an agile based environment makes things more misleading as there are lots of KLOC source code that is not part of the actual production code such as unit test code, integration test scripts, and other DevOps related YAML script lines.

Scrum has introduced the concept of sprint backlog burnout where productivity is observed by tracking a curve representing the consumption of customer stories in a sprint backlog. This method can also be misleading when ignoring the technical tasks injected into a sprint backlog as stories to tackle bugs and issues generated by the software team themselves including software code bugs and DevOps issues.

The accumulation of bugs and issues through Scrum sprints is known as technical debt. The larger the technical debt, the less productive is the team. That is why Scrum emphasizes on the need to stop all activities and take time to get rid of technical debt or at least reduce it to a minimum controllable level.

The Software Team

I purposefully stated in the time a software team rather than a software development team; as the productivity of the team is not limited to the development tasks but also includes other tasks related to DevOps, SecDevOps, and test engineering.

In some other times, you will find that organizational level managerial factors shall contribute to fluctuations observed in software team productivity during a software development lifecycle execution. These may include removing resources or injecting new resources, imposing pressure on timelines and cost factors, expanding or shrinking scope, or even decisions popping out due to escalations.

Whatever the case is, you should consider that the software team should include all team members regardless of their roles, and you should consider metrics for measuring productivity including all aspects and activities from all team members.

KLOC Is Misleading

Today, as test driven development (TDD) and domain driven design (DDD) are becoming a norm in software development the concept of KLOC measurement as a productivity metric becomes so misleading.

Clean code emphasizes on reducing number of lines of code written to solve a problem, while test case source code is not to be considered as part of the production code counted as KLOCs.

Lines of code written to do something one programming language is different than another. Those languages supporting Lambdas as a natural language concept may provide tremendously reduced lines of code compared to other languages that do not support that concept or support it in a nonnatural way.

Differences in programing language syntax, capabilities, and communities’ available libraries make it difficult to consider such a factor as a good productivity metric to measure.

Sprint Backlog Burnout

Sprint backlog burnout may present a good reference point to team productivity only and only if it is limited to true customer stories representing actual customer business functional and nonfunctional requirements.

If a team is injecting bugs and issues as stories; then Sprint backlog burnout will also become misleading.

Team Velocity

Scrum also presents a concept of team velocity measuring the speed in terms of actual time consumed to complete stories on the sprint backlog. You can easily see that this would be a good reference to observe if the backlog only contained true customer stories.

Factors Affecting Productivity

Let us try to list those factors that affect team productivity. This should help us building a mathematical model to measure team productivity:

1.??????? Number of true customer stories in a sprint backlog excluding bugs and issues

2.??????? Classification of customer stories in terms of complexity as it affects time needed to complete a story

3.??????? Team members seniority levels as senior developers may be more productive that juniors with less experience in the domain and tools used

4.??????? Increase or decrease in technical debt during sprint execution (bugs and issues)

5.??????? Business value of stories being completed and delivered

6.??????? Impact of organizational environment factors

As you can see that these factors requires more that an article to discuss and explain. Once understood we may extract some mathematical metrics from each category before attempting to build a proper model to measure team productivity.

That will be our journey during the next coming series of articles.

(to be continued….)