Mention productivity to adherents of agile methods and you will get a range of responses. Some of the typical responses include blank stares, tirades against organization level control mentality or discussions on why velocity is more relevant. Similar reactions albeit 180 degrees out of phased will be experienced when you substitute the word velocity and have discussions with adherents of other methodologies.
Fantasy movies and novels have taught us that in the realm of magic, knowing the name of a person or thing confers power. In fantasy novels the power conferred is that of control. In real life, the power of having a name for a concept is the power of spin. Spin and control are a pair of highly related terms.
The FreeDictionary (www.thefreedictionary.com) defines spin as:
To provide an interpretation (a statement or event, for example), especially in a way meant to sway public opinion.
Naming a concept even if many similar concepts have been given names creates an icon that can rally followers and be used to heap derision on non-followers. Maybe because the followers of fantasy and science fiction in the IT professions is higher than you would find in the normal population; the pattern of naming as a concept to focus attention has risen to a fine art. Examples abound in the IT world such as the use of the term logical files in the IFPUG Function Points (where are the illogical files) and agile methods (the others must be the “slow methods”). Productivity and velocity are named concepts that reflect this rule. Each can evoke followers to alter their behavior or to generate violent rage in what began as a civil conversation. The irony is that these terms represent highly related concepts. Both seek to describe the amount of output that will be delivered in a specific period of time. They only differ in percived level abstraction.
If they are so similar why are there two terms describing similar concepts? The lets peel back another layer.
Dion Hinchcliffe has defined project velocity is the measurement of the event rate of a project. A simpler definition is simply work divided by time. In both cases velocity is used to describe the speed a specific team delivers results. Typical velocity metrics include stories per function point, requirements per sprint and stories or story points per iteration. The units of measure are targeted at the level of requirements or user stories. The granularity of the unit of measure and collection time frame (iteration or sprints) insure that the metric is generated and collected multiple times throughout the project generating a repeatable process through rote memory at an individual project level. Becuase of the short time horizon and the use of measures that can be derived at a team level, the data is useful to the team as they plan and monitor their work. Useful equals metrics that get collected in my book. Unfortunately because relative measures (measures based on perception) are used to size requirements these metrics tend to be less useful for organizational comparison than more classic productivity measures. Productivity is also relatively simple metric. It is simply the output (numerator) of a project divided by the input(s) required to produce the output (denominator).
Productivity typically is denominated by more esoteric units than calendar time such as hours of effort or FTE months (full-time equivalents) that relate to the entire project. The units of measure for the numerator range from the venerable line of code to functional units such as function points. Because productivity is generally collected and used at an overall project level it is very useful for parametric estimation or comparing projects but far less effective for planning day to day activities than is velocity. It should be noted that some organizations collect many seperate units to create a lower level view of productivity. I would suggest this can be done albeit it will require a substatial amount of effort to implement and maintain.
So if velocity and productivity are both useful and related shouldn’t we do both? The first place to start is to decide what question you are trying to answer. Once the problem you are trying to solve is identified the unit of measure and the collection time horizon both become manageable decisions. The question of whether we have to choose one over the other I would suggest is a false question. I propose that if we focus on selecting the proper numerator we can have measures that are useful at both the project and organization level. One solution is to substitute Quick and Early Function Points (QEFP is a rules based functional metric) for the typical story points (relative measure). QEFP can be applied at a granular level and then aggregated because it is rules based for reporting at different levels. Understanding the relationship between the two measures we devise a solution to have our cake and eat it too.