New Product - How to prioritise when PO prioritises all features as high priority
When delivering a new software product, and having already chunked up the work into releases (such as an MVP) how should the Product backlog for a release (or MVP) be prioritised?
The conversation, from a Scrum team perspective, with the Product Owner, invariably goes along the lines of:
'What should we be working on first, since we want to always be working first on those things with the highest business value?'.
This is met with, from the Product Owner:
'At this level, since they are all needed, it does not make sense to prioritise one story or feature over another'.
I've been through an exercise of asking a PO to prioritise a backlog based on business value (using a modified fibonacci scale) and they came back with every single one of the items as business value 100! Must have, could have, should have, etc. - everything was a must have. That's fine but there must be some sub-level of prioritisation.
Approaches to prioritise within a 'need everything' scenario might include:
- Business value prioritisation (though reference everything I've said above)
- By prioritising all stories related to completing a user journey(s) (end-to-end)
- Prioritise happy path scenarios to build core functionality (though risks context switching to come back to less happy paths later)
- De-risking by working on the riskiest or most complex areas first. Seems preferable to generally working on simplest things first?
What do people think? How best to chunk up the work into frequent, theoretically shippable working software, where the PO is not giving much prioritisation guidance beyond what is going into a next (or first) release? Remember, the problem is in the context of a new product, where a big list of features/stories need to be prioritised.
There really is no “how best to”, only things to try and learn from to see what works for this product and team.
Value can come in many different forms. What is the smallest thing that could be delivered to customers to start gaining feedback? That first step may offer the most value today, and help to enable future value discussions. Everything is an assumption on value until delivered and validated.
Consider this from the Scrum Guide:
“The Product Backlog is an emergent, ordered list of what is needed to improve the product.”
Focusing on the “ordered” part, can help with these types of discussions. Imagine the backlog being structured in such a way that order is enforced, meaning that the PBI on top is number 1, below that number 2, then 3 following that and so on. This essentially forces the PO or team to make decisions. Only one PBI can hold the number 1 spot.
The PO may do this work, or may delegate the responsibility to others. If the PO doesn’t feel strongly about the order, bring it to the team to determine the order as they know how best to build the product and may offer guidance on what should be top priority.
Story mapping, site maps etc. can be helpful tools for bringing transparency to what needs to be built in order to have a working product. Bubble sort approach may also be useful to work through backlog through a series of relative comparisons to help with ordering.
Things to consider in Product Backlog ordering include priority, cost of delay, risk, value, dependencies (business and technical), ROI, lessons that can be learned, and many other things including perhaps the social good.
Each Sprint is an opportunity to get Done, usable work now, so productivity can be empirically evidenced now, and incrementally optimized. Failure to take advantage of this means there will be a succession of missed opportunities to maximize outcomes for stakeholders.
What does the PO think about this? What does he or she hope to get out of Sprints and from using Scrum at all?