Prioritising as a team
I’ve worked on several teams where the sole person involved in prioritising the backlog of work is the product owner. I’ve found this to be unhealthy for the team, leading to feelings of distance from the work and of being in a feature factory where you just get fed cards. I think this has stemmed from scrum, and the definition of a product owner including
"The Product Owner is the sole person responsible for managing the Product Backlog."
Yet whilst the product owner is accountable and responsible for this, it does not and should not mean that they are the only person involved in prioritising the backlog.
Whether the product owner is a product manager acting in the role to represent many stakeholders, or a direct customer/stakeholder product owner, they will not have all the knowledge necessary to prioritise all the work required to release usable software. To prioritise well they will need to listen to user researchers, designers, developers, and the rest of their team. Prioritising as a team provides this, and gives the team more of a buy in to the work they are doing and better context to decision making. The product owner can keep the tie breaking vote, but everyone on the team will understand why and how the work has been prioritised.
At this point, you might be thinking does this mean decision making by committee. It shouldn’t. The people involved should be those who have direct knowledge of the factors that will affect prioritisation. Whilst they may have opinions they express and challenge about other areas; the team should respect each other’s opinions enough to allow the right people to have the right level of influence.
A key factor will be the criteria for prioritisation. This is something that the product owner needs to communicate to the team so that the team can use that to inform their recommendations. Making this clear in the method you are using for prioritising is essential so that everyone understands the reason for decisions and doesn’t feel disempowered.
I wrote in one of my first blogs about types of work the team works on, one of which was tech work. In that post, I discussed ring fencing 20% of the backlog for this work to ensure that the work needed to ensure security and stability were prioritised. This was due to the backlog the team I worked on being the domain of the product owner and mainly feature focused. By prioritising as a team, tech work can be prioritised in context and understood by the whole team.
I personally use a similar method to the one I discussed and illustrated there to prioritise as a team when we need to prioritise a large amount of work. We draw out two axes with the main criteria for prioritisation on them, and then place each card on the board, discussing their relative positions to the cards around them. Almost always one of the axes is time, as there will always be some element of external deadlines, or of internal dependencies. The other axis will be some variation of importance, with what is important to us made clear. Most of the time it is value to our users, but I have worked on a project where the axis was ‘knowledge transfer required. This was where we had a short period of access to consultants and wanted to prioritise work we needed help with over work that might be important to our users but we knew we could handle on our own once they left.
Part of the team I am on standing around a board discussing the prioritisation of their work to be done
This method works well if there is a large amount of work to prioritise, as it helps to visualise it, allowing the whole team to see all the cards at once. If we have a much smaller amount of work to prioritise (eg higher level features for a roadmap, or just the work to implement one feature), we tend to simply chuck them up as a list and discuss their prioritisation. I try to keep the number of cards with an explicit prioritisation low, so that we don’t spend more time than we need prioritising things that will change in the future as we learn more.
Involving the team in prioritisation empowers them, involving them in decisions about the work they do. This is essential if you want to have self-organising teams. It is not enough to empower teams to organise how they do the work, they need to be able to influence the work they are doing. Your team will have the best knowledge of their users, the tech they are using, and their dependencies, and so need to be able to feed this into decision making. If they don’t have this knowledge, you have much deeper problems that need addressing.