Here at Corevist, we deliver our core product, Corevist Commerce, through a multi-tenant SaaS (software-as-a-service) model. We take care of all updates, innovations and bug fixes, which leaves our clients free to run their businesses rather than worrying about a complex technology stack.

Because our cloud-based platform includes comprehensive integration to SAP ERP, things get pretty complicated. When it comes to managing and updating our core product, we need a way to ensure we’re using our resources efficiently and delivering on our development commitments.

That’s why we’ve created our own system for tracking this. We call it the Corevist SprintScore.

Here’s how it works — and what it means for our clients and our team.

Corevist SprintScore in a nutshell

Essentially, our SprintScore provides a barometer on the health of our weekly software development sprints (which are a core part of our product management process). This score defines how well we’re delivering on the value that our clients need most in the core product. While SprintScore doesn’t define which things our team should work on (we determine that through a separate process), it does express our confidence in our ability to deliver those things and whether we actually deliver them.

Our SprintScore includes two measurements computed for each weekly sprint.

Measurement 1: CapacityScore

Essentially, this estimate is a sum of the hourly estimates of all the tickets we’re committing to in the sprint. We spend two hours every Wednesday morning planning our weekly sprint for the coming week. This measurement helps us gauge how much work we should commit to at the beginning of a sprint. In a nutshell, we’re asking one question: How well equipped are we to deliver the tasks for this sprint?

Calculating this is actually pretty simple.

• Example 1: 100 estimated hours / 125 hours available = 0.8. We subtract this from 1.0 to get 0.2, then multiply by 10 to get an integer. Capacity utilization = 2.
• Example 2: 100 estimated hours / 200 hours available = 0.5. Capacity utilization = 5.

The higher the number, the more available reserve capacity we have. The lower the number, the higher our estimate of utilized capacity is.

Measurement 2: DeliveryScore

Here, we’re asking one question: How much of our commitment did we deliver on at the end of the sprint?

The calculation is simple.

• Example 1: 20 tickets completed / 20 tickets committed = 1. We multiply by 10 to get an integer. Completed commitment score = 10.
• Example 2: 20 tickets completed / 25 tickets committed = 0.8. We multiply by 10 to get an integer. Completed commitment score = 8.

As you can see, a higher score means we did better on delivering, while a lower score means we didn’t do so well.

What SprintScore means for our clients

Our clients don’t have much visibility into this process (or our SprintScore for any given sprint). However, the fact that we’re managing this so well directly impacts our clients.

Every time we update our core product through a weekly sprint, our clients gain value in terms of new features (some turned off by default), bug fixes and updates. Our SprintScore system ensures that critical updates don’t get left out of the sprints in which we planned to address them. Ultimately, that keeps our product evolution rolling at a healthy clip and ensures our clients’ solutions remain secure and user-friendly.

What SprintScore means for our team

Because the SprintScore calculations are so simple, they empower our team to see what matters in any given sprint (and what doesn’t). Our team gets reassurance that they’re working on the highest-priority tickets, and that makes it easier to focus on the job at hand.

No one likes to get a subpar SprintScore, but even lower scores are helpful. They show us where we need to improve, and they give us the opportunity to review existing processes and find ways we can improve. Ultimately, that’s good for our team because it makes us more valuable to our clients.