Why use customer experience metrics in Agile?

The Agile community talks a lot about delivering Value and I mean A LOT. The first Principle of Agile has been “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” and couple with the 7th principle “Working software is the primary measure of progress”, we see why in general you can’t talk to an Agilist for 30 seconds without hearing something about delivering Value. Given the high priority of delivering Value, shouldn’t we have some idea of how we measure Value delivered?

Different teams and organizations measure the customer experience in a number of ways, and I believe there are some common metrics Agile can leverage from the customer experience (CX). The first metric I would recommend running is the equivalent of a Net Promoter Score (NPS). For those who don’t know what the NPS is, it is a single question organizations ask their customers, “On a scale of 1 to 10 how likely would you be to recommend our product/service to a friend, colleague, or family member?” Results are classified into 3 categories with a score of 1 to 6 being a detractor or someone who will actively work against using your product or service and informing others of this stance, 7 to 8 being neutral, and 9 to 10 being recognized as someone who will promote your product or service to others. A score of 9 to 10 most likely means they see Value in what you are doing.

What if we began asking our customers a similar question after a planning session, sprint review or demonstration? “On a scale of 1 to 10 how likely do you feel what you have just seen will add Value to the organization?” You get an immediate sense of if your customers Value the work the team has just completed, the product owner can schedule follow ups as needed, and you have a data point you can track over time much like a cumulative flow of story points delivered but instead having a cumulative flow of value delivered.

Another metrics that I have seen both Agile and CX have in common is the customer satisfaction score. Agile looks for feedback on a continual basis, but does your organization have a way to track the feedback over time? I would challenge most teams to think back 3 to 4 sprints about feedback they received. Unless the team has a way to look back on their history, and some do with a retrospective log, most teams are completely focused on the current and next sprint, not the past. It is the nature of Agile, particularly for high performing teams, to focus on the here and now. However, I believe part of my job as a Scrum Master is to help the team celebrate how far they have progressed and having a historical metric that can show the team how they have improved in the eyes of their customer can be valuable. In addition to this metric, having a periodic end to end review of all the work completed through multiple iterations can help solidify the advantages of iterative development when coupled with a metric like customer satisfaction and can be a great motivator for teams.

What about applying CX metrics to team members? Most teams I have worked with at some point complain about how many meetings they have to go to or how other tasks are keeping them from their primary work. This is similar to a number of customers I have heard complain about how long it takes to complete a task with a service or product. When a CX team wants to improve the customer experience they often measure “time on task”, or how long it takes to complete certain steps in the user journey. Applying this same metric to what your team is doing during a sprint can help you understand if drive-bys, meetings, and other tasks are keeping your team from reaching their highest performance. Tracking the amount of time they spend on tasks and meetings during several sprints can validate or disprove the team’s concerns very quickly. It’s up to your organization to determine what an acceptable limit is for your teams, but I have found that working to lower the time this metric measures on tasks outside the primary focus of the team can pay very large dividends over time.

Agile promotes team independence, self-organization and holding one another accountable, but not all organizations are comfortable with this concept. By showing the organization that you are measuring the Value you are delivering, keeping in mind that Value delivered to your customer is the primary measure of success, and that you are looking within the team to streamline process can go a long way to helping the organization understand and accept Agile as a working methodology.