The scrum master helps the product owner by ensuring empowerment in the organization, managing the product backlog in a transparent and prioritized way, facilitating events and workshops, and keeping clear and concise communication with the developers.
It all depends on how experienced is the Product Owner in his or her role but even if the experience is strong there is a lot to care for.
The product owner should be empowered in the organization
This sounds like an obviousness but if the product owner is not empowered scrum framework can’t work as it should. If the product owner can’t make decisions about the product – who can? Is there someone else that makes decisions? Why that person is not the product owner?
What does it mean that the product owner is not empowered?
- It means that decisions about the product can’t be made without someone else’s approval.
- Sometimes decisions are made by the product owner but someone else comes and changes them.
- For some reason, the product owner has no access to key stakeholders or can not communicate with end users. In this situation, the product owner can’t confirm the value hypothesis so basically can’t tell if the vision for the product is valid
The product owner should make decisions about product growth and by those decisions, the product owner achieves one of the most important tasks – optimizing the value that the development team is delivering.
If a product owner is not empowered and can’t make binding decisions – the development team is wasting precious time.
This kind of situation can lead to:
- rapid changes in requirements,
- canceled sprints,
- no concise vision of the product,
- and more things downhill to chaos.
In this environment, developers will probably think about leaving the team or even the organization.
A good scrum master can’t allow this to happen and must influence the management to respect and trust the product owner’s decisions and explain why this is important.
If the product manager (if there is one above the product owner) has issues with the product owner’s decisions it should be discussed in private. In public, in front of the team, the product owner should have the last call when planning the sprints.
Managing the product backlog
Product backlog items must explicitly describe the context and the outcome that should be produced to bring value to the users.
The backlog must be prioritized in the way that the increment produced across the sprints provides maximum outcome with minimum output.
As they say – 80% of the value is within 20% of the features. There are always so many functionalities you can think of but there is never the time to build them all. That is why the product owner has to know which ones will bring the most value to the users – those are the priorities.
A scrum master must know that the focus of the product owner should be on exploring what the users want or need. If the PO doesn’t do that the scrum master should coach the product owner to collaborate with the users or their representatives and find out what are the most important features. When that knowledge is acquired then prioritizing is easy. Also having the flow of value’s big picture on the table should make it easier to describe every piece as a part of the wide context.
There are of course other sources of product backlog items besides features. Non-functional requirements, risks, technical debt. Those issues are usually the result of workshops with other roles: architects, tech leads, or dev-ops engineers. As a scrum master, it would be good to point out that the backlog is missing those topics. Find the right people to talk to and propose to facilitate the workshops.
Facilitating events and workshops
As said in the previous chapter – the product owner should collaborate with users and with the development team. These collaborations take place during events and workshops. Scrum masters should know how to facilitate that kind of event and should help with them when requested.
A great example of exploration workshops that enable a shared understanding of how an application should work and look is story mapping workshops. An approach introduced by Jeff Patton author of the book “User story mapping”. You can read in detail how to commence this kind of workshop on this blog.
The scrum master can facilitate those workshops so the product owner can focus on participation. If a product owner doesn’t know how to commence those workshops and why it is a great way to work on the flow of value – the scrum master should be able to pass on this knowledge.
Other classic events are sprint planning and product backlog refinement. At those meetings, the product owner must clearly describe what needs to be done. The scrum master should ensure that the description is clear to developers and that everyone shares understanding of what needs to be done.
Clear and concise communication with developers
As mentioned above clear communication with developers is crucial to share a good understanding of what to develop at every stage of production. From my experience, from the communication standpoint there are two most common dysfunctions:
- The product owner is too technical – it is the job of the developers to figure out how to turn business requirements into working software. If a product owner tries to do that then who will focus on the business requirements? A scrum master should coach the product owner on how to focus only on the flow of value. Always keep an eye on the product owner – when he or she tries to discuss technical issues with the developers – break this dispute and remind everyone of their roles.
- The product owner doesn’t provide business context or it is too shallow to understand what outcome the users expect. It is hard to understand what to develop and how to test it. The reason for that can be a lack of domain knowledge or no access to end users.
A scrum master should work to remove this kind of impediment by supporting the product owner in gaining access to knowledge and to the users.
A scrum master should make sure that developers have comprehensive knowledge about the value that is there to be delivered.
Stakeholders on sprint review
The sprint review meeting should allow the scrum team to get valuable feedback about their work from the best possible source – the stakeholders. A scrum master should ensure that they participate in this meeting and provide feedback. It is in the product owner’s best interest to have key stakeholders on sprint review and acquire the feedback.
It is of course good to know who are the key stakeholders – find it out – here.
More on the scrum master’s role to commence a good sprint review – here.
The product owner should be available to the team
If a scrum master starts to work in a scrum team and sees that developers can talk to the product owner only during sprint planning and backlog refinement meetings – something is very wrong.
During sprint, developers can come across many difficulties, for example, there is an error in the business logic no one noticed during refinement and planning. This can be an obstacle to achieving the sprint goal. The product owner should be reached right away for consultations. If there is no contact possible developers will have to make their own decision – it is not their role to do that.
Most likely on a sprint review stakeholders would see an increment they didn’t want. We just lost time, money, reputation, team engagement…
Where was the product owner?
Where was the scrum master to escalate this situation?
There is a reason why the product owner is a part of the scrum team – he should be available so that continuous improvement is enabled.
What can a scrum master do about it?
- point it out, explain to the product owner why this is important, and what are the risks (example above)
- escalate the situation when necessary – maybe someone in the management is forcing this situation – coach the organization
- don’t agree on any proxy – developers must have all the information they need from first hand – directly from the product owner
Developers are making work behind PO’s back
It is the product owner’s decision what is being delivered during the sprint.
Only PO has the accountability for the scope of the increment.
If the development team achieved the sprint goal faster than expected and the sprint backlog is empty – they should meet up with the product owner and discuss what to do next. If they don’t – the scrum master should coach them on how to behave in this situation. The scrum team should discuss this issue during the sprint retrospective.
In conclusion
The scrum master should be familiar with the way a product owner works independently and within the scrum team. Above is not a closed list, but rather the most obvious and common situations in which the product owner and the whole scrum team can find them selfs in.
So dear scrum masters – learn the ways of the product owner. This knowledge will help you in identifying dysfunctions – support your PO in overcoming them. The fate of the users depends on you.
