Let's talk about value, not priority
What's the impact of a story?
Last week, I wrote about how to prioritise when everything is a priority.
I suggested picking out the risks, dependencies, and biggest stories to work on first.
However, this is more of a practical approach to unblocking future work. Crucially, this assumes you’ve already made sure that the stories belong on the backlog in the first place.
A better way to order your backlog is to bring the stories with the greatest value to the top.
The Kano model
This post on the Kano model is a good explanation of basic features and delighters in products, and how they differ:
Using the Kano Model to prioritize product development (Mind the Product)
I like to think of “delighters” as quality of life features. These could be things that can save the user time, no matter how small. For a process that is followed regularly and repeatedly such as entering data, these savings add up.
The impact of a story
Meanwhile, this post is a great guide to how you can measure the impact of a user story:
Measuring the impact of each user story (Product Talk)
In this example, we need to look at what value could be realised by adding or enhancing a feature. It could be a big change such as supporting small businesses when you only have options for individuals. Or it could be extending an integration to refine how data is passed back and forth.
In either case, being able to estimate the potential value at a logical future point in time will allow you to compare the user story against other stories.
All stories compete for time – and we can’t build everything. Choosing what to build should be an informed decision – not a stab in the dark.
10 Tips for Product Owners on (Business) Value (Scrum.org)
Put your clearest stories first
While the product backlog is not a wishlist, you’ll probably have some stories that are better defined than others.
This is especially true in the early stages of a big project. It can also happen with a new team – or if you’re new to an existing team.
And there may be pressure to start pushing stories to the development team – perhaps before you’re ready.
If it’s taking a little time to get started, focus your efforts on the stories with the most certainty – both in terms of scope, and desired value or outcome – and get those at the top of the backlog.
Once the team has a few stories to work on, you can then continue curating the backlog with a little more breathing space.
Don’t forget – it’s an ongoing effort - and it’s never really over.
Got a question about product management? Hit “reply” and let me know. I’ll happily answer in a future post.