As part of their responsibility to help Voyage teams coordinate their actvities Product Owners and Scrum Masters should collect, measure, and share various metrics with their team. The goals of this effort are to:
- Create measurements everyone on the team can use to monitor progress
- Identify and implement the least number of metrics to accomplish this goal
- Review the metrics in both the Sprint Planning and Team Retrospective meetings
Remember that Voyages are only 6-weeks long. This will limit the scope of the metrics you are able to collect and use. As a Product Owner or Scrum Master you want to focus of your efforts to be on the overall project rather than on collecting metrics. In other words, you want the metrics you use to be useful, but you don't want them to take time away from reaching your project's MVP.
So, what metrics should you collect. We suggest these may be a good starting point:
| Metric | Source |
|---|---|
| Remaining PBI's vs. total PBI's | Product Backlog |
| PBI's completed by team member | Product Backlog |
| Average no. sprints required per PBI | Product Backlog |
| Burndown chart for teams using story points | Product Backlog |
| No. commits to Main branch/sprint | GitHub repo - Insights - Pulse |
| No. main branch commits/sprint by teammate | GitHub repo - Insights - Contributors |
| No. PR's to main branch/sprint | GitHub repo - Pull Requests |
| Average time for PR review/sprint | GitHub repo - Pull Requests |
You might choose a tool or service in which to track and share your teams metrics. But, given the short lifespan of Voyage a good place would be in a spreadsheet maintained in the team repo or as a simple Markdown table in the repo.
Keep in mind that your metrics should be graphically rendered in a format that's easy for teammates to understand. But, it doesn't have to be highly polished. What matters most is the content.
There is a difference between team metrics and team statistics. Statistics are a standalone measurement while a metric is something you can gain a higher level of understanding from. Taken by themselves, metrics are more valuable than statistics.
For example, collecting the number of PR's to the main branch is a helpful statistic, but collecting this by sprint provides an indication of the rate in which the team is releasing features and fixes to the user.