Lean-Agile offers two productivity measures: Velocity and Throughput. It is possible to improve both over time but there is little point in management demanding that a development team improve either because both metrics are very simple to fudge.

There is also little point in using either of these productivity measures in product development. The focus is discovery not churning stuff out.

Where a productivity measure is useful is in a project or programme. Where somebody is wanting to know when the team will be finished. Or, conversely, how much functionality will be delivered before the time and/or money has run out.

Lean-Agile Productivity Measures: Velocity and Throughput

Productivity is measured as output per unit of input.

Productivity = Output / Input

The software industry doesn’t have a good unit on either the Output or Input side of this equation. “Output” is generally viewed as live production software. Input is generally labour. In an Lean-Agile context the labour is not the labour of a person but the combined labour of the team over a limited time period like a week or month (which might be a Sprint).

In the Lean-Agile world there are currently two common output measures: Story Point estimates and the number of User Stories.

XP introduced Story Point estimates and they spread from there into Scrum (see Agile Estimating). Story Points are a relative measure of the effort to build a particular piece of functionality (often a User Story). The estimate factors in size, complexity, risk, and anything else that might affect how long it takes to build. XP also introduced the productivity measure Velocity, i.e. the total story points delivered by the team in a iteration (i.e. Sprint). So, for example, a team might have a velocity of 28 Story Points per (Week long) Sprint.

The Kanban guys approach productivity a bit differently as they don’t have Sprints and they often don’t estimate. Instead they ensure that the User Stories going into the development process are a similar size then just count the number of User Stories that make it to live. Their productivity measure is Throughput, i.e. the number of User Stories delivered by the team in a certain time period (e.g. Week or Month). So, for example, a team might have an average throughput of 4 User Stories per week.

So both major Lean-Agile sub-communities have a productivity measure: Velocity or Throughput.

The danger of a Productivity Target

“I want my team to go faster. How can we double productivity?” A common enough question from a manager. Doubling productivity might not be reasonable but aiming for smaller incremental increases is.

The trouble is that the Lean-Agile productivity measures can be gamed. Manager says “Double your productivity” and the team can oblige overnight. To double velocity the team just has to double the size of every Story Point estimate. To double Throughput the team just halve the size of their User Stories; probably a bit more tricky but doable with some effort. The real irony is that the request to increase productivity is most likely to lower it as the team expends energy gaming the system.

Management and the team are much better off taking a slow and steady approach to improvement. Get the process more slick. Remove impediments when they see them. Inspect and adapt. And better metrics for incremental improvement are Lean’s Cycle Time and Lead Time; reduce those and Throughput is likely to increase.

The value of a Productivity Metric

Productivity measures are useful for answering the questions “How much stuff will we have by X date?” or the more traditional “How long will it take?”

If nobody is asking those questions, or nobody you care about, then you don’t need a productivity measure. The team will deliver stuff every week and as long as the amount of stuff being delivered “feels” about right then all good. This is the situation for most product development organisations. Particularly in startup mode. It is all about exploration and learning. Forget about productivity.

But if you do have to answer “how long will it take” then productivity does help. Typically in a project or programme. Most of my Agile software delivery work has been on a fixed price basis and the customer very much wants to know when the team will finish . . . and to be honest, so do I. This is where empirical project management comes in. Using yesterdays weather (i.e. productivity measure of work finished) to predict the future (i.e. get a release plan showing what will be delivered when). This is where you need a Release Plan and Agile Project Planning.