Mastering the art of Prioritizing by Business Value [Mind the Product]

As an agile product owner, you’re constantly trying to distinguish your products from the competition. Your secret weapon is your ability to prioritize your product backlog by business value, continuously. You’re well aware of this, but we would argue you could prioritize better.

As a product owner, what are the first questions you ask yourself when you begin to prioritize your backlog by business value? They should be:

• What feature in this software has never been done before?
• What do my end users really want to see? What will blow them away?
• What could potentially hold up release?

The reason you prioritize with these questions in mind is because you want to force development of the features that need the most eyes on it before launch. If the secret sauce of your new or updated product is an innovative shipping functionality, then you should build that shippable increment first. Leave login, a standard functionality, until later in the development process. This will prioritize continuous feedback on the feature that brings the greatest business value to your company. By the time login has been built, you will have had weeks or months of additional touchpoints on your key innovative shipping feature.

Let’s explain by using an analogy we all can appreciate: hosting a dinner party. Quality code, pleasing design, and a slick user interface of your software are equivalent to delicious food, inviting decorations, and seamless hosting. Similar to building a software product, pulling off a dinner party involves various skills and slices of exemplary output.

Like to building a software product, pulling off a dinner party involves various skills and slices of exemplary output

Finish the Most Important Thing First

Imagine you have invited 10 close friends over. You are renowned for the intricate desserts you bring to parties, but you have never hosted a dinner party on your own. In this scenario, your friends are your end customers, not your testers!

The novice planner will naturally start drafting the dinner menu by choosing the appetizer recipes, then the main meal, sides, and finally the dessert. They’ll probably fret about the napkins and music selection. Their day job is as a product owner and they see some similarities here, wanting to plan in the order their guests will be consuming the food and atmosphere – more or less these are shippable increments for their guests. And they’ll carry this approach through to the day of the party, decorating first, as that’s what the guests will see upon arriving, and then preparing the menu in the order it will be consumed.

You, being a more advanced planner, consider that your guests (customers), first and foremost, want and expect an exquisite dessert. From your baking experience you know making the dessert will likely take the longest, and requires some batch testing the week prior to the party (Note: you’re really into baking so this isn’t absurd). If the initial dessert you want to make doesn’t work out during batch testing, you’ll need to pick a new dessert. And that may change the timing of the whole dinner party prep, thereby affecting the rest of the menu. So, there is no point starting with designing the whole menu if the star feature isn’t yet nailed down.

This is what the top four stories of the novice and advanced planners might look like:

Novice

1. I want the menu planned so I know what ingredients to buy.
2. I want a list of decorations to buy so the table looks nice when people arrive.
3. I want to know the timing to prep and complete all the dishes so I know it’s possible to complete all dishes the day of the dinner party.
4. I want appetizers to be ready as soon as my friends arrive so I can serve something with the drinks.

Advanced

1. I want to choose a dessert that will help me remain well known for my desserts.
2. I want to know the timing to prep and complete all the dishes so I know if it’s possible to complete all the dishes the day of the dinner party.
3. I want the menu planned so I know what ingredients to buy.
4. I want the dessert prepped and completed first so I don’t have to rush completing it before people arrive.

The user stories don’t look terribly different. But if the dessert is the known draw to your party (other than your winning personality), the novice is at risk of failing. There are as many moving parts in a dinner party as there are in developing software. I don’t need to extend the analogy to imagine the novice ran out of time to make dessert. We’ve all hosted people before and could write a long list of snags we encounter at critical moments of prep: out of propane/charcoal for the grill, just dropped the last egg on the floor, forgot to thaw the butter, the power went out.

Why it’s Time to Stop Thinking Linearly

When we talk about the agile Scrum process, we generally focus on how it benefits and empowers developers. However, the real value is that the very nature of Scrum – building small vertical slices of working software each sprint – creates an opportunity for product owners to demonstrate immediate business value. By working with your stakeholders and customers to prioritize the backlog by business value, you can deliver relevant shippable increments to them on a consistent schedule.

Building software linearly, on the other hand, can erode this value and delay the opportunity to receive customer feedback on the product’s most important features.  A more business-friendly approach is to focus the team’s efforts on building something essential that your customer both needs and wants, and make it immediately shippable. From there, you can analyze how the functionality is used and what might need to be changed to provide additional business value. We all know the real test of a product happens when your customer gets their hands on it. Put your efforts into expediting that process.

The real test of a product happens when your customer gets their hands on it

Take an e-commerce application for example. You have created a process flow that shows a customer browsing items, adding items to a cart, reviewing the cart, selecting shipping, and checking out. Thinking linearly, you may write a user story for each step of the process and prioritize developing the user stories in the same order as the process flow. However, the secret sauce of your application is an integration with an innovative fulfillment center that will delight customers and crush the competition, so you move the integration user story to the top of the backlog, even though it is one of the last steps in your process flow. After all, that is the functionality that will differentiate your product. In addition, the data requirements of the integration may inform the design of your online ordering process. If you think linearly, you may not get to that integration feature until three months in and then find out your technology doesn’t support it.

If you abandon conventional linear thinking and instead focus solely on business value, you will reap the following benefits:

• Thinking about the most important things early:  The team will have more time to design and iterate on the most important part of the product
• Accelerating risk:  The most important product features can often be the most complex, so the earlier the team can test assumptions and uncover issues, the better
• Exposing functionality to users for as long as possible: By completing the most important parts of your product first, that functionality can spend more time in the hands of your stakeholders and beta testers, providing valuable feedback
• Ensuring the most important functionality is ready to ship: If you need to cut scope to make a release date, you will know your most important features are ready
• Shipping early:  Your most important features may provide so much value that you decide to defer some user stories to the next release and ship ahead of schedule

Put yourself in the shoes of your stakeholders. If they attend your first sprint review and are shown login, the footer and the header, you may lose their attention early on in the process. Whereas, if you demonstrated the newest innovation they’ve been requesting, you’ll hold their attention and garner more feedback throughout your entire development process. It’s like having the glistening dessert on display as soon as your guests arrive. Even if your appetizer is lying on the floor because you tripped, and the smoke alarm is going off because you’ve never roasted a chicken, your guests are still engaged and waiting for dessert to be served.

Goodbye Linear Development, Hello Business Value

To make the best use of your secret weapon, continuously ask “If my customers could only have one user story completed, which would it be?”  Continue to challenge your development teams to abandon conventional linear thinking, and be prepared to pivot in response to changing market conditions or opportunities.

Not only will this ability to change priorities give your development team an advantage over the competition, but it will also provide your customers with an advantage over their competition. In short: everyone wins.

The post Mastering the art of Prioritizing by Business Value appeared first on Mind the Product.

Source: Mind the Product https://www.mindtheproduct.com/mastering-the-art-of-prioritizing-by-business-value/