Velocity: How to interpret it to improve your agile team productivity. 3 of 3: What-if and FAQ
This is the final article of this series.
his third article contains some Q&A that are commonly asked when dealing with velocity.
Velocity: How to interpret it to improve your agile team productivity. 2 of 3: When velocity is read wrong
Second installement of the How to interpret Velocity to improve your agile team productivity.
This article will detail the information contained in each metric and how to use it to improve team productivity.
Velocity: How to interpret it to improve your agile team productivity. 1 of 3: Flavours of Velocity
Velocity is a commonly used metric in agile teams. It is a great metric due to its apparent simplicity. However, I often see teams drawing the wrong conclusions for the metric, which results in decreased productivity.
This post is the beginning of a three-part series to convey my understanding of how to make sense of the information that velocity, as a metric, can provide to an agile team. And use this information to improve the team’s productivity.
Paper of the Month: Interpretative case studies on agile team productivity and management
Paper of the Month: Interpretative case studies on agile team productivity and management.
Three topics that affect productitivy:
* Developer turnover
* Team Design
* Inter-coordination factors
Managing technical resources at capacity
“Only variation can absorb variation”
Software is intangible, is the result of knowledge work, and is very much prone to variation. In this post, variation means anything that changes the nature of work.