Scrum Metrics for Product Owner + Proxy Scrum Master

Ever been in a position where you are the product owner in a project and get requests like

1. What’s your team velocity?
2. What’s the team’s capacity?
3. How long would you take to complete these features?
4. How does the burndown chart look like?

Photo by Lukas from Pexels

You might think that these questions should be directed to the dedicated Scrum Master on the project and with some magic, they would be able to give you the answers. However, that may not be the case in projects where the scrum master role is not well defined in the project.

Now, there is a way for you to create this MAGIC for the team!

Based on my experience in various projects and acting as a proxy scrum master in projects where the role is not well defined, I have been able to capture some of the information that are frequently referred to while tracking progress of sprints and planning future sprints. This is commonly referred to as Scrum Metrics. A good start to understanding the term is detailed well in Scrum Metrics 101 by Atlassian.

In addition to the common scrum metrics, I was able to come up with few more metrics that would help the team plan and forecast their work and effort better. Let’s see the entire list of Scrum Metrics that I currently refer to in projects.

1. ​Team Capacity (Required)
2. ​Sprint Health (Required)
3. Sprint Status (Required)
4. Sprint Velocity (Required)
5. Sprint Burndown (Required)
6. Sprint Goals (Required)
7. Team Velocity (Required)
8. Release Burndown (Required)
9. Cycle Time (Optional)
10. Cumulative Flow (Optional)
11. Forecasting (Optional)
12. Resource Effort (Optional)

1. Team Capacity

For a sprint to be successful (all work items marked complete / done prior to closing the sprint), the team should be able to plan ahead. Team Capacity can be referred to as the amount of work the team can take / plan-for based on their availability on the project for an upcoming sprint.

In most of the cases, projects have team members from multiple levels of hierarchy having varied roles in the project. Hence, team members could be mapped to a role vs capacity-per-day matrix. This matrix would detail out the role and the amount of work (in terms of story points) that can be completed by a member playing that role in the project. Example of such a matrix is as follows.

2. Sprint Health

When you are playing the role of a scrum master in the project, understanding the health of the sprint is very important. Sprint Health is a visual representation of the overall health of the sprint in terms of the progress of the sprint considering the status of the planned work items, new work items and blocked work items. This metric could help provide detail on

1. Number of days left in the sprint
2. Number of work items that are complete and not complete
3. Number of work items that are flagged / blocked
4. Number of items that were added once the sprint started.

3. Sprint Status

Based on my experience, the scrum metrics in any agile project that is referred to and discussed is the status of work items. Sprint Status is the metrics that refers to the status of any work item at a given point of time within the duration of the active / current sprint. This metrics could provide a breakdown of all the work items planned for that sprint based on the status mapped in the workflow. This metric in addition to the Sprint Health metric would give a holistic view of the active sprint. This metric can be represented in a table (Status | # of items) or as an interactive pie chart.

4. Sprint Velocity

Velocity as we know is the distance covered in a defined duration. Likewise, Sprint Velocity depicts the amount of work completed in a sprint. This is quantified as the number of story points accrued for the items completed in that sprint / marked as done. This metric could represent the entire team or in cases where the metric is focused around development, it could represent only the development team’s velocity. Representation of this metric can either be a 2D matrix table calling out the velocity for previous sprints or could be simple textual representation of the velocity of just the previous sprint. This metric would be required while calculating Team Velocity metric.

5. Sprint Burndown

Let’s consider that you are looking for a visual representation of the completion of work items through the course of the sprint. That’s where the “Sprint Burndown” metric comes to play. It is a visual representation of effort that was initially estimated at the start of the sprint vs the effort completed at the end of the sprint. Hence, a line graph is the preferred representation of this metric. At the start of the sprint, the line would start at the corresponding story point set for the sprint. As the sprint progresses, the line would depict the completion progress of those points. Meaning, as the work items complete, the story points remaining in the sprint reduces and hence the line starts to dip. However if work items are added to the sprint while it is active (which is not recommended), then the line would spike up to represent addition of story points in the sprint. Some of the issue tracking tools, provide a line as a guide based on the items planned and the team’s capacity (if this information is available).

From the above example, x-axis represents story points, y-axis represents the start and end date of the sprint and the red line depicts the completion of work items in the sprint and the spikes are instances when work items with story points were added during the sprint (sprint’s scope creep). The grey line shown is the guide (In this case the team’s capacity information wasn’t present to create a proper guideline.)

6. Sprint Goals

While planning work items for a sprint, it is necessary to be aware of the features and it’s priority for the quarter. Sprint Goal could call out the items that are required to be completed in that sprint along with the features that would be worked upon. This can be represented by marking items based on priority and tagging working items to features and setting a sprint completion criteria based on the priority. For example, The goal of sprint12 is to complete all of the high priority along with the medium priority items and the features that would be worked upon in this sprint would be Feature 1, Feature 2, Feature 3.

7. Team Velocity

Sprint Velocity (mentioned couple of metrics above) was the velocity of the team for the previous sprint. In cases, when you are looking for velocity across multiple sprints, it is termed as “Team Velocity”. Team Velocity is average amount of effort of completed work item across multiple sprints. Which can be translated to average of previous sprints’ velocity. On a general note, when the team velocity is to be calculated, the average of at least last 3 sprints are to be taken into account. The reason behind this is that, it takes any team on an average 3 sprints to be able to understand the scope, team dynamics etc on the project. This metric is useful for the program / delivery team to be able to calculate the approximate timeline (in terms of sprints) to be able to complete the priority work items in the backlog. A prerequisite for this would be, those priority work items are to have either approx. story points / t-shirt size in terms of effort.

8. Release Burndown

When you are looking for the progress in completion of work items in the current sprint, a Sprint Burndown is very helpful. Now, if you plan to look at a higher level, beyond current / last sprint, then “Release Burndown” helps. Release Burndown is a visual representation of completed work items spanning across multiple sprint from start of the project till date. It is generally represented as a line graph similar to that of Sprint Burndown.

9. Cycle Time

Ever wondered how much it takes to mark a work item as complete in a sprint? Cycle Time is that metric that would give the turnaround time (once started to marked completed) of a work item in a sprint. This metric would help program, delivery managers and the team to know an approximate time that a team could take to complete the planned work item in the sprint. In order for this metric to be calculated accurately, the team would have to be diligent in providing the start date of the work item in the issue tracking tool. In cases, where the team feels that this is an overhead, then my recommendation is that, this metric shouldn’t be referred to. This metric should pertain to the current sprint and not for all sprints since the items, effort to complete the sprint would vary based on the team’s capacity.

10. Cumulative Flow

Unlike “Sprint Status” metric that displays the status of work items in the current sprint, Cumulative Flow depicts the status of all work items in the project across multiple sprints. This metric is useful to team since it provides an overview of the number of items that are in-progress / completed / blocked / cancelled till date. This metric can be represented well using a 2D matrix table with the features listed in the vertically and the status listed horizontally and number of work items in the table cell.

11. Forecasting

In a project, forecasting the work indeed helps in planning the completion of features based on priority while meeting project deadlines. The “Team velocity” metric along with past “Sprint Health” metric would help the team forecast features / work items that have to be addressed / completed in priority. Based on my experience, this activity is generally done outside the issue tracking tool since there are additional parameters to consider. However, if the issue tracking tool for your project does have the ability to forecast, it could help you plan better. In such cases, the tool would require the team’s capacity to be tracked within the the issue tracking tool since it is one of parameters taken into consideration while forecasting.

12. Resource vs Effort

In projects, where there are external team working along with the project team members to develop features, there could be a requirement from a program level to track efforts spent by all team members on the project. Resource vs Effort is the metric that would help the program / delivery team get an overview of the resources involved in the project and their corresponding effort spent across sprints. This can be visually represented in a 2D matrix table with resources listed vertically and sprints listed horizontally and story points completed by that resource in a sprint in the table cell. An easy way to get this information would be is to have the work item stay assigned to that team member when the work item is marked complete.

Given that these are few of the Scrum Metrics that I have used in my projects, the best way to represent some of the metrics would be is to have a dashboard in the issue tracking tool that you use for your project. Most of the issue tracking tools do provide widgets that you can customize to be able to represent these metrics visually through text / line graph / pie chart / interactive graphs / 2D matrix tables.

If you do come across any more metrics that has been useful for the team in your projects, do share in the comments below.

Thanks for reading!

In digital projects, I see a lot of opportunity in the way user stories are written for various teams. Based on my experience, I have come up with User Story Templates that have worked wonders in my projects. You can head to User Story Templates to know more.