If we start with the premise that points are an estimate of effort and not a measure of value then estimating effort (story points) for every work item type helps teams better plan the workload. When some items have effort estimates and others do not, planning becomes subjective and teams frequently struggle with meeting their forecasts.
My advice to teams is to estimate (i.e., assign points) everything and to recognize that velocity is the rate at which the team does fully tested, clean, quality work. Velocity is not something teams earn or get rewarded for – for example, saying the team earned 50 hours of effort estimate makes no sense.
My advice to managers is to not equate effort with value – one does not cause nor necessarily lead to the other. Team velocity is just a raw measure of speed, nothing else – I know that the team delivers 50 points a sprint but that doesn’t tell me if any of that work is valuable or not. If managers/stakeholders are really interested in determining the percentage of time spent on value-add work then teams can simply flag an item as value-add or not.
Of course, determining value is easier said than done because (1) value is not a constant and changes over time, (2) stories by themselves don’t always provide value but do so in concert with other stories, and (3) in many domains value added by a feature isn’t measured objectively and is hard to isolate from value added by other features delivered. Keep things simple and don’t try to guess eventual dollar value delivered/earned/saved by each story — it is an exercise in futility.
With that said, lean does provide guidance on classifying activities as value-add, non-value-add but necessary, and pure waste. Agile teams can use the same when/if they want to determine how much time they are spending on true value-add work.
Rules for Evaluating Activities (What is Value-Add Work?)
Value add activity:
- Transforms (changes the form, fit, or functionality of) the product or service into something that meets customer requirements
- Customer recognizes the value and is willing and able to pay for it
- Is done right the first time
- Cannot be shown to be performed more economically
Waste (2 Types)
Type 1 Waste / Non-Value Add But Necessary / Business Value Add / Organizational Value Add (OVA) :
- Not valued by the customer, but
- Valued by the business or perceived as necessary for delivering value or staying in business
- Not valued by customer but required by organization
- Sustains the business; facilitates value-add tasks
- Regulatory Compliance
- Ancillary activities like HR, Payroll, etc.
Type 2 Waste / Pure Waste:
- Adds cost but not value
The following table is my quick and dirty attempt at listing some of the software development activities and classifying them as value-add or not.
How do you treat velocity and value identification? Have you seen dysfunctional behavior caused by an over-emphasis on velocity and a constant pressure to increase velocity?