While I was training a group of product owners recently, the class started a robust discussion about the role of the ScrumMaster. In closing the session, when I asked what their key takeaway was from the discussion, they replied, "The value a ScrumMaster brings to the product owner."
I realized that in all the conversations I have had with ScrumMasters, they talked about their coaching efforts with their development teams, but I couldn't recall a single instance when they talked about what they did to support their product owner.
While working with a team, I had observed a product owner -- let's call her Amy -- who was new to both the Scrum team and her product owner role. She was very energetic and enthusiastic; however, from watching her interactions, it became apparent that she came from a command-and-control background. Within the first few sprints, Amy told
the team what to work on and later pushed
for changes mid-sprint, justifying it as changing priorities and business needs. The ScrumMaster -- let's call him Brian -- tried to guide Amy without much success. During the third sprint the dysfunctions became overt, as the development team was in a constant state of churn. The final straw came when the development team was unable to complete sprint planning for Sprint 4. At this point, Brian reached out and asked whether Amy would be open to exchanging dialogue and perhaps receiving some feedback. Hesitant at first, Amy agreed.
Brian talked with her about what was important to her, her view of the role of the product owner, and her view of Scrum and Agile, among other things. Brian used powerful questions to help him with this part. Amy told him about her background as a project manager, and how she felt that the role had set her up well as a product owner. She had never had any kind of formal Scrum training but had read a lot and was doing what she thought was required to get the job done.
Brian realized that she was trying to use traditional top-down management in an environment in which this approach didn't fit. He proposed to her that they meet every morning for 30 minutes for coffee. He explained that one part of his job as a ScrumMaster was to coach and help the product owner. He explained that the morning touch points would really help the two of them connect so that they could help the development team together. Amy agreed.
The first day they met, Brian brought the Scrum Guide to the conversation and walked her through it. They created a list of topics that they would discuss each day. Some of the topics included:
- The reason why sprints are timeboxed
- What is a healthy product backlog
- How to create a vision and road maps
- What are some effective prioritization and refinement techniques
Brian then worked with her to prioritize these topics, creating a coaching backlog with her. For the next two sprints, Brian wore various hats as a trainer, facilitator, mentor, and a coach to guide her through these topics.
One of the items they worked on was backlog estimation. Amy felt that estimation would allow her to predict when the Scrum team could deliver value. Brian cautioned her that sometimes too much emphasis on estimation could lead to non-Agile behaviors. They walked through two techniques used to estimate a backlog: planning poker and affinity estimation. Brian offered to facilitate one estimation session for the team so that Amy could then attempt the next one.
One of the biggest "Aha!" moments for Amy was their discussion on why sprints are timeboxed. Having thought the only
reason that the sprint was timeboxed was to provide value to the customer faster, she realized it was for other reasons as well. The timebox allows the development team to get feedback from the customer faster so they can iterate and continue to provide value. It allows the development team to be focused on delivering what is in the sprint backlog, without interruption. Her notion of being able to handle changing requirements throughout the sprint did not take any of this into account. She realized that most interruptions during the sprint were because of a poorly ordered product backlog.
As a result of this coaching, the development team noticed their environment improving during the next few sprints. Rather than telling the development team what product backlog items to work on, Amy would present the higher-ordered product backlog items, work with the development team to draft the sprint goal, and decide what they would work on. Rather than forcing change to items mid-sprint, Amy ensured that the product backlog was rightly ordered and, if there were indeed any changes, she would bring these to the attention of the development team and ask them what the team should do.
This experience makes me wonder how many product owners might benefit from some coaching from their ScrumMaster. Many ScrumMasters focus on the team -- which is needed -- but we need to have the ScrumMasters focus on the organization and the product owner as well.
The Scrum Guide
provides excellent guidance about what a ScrumMaster can do to help the product owner.
- Teach the product owner techniques for effective product backlog management.
- Teach the development team and product owner the need for clear and concise product backlog items.
- Mentor the product owner through managing the product backlog to ensure it is ordered and healthy.
- Facilitate planning and backlog refinement as needed or requested by the product owner.
- Coach the product owner to understand and practice agility.
I believe that every great product owner must have a great ScrumMaster to support and coach him or her.