There is a saying, that I like very much, that states: “you can’t manage what you can’t measure". Scrum is no exception. However there is a common misconception about agile methodologies such as Scrum: it is not supposed to be measured. In fact, in my humble opinion, Scrum has the right characteristics and the proper motivation to be easily measured and controlled. Why?:
- Scrum is oriented for quality and improvement. How can you know that you are improving or that you achieved your goal (quality) if you don’t measure it?
- As opposition to other methodologies, the main measures proposed by Scrum are very easy to collect
There are 2 metrics proposed by Scrum that are quite common:
- Velocity: it measures the quantity of work finished in a sprint. You calculate it by adding the story points of all the user stories that arrived at the state of “Done" in a given sprint (I will describe what story points are and how story points are obtained in a future post). Velocity enables the comparison of performance between sprints. So, if you implement changes in a Sprint, velocity provides you the possibility to measure if this modification brought a performance increase to the team comparing its velocity to the previous sprints’ velocity. Theoretically the velocity should have a slow but steady growth during the project. However you should consider that velocity is based on story points which measure the complexity of the user story and are estimated by the team. But the team perception of complexity varies throughout the project
- Sprint burndown chart: it represents the evolution of work to do within the sprint. The x-axis represents the time (days of the sprint) and the y-axis represents the story points. The day 0 will have the number of story points that the team committed to in the sprint planning meeting. Each day you decrement the number of points that were completed until that day. Hopefully in the last day of the sprint you’ll have 0 points to complete, meaning that the team completed all the user stories that it has committed to. This chart enables the team to follow up the stories that were finished and those that, to this day, were not, giving a good idea if the team is inline with its forecast. Sometimes this chart also includes a straight line linking the point in the day 0 of the sprint (with the initial number of story points) to the last day of the sprint (with 0 points). The user story completion should follow, has close as possible, this straight line. If this is not the case, it may mean that, either the tasks/user stories should be broken down into granular pieces or that corrective measures should be applied
Besides these two metrics proposed by Scrum there are several others that also provide a good help on tracking the team performance and evolution. Here are two examples that I find interesting and that I already used in my professional activity:
- Cumulative flow diagram: it allows the team to track the project evolution and to find bottlenecks. It shows the distribution of stories per state along the span of a project. The x-axis represents the time and the y-axis shows the number of stories. Each day you add all the stories in the system (organized per state) and represent them in the diagram. An ideal diagram would be a smooth growing set of lines or bands. If you find “bubbles” or “gaps” in any line or band, it means that you have a bottleneck somewhere: you must find it and correct it
- Committed vs completed user stories: For each sprint, it measures the percentage of work completed related to the work that the team thought it would complete at the sprint planning. It gives the idea of team accomplishment and also the ability of the team to understand the requirements and predict its capabilities. In the other hand, we can also use this metric to take conclusions about the availability of relevant information or the quality of the user stories’ content at the sprint planning
There are much more metrics that can be used in Scrum (the imagination is your limit). The most important part is that the team must be aware of these metrics and should “believe" in them. Otherwise they will be ignored or even worse: cheated in order to achieve the objectives. You must also remember that you should always choose very carefully what you measure. The KPIs should be aligned with what you want to monitor and improve. If they are not, eventually you’ll end up to optimize what you measure and not what you want. So choose wisely and the results will bring the team’s success.