Developer Productivity is a major concern for most organisations.  All commercial and non-commercial organisations are increasingly dependent on software and the pace and efficiency of delivering software capabilities. Developer Productivity is a metric that determines the pace at which software innovations can be delivered, and so is developer productivity is key to organisational success.

Factors Affecting Developer Productivity

There are many factors that affect developer productivity and the impact of each varies depending on context.  Below is a partial list of some of the leading factors that affect developer productivity:

  • Size of the initiative
  • Technical competence and experience
  • Interpersonal skills
  • Domain knowledge
  • Focus/distractions
  • Tools (including use of AI code assistants)
  • Code-reuse
  • Leadership engagement
  • Clear requirements
  • Clarity of goal

What Developers Do

Developers are typically working on one or a combination of the following:

  • New software initiative (innovative or not).
  • Maintaining and/or fixing software (including tech debt repair)
  • Removing/replacing software

Project Size and Productivity

Project Size is one of the leading quantifiable considerations that determines developer productivity significantly.  For this reason our benchmarks are grouped according to project size.

Project size and developer productivity

Let us first look at why this is the case.  Successful software work requires close communication between users, developers, testers and other stakeholders.  As a team size increases,  the amount of time and effort required to communicate increases at a rate proportional to the square of the number of team members.   Consider the maths of the number of lines of communication between team members is N x (N – 1) / 2

Team size and communication overhead, source getlighthouse.com

Developer productivity is affected by project size because of the cost of communication.  Fortunately Project size (functional size) is measurable in a standardised and valid way.  For this reason we see that the highest productivity is achieved by teams of 7 highly competent people or less.

Our Developer Productivity Benchmarks

Typical Developer Productivity

Projects of <1000 CFP

Low Competence

Hours per CFP

Medium Competence

Hours per CFP

High Competence

Hours per CFP

Package implementation 6 2 1
Low code 8 3 2
High level language (typical) 25 8 4
Highly regulated domain 80 20 12
Low level language / firmware 80 20 12
Source: ScopeMaster Ltd

This table refers to the number of developer work hours per COSMIC Function Points delivered without defect, that we have observed.  These benchmarks are presented in hours per CFP. It is also legitimate to use the reciprocal of CFP per hours worked.  It is also useful to look at team productivity in CFP per 2 week sprint of each team.

Although these benchmarks may be useful to you for comparison with other organisations, we recommend that you accumulate and nurture your own internal benchmarks for developer productivity and other projects dimensions.  

Velocity Just Means Busy-ness

Velocity is a commonly used term amongst Agile enthusiasts gives some indication of the rate of developers doing stuff.  Whether it’s closing tickets or delivering “story points”, it usually means getting stuff ticked off a list.  From a literal point of view it is not really about velocity in the physics sense (direction and magnitude) but more about busy-ness or the rate of “closing tickets”.  In our view this is a pseudo-metric that is of little real world value.  Furthermore, velocity as it the term is usually used by agile teams, is inconsistent, subjective and gameable.