Software Metrics

Measuring Productivity through Outputs: 3 Considerations

For as much as we try to draw simple comparisons in order to explain concepts, the truth is that businesses are complicated things. In a post at his blog, Tom Cagley furthers his discussion on how inputs and outputs factor into measuring overall productivity. In this case, he looks squarely at three major decisions that must be made to best define outputs, which will in turn remove complexity in measuring productivity. These are the decisions:

  1. Deciding which output process or value chain to measure
  2. Selecting a unit of measure
  3. Deciding which units of measure to count

Time to Decide

Regarding the first decision, Cagley has this to say:

Deciding what to measure begins with defining the decisions the measurement will support… For example, to establish whether improving the processing power available to software developers in the form of new laptops would increase productivity requires measuring the output of software development (functional software).  Measuring the organization’s whole value chain would be overkill and far less effective… Organizations need to decide whether they are measuring the productivity of the overall product or a component that is part of the value chain.

As for the second decision, businesses often produce output that comes in different models. Cagley’s example there is that a pencil manufacturer’s output could be pencils, but if it produces two different types of pencil, then it would need to account for differences between the two when attempting to measure their combined productivity. A combination of function metrics and things like story points often account for such differences in software development. At any rate, a reasonable unit of measure must be defined, lest the business default to using a crude metric like number of hours worked.

Lastly, deciding which units of measure to count specifically regards the quality of the outputs. A pencil missing its eraser should not count as output at the pencil factory, for instance. Likewise, defective software deliverables should not be seen as output either. They should meet the agreed upon definition of done and be tested that they work to expectations.

Understanding what exactly constitutes valid output is the first step toward truly understanding productivity. You can view the original post here:

Show More
Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.