Celebrating story points vs real customer value

Introduction

As developers we're usually part of a team. Our primary goal is to build something useful for the business and the company we're currently working for. But why are we building it, what are we building, and how do we know we've built the right thing? In this post we'll look more into the how do we even know?.

Once upon a time in PowerPoint

Ever seen a demo from a team with the following PowerPoint content?

"Story points estimated"

"Story points achieved"

"X stories finished and Y bugs fixed"

"Great work team!"

It's interesting right. What are we actually saying here? And why do we even care? Do the customers care? Do the developers care? Is it important for management to know we're crunching stories? Did our story point velocity increase or decrease?

This type of PowerPoint is not very uncommon to see in development teams unfortunately. This is how we as developers are "raised" basically and how we traditionally have measured whether a team is performing well or not. It's a way to measure and see that yes indeed, once again we crushed our stories and now management or the product owner is definitely proud again! Great job team! Let's now start the next sprint and do the same estimations again, and meet up here in a couple of weeks and look at the same numbers to see whether we're performing good!

It's not uncommon for these teams to constantly be busy, whether that's in a meeting or writing code. Being busy is a good thing, because it means we have good resource utilization, and we are currently doing our best and focusing on our primary goal, which is to deliver stories. Well, traditional management believes so at least.

We've just seen that the traditional purpose of a development team is to deliver stories (functionality) for the business and the company in which we happen to currently work for. So what are we actually delivering? Stories. That's all we really know. And this is usually where the interest ends for the team.

This is very sad, because it means in the best world we have stories (functionality) delivered to end customers that are somewhat used, and in the worst case no customer uses or even likes the features we've developed.

Some people think it's up to business to make sure they request relevant stories from the development team, and that business follows up on the stories and make sure that they are used by real customers. But how do business know? They might know that something is used in the sense that "we actually did sell the product, so it's definitely used in some way". But most of the time it's not a thing you build and sell, it's a stream of features evolving over time, and business have absolutely no idea what features are used and which are not.

Now it's easy to believe that it's still business responsibility to understand and/or track what features are used, but this is really hard. How would business know what page are viewed most, what buttons are pressed, which push notifications users interact with and which push notifications are noise? Do customers even download the invoice by clicking the mail in the email or do they just download the invoice from the invoice page on the web? Maybe it would have been enough value of just building the invoice page on the web and skip spending 2 weeks to build a custom email template that no customers seem to interact with much anyway. All these questions are relevant but also very hard for business to find answers too so business and development teams needs to work together on this. It's time to enter another perspective of a development team, the value driven approach.

Value driven

What is the behaviour of end customers and do they use our application? Can they accomplish their tasks within the application? Do they get a lot of crash reports? Is the application very slow and response times so high that the human eye will notice it? During the last 3 months, have customer satisfaction increased or decreased?

A value driven team is a team that realize that the important bits for our team is not to constantly be busy, but rather to continuously deliver value to our customers (note here I said deliver value and not stories). Teams summarizing their work and measure success in terms of story points are usually focused around being busy, whereas teams that summarize their work by talking about end customer behaviour are focused around delivering real customer value. Delivering value is our primary goal and why we're hired, nothing else.

So with this in mind, think about it: what real value are we actually creating as a team?

Another example: the last four weeks we've built stuff and released it to customers but is it even used by the customers? If you ask a team focused on crunching story points the answer is really very often "we do not know that", whereas if you ask a value-driven team the same question they might not have an immediate answer either, but they definitely have a way to look it up without too much hassle. They realize that being able to answer such a question is important, because if they can't then they also don't know if the stories they completed provided any value to the company. And creating value is the reason why we're building products in the first place.

Traditional vs modern

Hopefully it's now becoming more obvious that it's worth to question the traditional approach of measuring story point velocity vs questioning what value we are creating as a team. Traditional management cares about story point velocity because for them it's of uttermost importance that teams are working 100%. Modern management doesn't care about if people are busy all the time, but rather they're very interested in how customers appreciate the application we're building. Traditional management will say that if you have an hour over and have nothing to work on, start working on a new story in the backlog. Modern management will say it's not worth to start something new and bring that complexity into our current set of ongoing features. One is obsessed with avoiding slack-time at all costs, the other doesn't care that much if people are free a few hours here and there, as long as value is created.

How to be more value-driven

An organization or team likely won't change the way they work over night, so we can bury that idea into the ground straight away.

But can we start small? I think we definitely can! It's less about the tools to use, and more about doing something to make it possible to see customer interaction of your site and/or app. Let's say the development team already have a logging framework in place and/or metrics of the system. When users navigate in the app and an error occurs the developers can see this. This information is valuable to developers but not really that interesting for business.

So what can we do to better understand the business-value of our app? Let's take an example: If you're building an app for charging of electric vehicles and you have two buttons in different views that allows a user to enter the edit profile section. Let's now imagine we want to understand which of these buttons are actually used more frequent and has "more value" in that sense. To understand which button has more value we can add an additional log statement in code whenever each edit profile button is pressed. Now when we have this information logged we can choose to either manually extract the data each week by issuing a query to our logging database (or wherever logs are stored) and compare how many edit profile button clicks we have. We can also display the total number of edit profile clicks on some other monitoring tool like Grafana!

The above example can very well seem trivial and too easy, but compare it to the alternative when you don't track it: the product owner walks into the room and says:

we will remove this view here where the customer can click edit profile because we're not happy with the layout of this view

What if this view has the edit profile button that customers actually click on a lot? With metrics you know it. You might not know why customers click it, but you do know they click it. To understand the why behind it requires more qualitative research is not something I wanted to dig into in this post, but you at least now know and can respond with:

Well wait a second, this piece of view here and that button that allows a customer to edit their profile is actually the button that gets a lot of attention, do we really wanna remove it? I mean we can maybe re-design it or something instead? Anyhow I think we should have a conversation about this before removing it because it's very frequent used and I think it could potentially upset the customers if it all of a sudden is not there.

Don't you agree this piece of dialog is the foundation of creating more value to an organization rather than celebrating and taking a beer or two because your story point velocity increased?

Conclusion

In the traditional approach the culture of the team is to talk less about real customer value, but they care about being effective and 100% busy. Having 7 stories in-progress is a good thing in the traditional approach because it means if one story gets blocked you can immediately switch to another story. Again 100% resource utilization.

In the latter approach the manager doesn't care if the team is 100% busy or not, but delivering value to end customers is what makes us fulfilled.

This all leads us to naturally stop talk about story point velocity, and instead talk about the value we create for customers. So in the next PowerPoint, hopefully you won't ever see any more burndown charts and instead see some metrics of how the system/app is used so that you have something that matters to celebrate.