4 Agile Metrics Every Business Analyst And Product Owner Should Care About

It is true that “working software is the primary measure of progress” in Agile, but that is not our only measure. The Agile Principles also call us to reflect on […]

It is true that “working software is the primary measure of progress” in Agile, but that is not our only measure. The Agile Principles also call us to reflect on how to become more effective.

As business analysts and product owners, we should care about metrics that provide value—that give us insights into our team’s ability to effectively and efficiently deliver working software that delights our end users and customers.

There are dozens of possibilities, but here are four of my favorites with a few thoughts on the value they bring to the business analyst and product owner roles.

 

Carry Over

Carry Over measures the amount of work pushed from one Sprint or iteration into the next. While this metric can shine a light on many team challenges, business analysts and product owners should be most concerned about “user story scope creep.”

Consistent carry over points to user stories that are too big going into the sprint or are growing in scope as the Sprint evolves. Either way, it means the stories were not analyzed and properly sliced before they entered the sprint. This slows delivery dramatically as teams waste time analyzing, slicing and reprioritizing during the Sprint.

Smaller chunks of work improve the team’s ability to estimate accurately and deliver value without carry over. Look at your user stories closely to determine if you are effectively slicing stories into small, independent increments of value. Analyze the story slices and break them down until each story is “finishable” within your standard iteration duration.

Also, before estimating, it helps to have the product owner, business analysts, tech lead and quality assurance meet to discuss each story. This ensures the right dialog to identify when a story is too big and at risk for carry over.

WIP – Work In Progress

WIP is a measure of how much work the team is doing at one time. The team’s WIP should be the least amount of work (or user stories) that they can handle while staying busy, but not more than that! Any more will slow the team down by pushing out iteration delivery dates or creating more carry over.

Why is this important to business analysts and product owners (PO)? Because product owners own what gets put into the work queue and business analysts help the product owner define this. We are critical to defining the flow of work. This means product owners need to say “NO” to new work so the team can stay focused until they deliver their current iteration.

The team works together to define its WIP limits to maintain a consistent flow of work. The product owner and business analyst make sure that items are ready to flow into the team when the team is ready to pull more in. The goal here is to “stop starting and start finishing” work. You know your team has too much WIP when the team keeps starting new work rather than finishing what they have started.

Release Frequency

You might think of the release frequency metric as more management or technical in nature, but it is often a great indicator of the effectiveness of business analysis. The better business analysts and product owners are at defining small increments of value and minimum viable product then the more often teams can consider releasing.

There can be technical process challenges that impact release frequency, but the root-cause usually leads back to defining a releasable chunk of work that matters to the user. This requires business analysis! Business analysts and product owners define the releases. They analyze processes, user needs, user experience and technology to slice user stories into small, independent increments of value.

Number Of Backlog Items NOT Done

This metric is about focusing on the future, rather than fixing the past. Many teams are dutifully focused on getting through the backlog. They just assume it all needs to get done and think of it as a giant checklist.

Effective business analysts and product owners assume that 25-50% of the backlog will not get done. (This percentage is even higher for some teams.) business analysts and product owners continually refine the backlog to make sure the team is working on the most valuable, highest priority items that keep end users and the organization moving forward. This refinement often means removing things from the backlog that don’t belong because they keep the product in the past vs. creating the future.

So, measure the number of things NOT done and see how much you are saving the organization by NOT doing things, and focusing on the future rather than the past!