Importance of product ownership

The Product Owner has often been described as the development team’s most important stakeholder. The role of a Product Owner is critical with the success of delivery, creating a motivated team and ensuring an enjoyable journey. A recent experience highlighted the necessity of having a strong and consistent Product Owner and prompted me to share my experience with what makes a good PO.

Whilst working on a short 10 day engagement with Andrew Li, whereby we split our discovery, consultation and delivery into two 1 week sprints, we experienced a change of product owner multiple times – in part down to the unforeseen circumstances and the festive holiday period.

During the 2nd planning session, priorities shifted (which of course we welcome), however the requirements were not fully understood and the various people present were unable to provide sufficient detail for the team to confidently take the work into the sprint. What made matters more tricky was that the relevant subject matter experts were not present, in fact were not known, making it impossible for the prioritised requirements to be represented as well formed user stories.

The challenge we faced was to accommodate the desire to work on the most important thing, despite not knowing what was specifically required, and to progress delivery with the clock counting down.

Thankfully, our solution to the problem worked on this occasion – we front-loaded the sprint with a series of SPIKEs, which depending on their outcome would dictate the goal of the sprint.  This did mean we defined a primary goal, which the team were confident to commit to, and an alternate goal – which would trump the primary goal if clarity was gained early enough in the sprint.

I’m not a fan of this approach, but sometimes pragmatism shines through particularly when dealing with a very limited amount of time.  Again, thankfully, the outcome was positive despite the less than ideal process and has resulted in a much longer engagement with the client.

This experienced not only stressed the importance of good quality user stories, but also the need for a “good quality” and “stable” product owner who is mindful of and effective in fulling the role.

It became apparent the need to express the importance of product ownership and how this role is critical with delivery success, a motivated team, and enjoyable journey.

It also prompted me to think back about a workshop a past colleague, and good friend, Steve Trapps (Professional Scrum Trainer with Scrum.org), who hosted a session on the subject, entitled “The World’s Worst Product Owner Would Do This…?”.  I thought this was a good approach at describing some behaviours that I’ve certainly witnessed and no doubt others have.

Just to be clear though, those acting in the product owner role in the engagement mentioned above, were pretty awesome and the challenge was more circumstantial on that occasion.

Before I go into some the less than desirable behaviours and traits of a product owner, here’s a reminder / brief overview of the product owner role…

Product owner role within the scrum framework

As the product owner is typically the project’s key stakeholder, having a single product owner for the course of the project ensures that there is no confusion as to who the delivery team or broader business needs to reach out to, otherwise the vision of a product is a very personal and unique concept. Each person can bring their own flavour to this concept. If the individual who is responsible for setting this constantly changes, subtle changes to the original vision may occur. This can cause confusion to with the team (previous work may contradict new vision – is it still right).

To summarise to the role:

• The product owner is typically a project’s key stakeholder
• Responsible for the vision of what is to be built and can convey the vision to the delivery scrum team
• This is done in part through the product backlog – the prioritised list of features
• Commonly a lead user of the system, often someone from marketing, product management or anyone with a solid understanding of the users, the market, competitors and future trends.
• Although the product owner prioritises the backlog, the team selects the amount of work they believe
  is achievable within a sprint, and indeed how many sprints may be required.
• The product owner does not, for example, say “we have four sprints remaining, therefore you must deliver one-fourth of the product backlog this sprint.”.  Rather, he/she should look to motivate the team with a clear, elevating sprint goal to get the product closer the fulfilling the vision.
• The product owner should not look to change requirements, or add additional work, within sprint.
• Requirements are allowed to change, and indeed welcomed, but only outside of the sprint.  The sprint should remain focused on the sprint goal and the stories within to honour it.
• Skills and traits sought for a product owner include: availability, business savvy, and communication skills.  Active engagement with the team is critical.
• Being empowered to make quick decision on priority and scope is essential.
• In addition to communicating well with the delivery team, stakeholder engagement throughout the organisation and beyond is equally essential and he/she must be able to communicate different messages to different people about the project at any given time.

In practice, I encourage, and assist, the product owner to be well prepared ahead of planning sessions – so that less time is spent discussing the what and why, with more time focusing on the how.

Allowing for sufficient time ahead of a delivery phase is dedicated to a discovery period, results in a good quality initial product backlog broken down into epics and user stories.  Once the team is sprinting, I also advocate backlog maintenance sessions (usually mid-sprint) and continuous discovery (usually in the form of spikes/specific analysis resulting in one or more well defined user stories).

---

The World’s Worst Product Owner Would Do This…?

Here are some behaviours we watch out for, seek to avoid, and proactively look to address:

Behaviours / Traits

Consequences

The fall out of these behaviours left to fester, could result in:

• A de-motivated team
• Lack of trust
• Risk of conflict turning into crisis
• Mis-alignment of expectations
• Unclear product vision
• Unclear sprint goals
• Inefficient ability to reflect and adapt
• Devalues the importance of meetings & key meetings being dropped
• Team not working on the right things
• Sprint goals not met
• Blockers/impediments dwelling
• Blame culture ensues
• Them and us; barriers and silo’s formed!

Course Correction

Before delivery commences / between engagements / between delivery phases

• This is by far the best opportunity to set out good behaviours, team norms and intra-team needs/expectations.
• If the product owner is unfamiliar with scrum, use the time you have ahead of delivery to facilitate training.  In fact, even if they have acted the product owner previously, a refresher session would be beneficial.
• As a team, review the definition of ready as well as the definition of done.
  • Perhaps try leveraging a Kanban board to represent the journey of a requirement to a user story ready for the team to plan and estimate.

During delivery

• Passively elicit areas of improvement with the retrospective, avoiding finger pointing.  Leverage various techniques to enable a focus on how the team can improve rather than individuals.
• 1:2:1 agile training/coaching with the product owner – perhaps go back to basics and devote time to taking a step back and looking at the various needs a team has and what a product owner should be doing to assist with this.
• Provide assistance to the product owner in various tasks – it may well be the case that he/she is stretched, possibly working across multiple teams/projects and being pulled in many directions.
• Ensure to set aside time for a backlog maintenance session, which doesn’t necessarily need to involve the entire team, but will enable a more productive planning session.

Always have to hand:

• Sprint checklist: a useful reminder of items needing doing ahead of, during, and at the end of each session to which the the product owner is critical.
• Visible Definition of Ready: clear reminder as to what the team has agreed for the work item to be ready to plan
• Sprint schedule / calendar

Final words

Help your product owner! They’re probably stretched and it’s likely they have another role and/or project/team competing for their attention.

Ensure your product owner feels part of the team – one team mentality.

Use your retrospectives to non-aggressively encourage improvement.

Take time out to refresh your knowledge of the role and responsibilities.

Check out some top tips from Scrum.org: https://www.scrum.org/resources/blog/10-tips-product-owners-agile-product-management.

---

Further reading

• https://www.mountaingoatsoftware.com/agile/scrum/roles/product-owner
• https://scrum-master-toolbox.org/tag/product-owner/
• https://www.lucidchart.com/blog/product-owner-roles-and-responsibilities
• https://www.scrum.org/resources/blog/tips-starting-product-owners
• https://dzone.com/articles/11-secret-agile-tools-every-product-manager-should
• Robbin Schuurman, Scrum.org
• Steve Trapps
• https://scrum-master-toolbox.org/2018/02/blog/the-product-owner-sprint-checklist-a-tool-to-help-you-deal-with-an-overly-busy-or-absent-po/