Kategoria: Wizualizuję (ciągle)

"Ewolucja backlogu i roadmapy produktu czyli “mięsny agile by example”" https://t.co/T39DxCK5ub by @AgilePiMa on @LinkedIn

— Piotr Maksimczyk (@AgilePiMa) October 7, 2016

If you start your journey towards measuring Scrum team’s agility, it is possible you will find it valuable to measure Velocity. I intentionally called the metric the mother as this is probably the most recognizable metric in an agile world. Yet it’s empirical value is often overestimated. Consider below example.

The team’s velocity is systematically decreasing over time. Does it mean the team is doing less and less work over time? Yeah! Sure! Let’s help them to do more. In fact, you can observe some common pattern. Without usage of reference estimates, stories required the same amount of work, often tend to be estimated with less and fewer story points over time.

The team’s velocity is systematically increasing over time. Does it mean the team is doing more and more over time? Yeah! Sure! Let’s give a bonus to them. In fact in this particular company bonuses are based on teams’ velocities so teams to get higher bonuses play with this metric and estimate the same tasks as higher and higher over time.

In a perfect world, velocity should be used as a planning tool only, for a Development Team to predict how much work can be done in the forthcoming sprint, for a Product Owner to plan consecutive sprints and releases. Assuming your team’s estimates are not changing over time, you can still use this metric during measuring team agility. See the charts below.

 

The first one is classic Velocity chart showing how many story points is done at the end of a sprint. Vertical bars indicate Velocity calculated in the consecutive sprints. The trend line is in the form of a moving average calculated from last 5 sprints. Take into consideration the “doneness” of points must be calculated according to the actual team’s Definition Of Done.

 

 

The second chart is exactly the same data shown not as absolute story points but on a relative scale, where 100% means the highest velocity the team has ever reached. Each time team reaches new highest value, this value becomes new 100% and all old data is being recalculated.
To be more precise, here comes an example of calculation. In last 3 sprints team reached 15, 20, 15 story points. We convert these numbers to 75%, 100%, 75% respectively. In 4th sprint team reaches 25 points, so the new relative numbers are 60%, 80%, 60%, 100%.

This kind of measuring can be used by a Scrum Master as a “raising the bar” tool for which team should be striving for in forthcoming sprints. To be more specific. If a team reaches new 100% Velocity, Scrum Master can ask a team questions like “what can we do better in the next sprint to hold the same high velocity?” and facilitate discussion so the team can improve.

Measuring Velocity can be good starting point for measuring team agility however, this is only the beginning of the journey.

Note! After 2 years since writing the article above, my knowledge in the field of metrics improved dramatically. I highly reccomend yo to read also an article titled Real-life Agility Metrics And Visualizations That Will Lead You Towards Evidence-Based Decision-Making.