Working With Stakeholders
As Product Owners we might typically work with stakeholders when we need their input, feedback or their indication of priorities so that we can then update the Product Backlog.
Ideally we want to collaborate progressively with the stakeholders, to know what has been done and what new insights we gain when we inspect a finished Sprint Increment for example. Some stakeholders spend a lot of time with teams, some too much, and some too little, but all have a strong influence on how a team responds to their feedback and understanding, and so should not be overlooked.
Interaction
An invested stakeholder may look to interact with the Product Owner and the Development team at every opportunity and make themselves available either remotely or relocating themselves to sit near to the team and be available for impromptu discussions and Product Backlog Refinement, which is the ideal.
Alternatively, for partially engaged or disengaged stakeholders they may only interact with the Product Owner during formal events such as the Sprint Review or through explicit Product Backlog Refinement sessions for example, that are bookable within calendars for time poor stakeholders.
Invested vs. Disengaged Stakeholders
Stakeholders tend to fall into three main categories:
- Invested – They have a great rapport and interaction with the team and are happy to provide feedback, convey deeper insights about how the product might be used, and like vigorous discussions and interactions with the team. In short, they invest their time with the team knowing that their investment will pay off with a better product and end customer experience.
- Partially Engaged – These stakeholders typically are time poor and struggle to keep up to date with the team. They may attend Sprint Reviews for example but tend to be absent during the rest of the Sprint. They may not have time to think about things deeply and so may only provide superficial feedback and react to suggestions and issues. Teams typically struggle to keep them informed with some of the Product Owner time invested in presenting information to them and getting them up to speed, rather than spending that time thinking about the product. Surprises and reactions are common especially when things are not going to plan, and they may well feel threatened by these surprises and take action as the fight or flight threat response kicks in.
- Disengaged – These stakeholders tend to be on the sidelines and may only attend a few Sprint Reviews for example. Their main objective may well be to endorse the team’s direction or just be informed of progress. This interaction with the team and the Product Owner can be disruptive if they are constantly asking questions and distracts the team away from other critical tasks, which can be a drain on their time with little or no benefit to the end product. When teams need feedback, these stakeholders are more likely to deflect direct questions and delegate opinions to the team. When things don’t go to plan or surprises happen, they may very well attack the team for seemingly creating the situation.
Level of Awareness
Stakeholders can be on a spectrum of awareness of the product, it’s intention and the downstream impacts to the customers and other actors. At one end of the spectrum is the time poor stakeholder with a reactive and superficial understanding of the product, and at the other is the invested stakeholder with deep insights into the product and the customers’ needs.
Depending where stakeholders fall in the spectrum can influence their behaviour with the team and the Product Owner.
Stakeholders with a superficial awareness may only provide superficial and reactive feedback, whereas stakeholders with a deeper level of awareness provide good insights into how the product will be used with a higher level of qualitative feedback.
Communicating with Stakeholders
To avoid the surprises, it is good practice to keep them informed as often as possible and generate a conversation throughout the work. The Product Owner may have to initiate these conversations and seek out the stakeholders rather than waiting. The key principle here is to keep the information flow constant right from the start of the release or project and avoid sudden surprises when things don’t go well.
An approach that tends to work well for organisations that are used to metrics and measuring progress, are Burnup Charts that indicate the amount of work on the Product Backlog and the amount of work delivered by the team.
The fluctuations in the amount of work on the Product Backlog represent the decisions made with the stakeholders and the team. When there is an upward trend in the curve, this indicates additional items on the Product Backlog, when there is a downward trend, then scoping decisions have been made.