5 Metrics to Measure Success on Your Software Project

Metrics can be a tricky thing. They help a team understand how they are being measured, which means they can be gamed to look great — hiding issues under the surface.

My general guidelines are that metrics should be:

  • Easily understood by the entire team.
  • Visible to the entire team.
  • On the chopping block at any time.

With that in mind, here are three documents and five metrics that I think are useful to all software project teams.

High-Value Ready Backlog

When priorities shift on a large Agile project, work that was previously high value and ready for development can move out of scope. That work remains in the backlog because it needs to get done eventually, even though it’s not high value right now. The traditional Ready Backlog metric doesn’t account for this. The Product Owner may be unaware that the runway of critical-path work is short.

The High-Value Ready Backlog instead categorizes each user story as “high value” or “not high value,” then reports how many sprints of high-value work remain.

Categorizing the stories will depend on the tool you use to manage your backlog. It should be something that can be applied to each story and can easily be filtered on. You should work with the Product Owner in a cadence that makes sense (weekly, bi-weekly, etc.) to discuss all new user stories and determine which are high value.

Metric 1: Number of High-Value Sprints

Number of High-Value Sprints = High-Value Points / Team Velocity

Report the metric out with a “Health” status that makes sense for your team. On our team, 4-6 sprints is green, 2-4 is yellow, and under 2 or over 6 is red (high risk).

Burn-Up Chart

A burn-up chart is a visualization that plainly your target, your projected velocity, and your progress. It wraps up several metrics, including total scope, progress, and projections. It’s typically generated after every sprint to account for updates.

Example Burn-Up Chart
A hypothetical project burn-up example, highlighting scope creep, scope control, and an on-target projection.

Metric 2: Total Scope

Total scope is the total number of points for the level of burn-up you are creating. On smaller projects, it could be the entire scope of the project. On larger ones, it may represent the scope of the current milestone.

Tracking total scope helps us identify scope creep. If the total scope line grows every sprint, it can help us trigger a conversation about exercising scope control. Tracking total scope also helps show us when the project is nearing completion.

Metric 3: Points Completed

Points completed is the cumulative total of points completed as of the last sprint. This metric helps show the progress the team is making. It can be a big morale boost to teams that are working on large projects because they can see that they are making a dent in the overall project work. It can also help us identify process experiments that are going well by visualizing trends in velocity.

Metric 4: Projected Points Completed

Projected points completed is the estimated total of points completed for future sprints:

PPC = Projected Velocity + Total Points Completed (as of last sprint)

There are several ways to calculate your team’s projected velocity. I’m partial to Pivotal Tracker’s method. They project velocity as the average of the team’s velocity for the past three sprints, with the ability to include a team strength modifier.

Projected points completed helps us understand where we will be in N number of sprints. It also helps us understand how long it will take the team to complete the total scope of the project or milestone. It can be used to guide conversations about efficiency, cutting scope, or adding capacity.

Risk Tracker

Tracking risks is critical to your project’s success. This should be done in a single, easily visible document that outlines historical and active risks for the project. The document should clearly define the different severity of risks. For example, “High” might be defined as a risk that is in danger of blocking development within three sprints.

Tracking risks demonstrates to key stakeholders that your team is being proactive about identifying upcoming risks and attempting to mitigate them before they materialize. It also creates a historical audit of all risks that your team has managed to avoid or mitigate.

Metric 5: Active Risks

I suggest reviewing and updating your risk tracker no less than once a month. I like to break the meeting into three exercises. First, review active risks from the previous session. Update the mitigation strategies if needed, or mark the risk as no longer active. Second, identify any new risks and document initial mitigation or avoidance strategies. Lastly, discuss if any active risks need support from the organization, outside the current team. Flag those so they can be escalated up within the organization.

Bringing it All Together

Tracking all of the things above will help you understand if you are on track, where there might be dragons, and how you can help the team improve.

It’s important to make these metrics highly visible to the entire team. One strategy for this is creating a single document every sprint that pulls in all of the metrics gathered that sprint. (For metrics that you gather on a different cadence, only include updates when a new collection happens.) Make sure the team has access to this document, and make sure they know you are available to answer questions or collaborate on ways to improve.

What other metrics have you found particularly helpful to demonstrate progress, project completions, and measure experiments?