Reading9 metrics to make your sprints more customer-centric
blog

9 metrics to make your sprints more customer-centric

hero

Sprint reviews through retrospectives and frequent stand-ups are arguably one of the most important parts of product execution. They can help you proactively identify blockers, flag scope creep, and make important decisions around resource allocation. But are your sprint reviews measuring the right outcomes?

Traditional scrum metrics can run into extensive lists that cover developer productivity, user stories, defect densities, time to market, and so on. Measuring these aspects is undoubtedly important, but not all metrics are created equal. At best, having to keep track of a long list of metrics can make stand-ups less productive and hamper sprint performance. At worst, it can blur the actual customer impact of sprints and reduce developer motivation.

So what should sprints measure?

Product development in SaaS must be rooted in continuous discovery, continuous integration, and continuous deployment. New feature requests, bugs, and customer inputs flow in from various channels and products need to keep evolving. Agile sprint planning should revolve around the customer’s voice and prioritize work that has the highest impact. Metrics to measure the success of each sprint cycle should reflect this goal.

Sprint metrics to measure impact

The Build app in DevRev strips down sprint analytics to the actual metrics that showcase customer impact and development velocity. Unlike traditional sprint metrics, the Build app gives you complete visibility into how many customer-initiated issues are being worked on and what product parts they are connected to. This gives developers more context into how their work in sprints affects the overall product and end-user.

Get started with DevRev Build for free

1. Sprint burndown charts

Sprint_burndown.png

Sprint burndowns can help you track the progress of a sprint and the likelihood of completing all issues assigned within a sprint. They can also flag scope creep, which could impact the success of a sprint. Most burndown charts, however, only show you progress against issues, without differentiating between the type of issues worked on. In DevRev, sprint burndown charts give you visibility of internal issues remaining and customer issues remaining. This helps you keep track progress against issues that impact customer experience.

2. Sprint health

sprint_health.png

The sprint health chart gives you a snapshot of how each sprint is progressing. It helps you identify what the scope creep for that sprint cycle is, how many issues are remaining, and the remaining days for the sprint to complete. Keeping track of this chart can be a quick way to gauge sprint performance and the likelihood of completing tasks assigned in the sprint.

3. Enhancement count breakdown

sprint_enhancements.png

Enhancements in DevRev are similar to Epics in the agile methodology. Each ‘enhancement’ is connected to a product part and is broken down into a set of ‘issues’ for developers to work on in sprints. Enhancements can be created from customer feature requests or internal product roadmaps. In DevRev’s sprint insights, you can get a breakdown of how many issues in the sprint are from customer-initiated enhancements and from internal requests. This helps you understand how much development effort is going towards solving for the customer. Developers also have direct visibility of how their work is impacting the end-user.

4. Maintenance count breakdown

sprint_maintenance.png

The maintenance count chart shows you how many issues in the sprint are related to bug fixes to maintain the stability of the product. This is also broken down into how many issues were initiated by customers and how many were raised internally. The split between maintenance issues and enhancement issues also indicates how much development effort is going towards maintaining product health versus building new features and product improvements.

5. Issue breakdown by stage

sprint_issues.png

Issues move through different stages in their lifecycle:

  • Triage: All issues are in triage by default. Through regular backlog grooming, issues can be picked up from triage and moved to a sprint. In DevRev, issues are connected to customer tickets (if initiated by a customer), so you can easily prioritize which ones to move to a sprint based on the customer impact.
  • Prioritized: Issues marked ‘prioritized’ are moved to the next sprint cycle
  • In Development: Issues marked ‘in development’ are added to the current sprint cycle
  • In Review: Issues are marked for review if they need another round of evaluation
  • Completed: Issues marked completed are closed automatically

Issue breakdown by stage shows you the split-up of issues in the current sprint so you can track if there are any blockers to completion.

6. Issue breakdown by owner

sprint_owners.png

Each issue is assigned to an owner who is responsible for its completion. The issue breakdown by owner helps you see how work is distributed within the team in a sprint cycle. This can help you see who your top performers are and identify if there are any team members who are overloaded so you can move around work accordingly.

7. Issue breakdown by priority

sprint_priorities.png

Issues are categorized as P0>P1>P2 in order of priority. Issue breakdown by priority shows you how many high-priority issues your team is working on in each sprint. This gives you visibility into whether your team is working on issues that are the most critical and time-sensitive.

8. Issue breakdown by part

sprint_parts.png

In DevRev, every issue is mapped to a product part. This could be a capability (a fundamental part of your product), a feature (a set of features power a specific capability), or an enhancement (feature improvements coming up). An issue breakdown by part shows you how each sprint relates to the overall product evolution. You can see what parts of the product are most actively being worked on and where most of your development effort is being channeled.

9. Avg time issues spend in each stage

sprint_avg_time.png

This chart shows you the journey of an issue from the time it is raised to completion. It lets you identify any bottlenecks that might be impacting the speed with which issues are resolved.

These sprint metrics make it easier to track sprint progress and keep retrospectives focused on end-user impact. Developers also become more motivated to work on sprint issues as they can see how each task affects the product and customer.

Get started for free with DevRev Build, a Product CRM that brings your developers, product managers, and designers together so you can build with and for your customers.