While talking to numerous Scrum Master over the last few years, I came across a concerning pattern. Although we have Scrum Guide and other complementary resources, many Scrum Masters, especially those starting out, struggle with the interpretation and ideas on how to help their Product Owners on a day-to-day basis.
Below, you can find some examples on how I work with Product Owners, as well as citations from Scrum Guide, which help me navigate between support, and not doing something that’s in their capacity.
Let’s start with the first one:
(..) Helping find techniques for effective Product Goal definition and Product Backlog management;
What does it mean helping find techniques? Is it just “here you go, a Story Mapping technique for you for all your troubles”. Well, the way I see it, we as Scrum Masters should be able to research those techniques via any means necessary, such as:
- ‘Just google it’ and take the pressure of our Product Owner with finding the best technique,
- Networking with other Scrum Masters to have a chance to browse from their experience,
- Connecting our Product Owner with other Product Owners – either in our organization, or outside of it, to ensure knowledge sharing, maybe you already have some sort of PO Guild? If not, maybe there is still a possibility to have one?
- Taking part in various meetups, trainings for those available techniques and be able to explain their meaning to Product Owner, and conduct those, when necessary,
- Facilitate workshops on defining Product Goal and/or Product Backlog management,
- Teaching different approaches to ordering Product Backlog – have you tried a Value Based Method?
- Have coaching 1 on 1 sessions with Product Owners, on a regular basis.
I cannot stress enough the importance of 1 on 1 regular session. This is where, as I say, “magic happens”. We as Scrum Master are ensuring a spot for deeper understanding of Scrum framework, and all the questions our Product Owner might have during the Sprint. Unfortunately, this is also one of the things Scrum Master does not pay enough attention to. We often say, “to establish relationships, to have a real change, we need trust”. This is one of the moments, this trust can happen.
Those are just a few of the ideas on how we can help with establishing, Product Goal and Product Backlog management, and I encourage you to use whatever you have at your disposal, to serve your PO in this matter.
Another thing we can find in Scrum Guide: Scrum Master serves Product Owner by:
Helping the Scrum Team understand the need for clear and concise Product Backlog items
A few ideas below on how he can support this:
- Ensuring that during Sprint Planning, the Scrum Team is aware of the WHY, the WHAT and the HOW of upcoming Sprint,
- Establishing transparency on PBIs,
- Encouraging the Product Owner and Developers to experiment with different ideas on how to create PBIs, maybe User Story format is not the only option that exists?
- Asking powerful questions, such as “Will you still be able to understand your PBI in few weeks?”,
- Tying PBIs to Definition of Done, for example with questions “How will you know this PBI is DONE? What needs to happen?”
- Dropping an idea of a complimentary practice such as Definition of Ready (personally I am not a fan, but I know that certain teams can benefit from it),
- Setting up a standard of how our PBI should be build (for instance, it should have a purpose, a description, acceptance criteria – anything that works for YOUR team)
Next line would be:
Helping establish empirical product planning for a complex environment;
Now, that’s a tough one. What does it mean exactly to have an empirical product planning?
For me, it’s taking into account all we have learned from previous Sprints, and adapting towards the next one.But, for this to happen we need to start before the Sprint Planning itself:
- During retrospective, Scrum Master fosters a safe environment for the Scrum Team to inspect their work in previous Sprint,
- Scrum Masters makes sure Product Owner takes into account market information about Product developed,
- Helps Product Owner find metrics appropriate for the Product, show different approaches – maybe use of Evidence Based Management would be a good starting point?
- Helps to create focus on the value our Product will give customers – are we sure all those features are really needed?
- We make sure the Product Owner is constantly aware of the Product Goal he set, by reminding him “how is this element going to serve our Product Goal?”
- Explaining what is a complex environment – and building the understanding on how Scrum can help in that domain. When was the last time you talked to your Product Owner about complex theory?
And last, but not the least:
Facilitating stakeholder collaboration as requested or needed.
How might we achieve it?
- Helping Product Owner find stakeholders within the organization, and outside of it – maybe a map of stakeholders?
- Helping Making sure all relevant information are taking into account by Product Owner,
- Helping Facilitating intense stakeholders meetings when needed, maybe suggest some ideas on how to choose which stakeholders needs are the most in line with our product development – maybe work/impact matrix?
- Helping Showing Product Owner the need of gathering feedback for his/her Product,
- Helping Making sure we have product users on our Sprint Review – too often we only have internal stakeholders, who do not actually use our product!
- Helping Ensuring transparency with stakeholders collaboration – maybe by a clear vision on Product Backlog and the ordering?
As you can see, while we have some guides in Scrum, there is a lot of freedom between those frames on how you can achieve it. It both fosters creativity and sometimes frustration.
I hope this article will sparkle you with some ideas and inspirations on how to turn these moments of frustration, towards creativity.
