Many teams leap to make changes without understanding whether their improvement actions have any real impact.
It's not enough to say "we collaborated well" in the Retrospective. Using metrics can uncover what led to great collaboration and when it happened, so you can repeat it next Sprint.
Gathering data is an important part of advanced Retrospectives. Important data to examine include:
If the team’s quality is low, if there is a lot of rework, then tighten the Definition of Done. If the team is strict in its adherence to the Definition of Done then quality should improve and defects should reduce.
Velocity is the average amount of Product Backlog that can be turned into an Increment of Done. Velocity trends should improve as a team gets better at delivering the same type of work. Velocity can go down due to:
Use Retrospective to talk about velocity trends:
How long do your “S” items take (in days) to go from in-progress to Done? What about “M” and “L” sized work?
Cluster Backlog Items by the number of days it took from in-progress to Done. There may be no difference in delivery time between certain sizes like “S” and “M”.
Estimate the size of the work it will take to deliver the Product Backlog item to Done as a team. Don't estimate tasks and don't use hours or days for estimation.
Lead Time is the total time it takes for a request to be actioned and delivered to Done.
Cycle Time is the time an item takes to move from in-progress to Done.
As agile behaviours strengthen, you should see a corresponding increase in the following Agile IQ measures:
Do a new team assessment every couple of months and decide as a team how you will improve these measures:
Do a team assessment every month. Compare the results to last assessment. And then look for improvement actions that align to your team's maturity stage.
Esther Derby’s Agile Retrospectives pattern sets a good structure for the use of metrics.
Ask the team to talk about the improvement actions that they did this Sprint. Ask questions like:
Examine the metrics you used:
Many teams jump from "what worked" to making decisions without understanding the causes of great outcomes, or poor ones, in a Sprint. Unpack what happened and identify the root cause to work out how to make successes repeatable.
All fields are required.