Sizing is focused on answering, “If we assume no identified requirement risk, what is the size?” This is useful, but it can be harmful if it’s used for estimation while potential risks are ignored. If that happens, we might achieve high team velocity while the overall system throughput is low. Also, it can widen the execution gap between the team and organization as the team wants isolation in order to achieve its velocity. I found many teams who are devoted to measure their velocities are almost always operate in isolation from the rest of the organization. Once, they begin to align to the organization, velocity becomes of less relevance.
For me the above point is specially critical. The team increases productivity is the driver, while the reality is that the team increases the velocity of divergence from the organization.
Measuring people performance based on number has been always warned against as it:
– Reduces team initiative because the team is focused on achieving its velocity target if it ignores all aspects important to operate in harmony with the organization.
– Leads to non-meaningful comparison between different teams in the organization based on the velocity of each.
– Misguides the organization because after all velocity is a vritual figure at it has no baring to what brings value to the client.
There is lot of literature about performance management and team performance which do not relate to the performance in the Engineering aspects.
We should focus on measuring:
– the business valued features which the client appreciates,
– the cost per feature delivered to the client, and
– Lead Time.