Do Product Owners Know What VALUE Really Is?
The art of maximizing story points leads Scrum Teams in the wrong direction.
The art of maximizing story points leads Scrum Teams in the wrong direction.
After breaking the record of story points ever delivered, the Scrum Team was on fire. But the excitement didn’t last long; it went down during the Sprint Planning as the Product Owner asked, “How many story points can we deliver for this Sprint? We have to beat our previous one?” Developers felt locked in a trap. No matter how much they delivered, it would never be enough.
In my opinion, Scrum exists for one single reason, to help teams deliver more value for the end-user and business. Still, it’s shocking how people evaluate value differently. For many stakeholders, maximizing features defines success. Surprisingly, many Product Owners are obsessed with story points; they often push the team for more.
I’ve seen many Scrum Teams failing because the expectations are misaligned. How can a team maximize the value if everyone perceives it differently? Scrum will never work correctly until the involved people have a common understanding of value.
I’ve come across some common misconceptions of value. Let me share them with you. Hopefully, after reading this text, you will know where to focus on.
Recently, I’ve shared a video on my YouTube channel with similar content to this article; you may want to have a look at it :)
Story Points Obsession
When I got my first job as a Product Owner, delivering more story points Sprint after Sprint was my way of measuring success. I thought the more story points we completed, the more value we provided.
Every day I looked at the burndown chart, I put pressure on developers whenever it didn’t look like we would manage everything. We continuously increased the story points delivered, but did we produce value? That’s a good question; nobody cared about the real value.
Long-story-short, we were a very productive machine that generated a lot of useless stuff nobody needed. Be careful! A beautiful burn down is a sign you are locked into the same trap I was in. Delivering more story points has no connection with generating value.
If you’ve managed to produce perfect burn down charts every single Sprint, maybe it’s time to consider dropping Scrum. You can decide, plan, and predict everything up-front. You don’t need to be Agile, as you’re not doing complex work.
— Maarten Dalmijn, A pretty burn down chart usually means ugly Scrum
Feature Driven
Another common trap with Scrum Teams is to become a feature factory. It’s a similar situation as the art of maximizing story points, but with some different aspects.
The scenario is simple; stakeholders want features implemented, and Product Owners want to please them to keep a good relationship. Often, nobody questions how features generate value for the end-user and business. Delivering the feature is perceived as the value itself.
Inexperienced Product Owners frequently fall prey to feature factory anti-patterns because their repertoire lacks tools to avoid this pitfall. The symptoms of this pitfall are:
Nobody measures how the feature impacted the business and end-user.
The goal of each Sprint is to deliver more features.
Once a feature goes live, it stays there forever. Even when that’s useless, nobody dares to remove it from the product.
“Remember: at the end of the day, your job isn’t to get the requirements right — your job is to change the world.”
― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product
What Is Value?
If more story points or more features don’t mean more value. Then, what is value? Well, it depends. In short, value is the outcome, while a feature is the output.
Let me try to make it clearer. For example, implementing a social login is the output; it provides the user an alternative to sign up. However, the feature alone doesn’t mean anything. Value is the impact the social login produces. If the sign-up rate increases by 5%, that’s the value generated; more users signed-up after the social login went live. But if the sign-up rate remains the same, it means no value was delivered.
The mistake is to assume features always deliver value. No matter what you do, you will never know if the feature works for the end-users. To claim you delivered value, you need to perceive a positive development on the related Key Performance Indicator.
“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.”
― Clayton M. Christensen, The Innovator’s Solution: Creating and Sustaining Successful Growth
The job of Product Owners doesn’t finish when features go live. To maximize the value, you have to measure the impact generated by features.
Product Owners should never forget that features are a means to an end. Delivering a feature without measuring value is the same as playing on the lottery without checking the results; you will never know if you won.
How to Maximize the Value?
To maximize value, Scrum Teams need to start with the end in mind. When you focus on the wrong questions, you will fail to deliver value. You should be careful with output-oriented questions, for example:
How can we implement a specific solution?
Which features should we prioritize for the next Sprint?
How could we have a better design for our product?
Without knowing the impact you want to generate, you will miss the mark and deliver the wrong solutions. To ensure you can maximize the value, you could ask one of the following questions:
What do we want to achieve with this feature?
How do we know this feature is successful?
Which KPIs are not satisfactory to our business model?
Once you know which impact you want to achieve, you can define how to get there. First things first. Starting with the end in mind ensures you don’t build a feature for the sake of building it.
Each business has different KPIs, which is fine. What is crucial for you is to ensure you know how to measure whether the feature was successful. Then, you can decide on what to do next. Sometimes, you can improve the feature to generate the expected result, or if it proved to be a bad experience, you should remove it from the product.
“If you don’t know where you are going, you will probably end up somewhere else.” –Lawrence J. Peter
Do you want to write for Serious Scrum or seriously discuss Scrum?