A Metrics-Driven Approach to Agile Planning

Using metrics for long-range planning is a great way to build confidence from your stakeholders that your team will deliver. Metrics and data bring a lot more merit to the table than a feeling or an opinion, but you must be careful to use metrics appropriately or they can do more harm than good.

We’ve got some great ideas for how you can get metrics, what to do with them and how to use them for the team’s benefit.

Establish the Team’s Velocity

Before you can establish any kind of team metrics, you’ll want to understand the team’s velocity—the sustainable pace at which the team can deliver work. In order to do this, you’ll need a sticky team (one that stays together), a consistent method for estimating work as well as a few sprints under its belt.

If you’re constantly shuffling people from team to team or disbanding the team after a project completes, it will be nearly impossible to establish a steady pace.

Use Confidence Intervals for Delivery Dates

If you’re used to being asked when a feature will be done and you either blindly agree to a date or spend an enormous amount of effort putting together a Gantt chart, we’ve got a better approach that you can try. Confidence intervals are a statistically proven approach to predicting data elements, but are quite complicated to explain. We will try to make it easier in our approach below (no math involved, or barely any math).

If your team has been together for at least 10 sprints, take a look back at the team’s historical velocity. That number should reflect the completed story points the team achieved in that sprint. If a story was not done, the points get counted in the sprint where the work was finished.

Let’s say your last 10 sprints looks something like this:

  • 23
  • 30
  • 25
  • 18
  • 31
  • 28
  • 22
  • 19
  • 24
  • 29

Next, you’ll want to establish a velocity range by eliminating both the lowest and highest numbers at the same time until you’re left with the middle 5 or 6 numbers.

At first pass, I’m going to take out the lowest number, 18, and the highest number, 31. I’ll then take one more pass and remove the next lowest and highest, 19 and 30. This leaves us with the middle 6 velocity numbers, establishing a range of 22 to 29.

This is the Confidence Interval technique and it’s statistically 90 percent accurate. So the team can say with a 90 percent confidence level that it can deliver between 22 and 29 points a sprint, assuming the team dynamic stays consistent.

Now, when the VP brings the team a new feature, the team can use story points to estimate the feature. Let’s say the team says the feature is 90 story points and they work in two week sprints.

If we take 90 and divide it with the low number of 22, we get roughly 4 sprints. Taking the high number of 29, we get around 3 sprints. Therefore, if the team were to use all of its time working on the feature, they can say with 90 percent confidence that it will take 3-to-4 sprints to deliver. They can then translate that into actual calendar dates for their stakeholders.

If your stakeholders aren’t used to getting a date range and are balking at this idea, remind them that this approach is going to be a lot more realistic than falsely agreeing to a date. Also, ensure them that as you begin working on the feature, you’ll know more and be able to hone in on a smaller target date.

Keep Velocity for the Team Only

While velocity metrics are great for the team, they can quickly get abused outside of the team. Since story point estimation is all about a team comparing one piece of work to another, each team or product group determines its own scale. A story that’s a 3 on one team or whole product group may be a 13 on another.

The team should use velocity to become more predictable to stakeholders, rather than to maximize the number of story points (doing that can cause the team to quickly inflate the numbers).

A better metric that leaders can use to gauge the team’s performance is how well the team is doing at meeting its commitments. We’d like to see teams completing 100 percent of the planned work 80 percent of the time. All of the time and the team isn’t pushing itself to get better. Less than 80 percent and the team is too often letting down stakeholders and customers.

Metrics can be your best friend or worst enemy, so understanding how to use them properly to gain alignment and success for your team.

Lance Dacy is a Certified Scrum Trainer who’s passionate about applying Scrum beyond technology to all areas of business and life. If you’d like to become a Certified ScrumMaster® or Product Owner, check out the upcoming class schedule.


Related Articles

Metrics Drive Behavior...Right?

From the beginning of our existence, we have been surrounded by various forms of leadership. Whether the leadership was good or bad, that is a different question. We can agree though, that good or bad leadership sets things in motion. As I work with various organizations, I encounter the same...

Read More

Agile Metrics...To use or not to use?

Metrics are not always harmful in an agile team, but if not used appropriately, they can be detrimental. Agile is a value- and principle-based approach that stresses people and interactions over processes and tools. Agile prioritizes the delivery of working products often, adapting to change, and interacting with customers and...

Read More

Certificate of Occupancy

Have you ever been in your building and noticed a “Certificate of Occupancy”? These gems enforce a safe occupancy number that are built around fire codes. How many people could realistically exit this building in the case of a fire? My question, as it relates to software development and Scrum...

Read More