Measurements
Yesterday I made a statement to my daughter that she is spending too much time on the phone. She argued back that she is spending lots of time studying and uses phone for some relaxation from the hard work. How to solve the perception difference here. We need to measure the time spent on the phone. We also need to define what is acceptable ratio of phone and study. While I was not able to solve the perception battle there, it is easier on the work front.
What do you want to measure in your team? I did list some measurement in a post ten years ago.
I did not go deep into the why part at that time. Let us do it now. Without knowing why and what of the measurements you will become cargo cult agile
Team Velocity
While estimation is not absolute, it still gives some visibility into the effort. If you want to know how much you can deliver, then you need to know your velocity. Without knowing velocity, it is a waste of time to plan. It will be a blunder to commit to a plan without knowing your velocity.
Team Capacity
Velocity and capacity go hand in hand. You need to know your capacity for the sprint to give a commitment. There are various techniques to map the hours to story points.
Burndown during sprint
This is a visual representation of progress during the sprint. It gives a good idea about progress and any pitfalls during the sprint.
Backlog (Value delivered)
This measure is helpful for the financier of the project. It justifies the money and effort put on the project.
Fail ratio of automated tests
This is an indicator of quality. If more tests fail, it means there is a fundamental change in the product. Take care if it happened without conscious decision.
Failed builds - if using CI
Failed builds are an indicator of pressure or demotivation. Perform a RCA to find the reason and take appropriate decisions.
Test coverage
Falling test coverage is a measure of increasing technical debt. This will lead in a path of diminishing returns.
Comments
Post a Comment