| I have had a lot of discussion about team productivity and how it might relate to velocity. In my view velocity is something to base small predictions/estimates on; NOT to assess teams productivity.
Questions:
- am right? or....
- is this trying to avoid responsibility for team effectiveness?
- can/may velocity be used as productivity measure.
Convenor: RobWestgeest
Output
Things we learned:
- When velocity is made a target, people might change their estimates. (evil; not effective feedback loop)
- Some tasks / stories do not have business value (e.g. infrastructure tasks and such.)
- Velocity can give us a clue that something is wrong with team effectiveness, but such clues should be combined with other indicators like business value and information (problems) gathered from stand-ups)
- In relation to throughput accounting: Productivity = Throughput / Operational expense (formula not complete - Pascal please help): Business Value measures Throughput and Velocity (indirectly) measures Operational expense. So it IS valid to relate Velocity to productivity.
- We can use business value to measure productivity, but this does not help us with team efficiency. ()
- Customers optimize on (business)value; developers optimize on velocity.
- If you only looked at value and the customer would put highes value stories in early iterations, it would look as if our productivity was decreasing. (which is true :-))
The measurement perspective of the TheoryOfConstraints is summarized in ThroughputAccounting -- PascalVanCauwenberghe
|
