Every Sprint is a chance to do things better. Use data to grab this chance for your team to grow and improve.
Starting The Retrospective With Data
Scrum is founded upon three pillars of empirical process control: Transparency, Inspection and Adaption. Yet few Scrum Teams use data as starting point of their Retrospective. Everybody is able to express their opinion, but data never enters the equation. There is a lot of talking with little objective common ground.
By starting with data it is transparent how the team is doing. The team will be able to inspect the outcome of process improvements and adapt if necessary. Without data, how will you know when you actually performed better? How will you know when decisions actually had negative consequences or side-effects?
I will share some easy to track metrics that will help focusing your Retrospectives.
Forecasted Versus Delivered Story Points
Every Sprint the team forecasts how many Story Points it will deliver. If the team fails to deliver the forecasted Story Points this is an opportunity for learning. Did the team pick up too many Story Points or where there too many disturbances? Where the issues in the Sprint poorly described? It is easy to adjust the velocity for the next Sprint without thinking about it. Maybe we can prevent it from happening by pausing and reflecting.
Average Time In Status
The slowest step in your software development workflow forms a bottleneck. The flow in the development process is constrained by this slowest step. Any process improvement made anywhere besides the constraint is an illusion. This is why it is important to know which step in your process is the slowest. This is the step you should focus on. Until another step becomes slower and turns into the new bottleneck.
Average Cycle Time
The Average Cycle Time represents how long it takes on average before an issue is finished after the team starts working on it. Ideally process improvements should result in a lower Average Cycle Time. A higher Average Cycle Time means issues passed through your development workflow slower. As your team works together longer (and better) the Average Cycle Time should decrease.
Time Spent Versus Estimated
Any issues where the team spent more than twice or less than half of the estimated time are worth discussing. What could we do to estimate better next time? Was there something we forgot to take into account? Was the discrepancy inevitable or not? Estimations will always be off. By decreasing variability the predictability increases.
When the team moves an issue back from code review or test to be worked on it is reopened. If this happens a lot, then this is a clear signal something is not going well. It is very important to try to minimise the reopened count of your development work. You should aim to do things right the first time. Mistakes are exponentially more expensive the later they are discovered.
Critical/Blocker Bug Ratio
The Critical/Blocker Bug Ratio is the number of Critical/Blocking bugs divided by the total amount of bugs. When this number gradually increases after your team releases new functionality then this is a clear indicator the quality of what your team is releasing is becoming lower. If you introduce quality control improvements then this number should gradually decrease for your team.
Transparency By Using Data In Retrospectives
Using data as the starting point of your Retrospective allows for Transparency, Inspection and Adaption. By using data you can actually talk about the numbers instead of your gut feeling. You will also able to revert bad decisions based on facts. Or challenge your team to try something bold and new. The team can measure the outcome in the next Sprint to prevent resistance to change from dictating the conversation. The numbers will help telling the story of what actually happened and guide the discussion.