Effective prioritisation:
Not all requirements are created equal
- 15 November, 2021
- Article - Software Best Practices
Friction in priority and communication are common themes in enterprise software projects. When a new project kicks off, everybody is inspired by how they can leverage the solution or how it can address their burning needs. However, having a single solution provide direct value to multiple stakeholders in different departments within the organisation can be problematic. A strong product owner must be able to understand the different needs and complexity of the business and technology ecosystems, prioritise effectively, and communicate what will happen, when it will happen, and why that decision is preferable.
The product backlog should have low friction for anyone to contribute towards, regardless of their designation or level of influence in the project.
A single view of needs and wants
A product backlog is a single list of the new features, feature changes, bug fixes, infrastructure and technology changes, and all activities that a team may deliver or depend on to achieve a broader goal.
The product backlog should be the single authoritative source for what should be prioritised at any point in time. This means that nothing gets done that isn’t on the product backlog. With that said, the presence of a product backlog item does not guarantee that it will be delivered. It represents options the team has for delivering a specific outcome rather than a commitment. The product backlog should have low friction for anyone to contribute towards, regardless of their designation or level of influence in the project.
Collaborate widely to extract information
A single product backlog allows for diversity of inputs from anyone who has an interest in the project to express their wants and needs, the value it brings, and the factors driving it. A backlog item, at a minimum, should include:
- What it is
- Why it is valuable
- What the dependencies are
- What the constraints are
By allowing everyone to voice their wants and needs, the core product team, including the product owner and technical leadership, can easily find patterns in requests, identify trends in items of value, and map dependencies to boost efficiency.
Prioritise in a small well-informed group
The core product team should be responsible for the final decision on prioritisation of items on the backlog after stakeholders have provided motivation for their items. By harnessing their deep understanding of the software as a functional asset, and the details of the technology behind it, the core product team can use a method like lean prioritisation based on the qualitative information in the backlog.
A simple value vs cost matrix can be employed to create structure and more quantitative sense of the backlog items. It is worth noting that cost can include effort, time, and complexity. All decisions should be centred around value.
Value can be subjective – it might mean tangible financial benefit, or intangible customer experience benefit. It’s the responsibility of the core product team to understand the complexity and identify value as accurately as possible.
For items where the value might be difficult to estimate, hypothesis-driven development is a useful technique to test requests responsibly.
Prioritisation is not a perfect science and needs to be thought about and tailored for different business contexts, problems solved, and organisation dynamics at play. By creating a single central backlog, the entire business is empowered to express their needs, and the product team is better informed and equipped to make decisions. Creating order from the qualitative information will drive better quality decisions, and ultimately generate more valuable technology solutions.
Need more guidance on how to prioritise requirements?
We can help you crystalise the way forward and facilitate decision-making. Get in touch.
