Should Product Owners be Backlog Owners?
- Danielle Downs
- May 6, 2022
- 12 min read
Updated: Jul 22, 2024
Reading a post on LinkedIn by David Pereira (April 2022) and a reply from Florian Sperber got me thinking….
TLDR? Jump to the conclusion or section in which you're most interested:
Should the PO role be split into Requirements Engineer and Product Manager?
Earlier in my product career, firstly as a Business Analyst and then a Product Owner, my answer to this question would have been an unequivocal ‘no’. My reasons for this came from two different perspectives of the same coin.
As a Product Owner, I baulked at the inefficiency of transferring all the knowledge, context and research that had gone into my Product Vision to another person. Delegating the creation of user stories and acceptance criteria surely risked perpetuating the infamous meme, where the product created by the development team ends up bearing little resemblance to what the customer wanted in the first place.
One of the key benefits of Agile for me was the vastly reduced feedback cycles and prevention of rework, by involving the Product Owner (representing the voice of the customer) every step of the way. Adding a degree of separation between the Product Owner and the development team seemed to defeat one of the most fundamental principles of Agile.
Secondly, as a former Business Analyst, who had been a Proxy Product Owner during the first wave of migration from Waterfall to Agile, when the "real" Product Owners (formerly known as Project Sponsors) were busy directors with full-time day jobs, I had felt frustrated and disempowered that I had to run to the actual Product Owner with every question or refinement. As much as I, as a Product Owner, wanted to be involved in every decision, why would someone else want to be in the demoralising position of having to come to me?
Back when my then employer first transitioned to Agile, I remember being told by some of my peers that the Business Analyst had no place in Scrum. There was only the Product Owner and the Development Team, consisting of Developers, QA and a Scrum Master.
They ‘joked’ that my role was now to ask customers if they would like to add fried potato products to their meal order. I went to the gym and cried in the shower. Others tried to comfort me by conceding that the Business Analyst could be seen as a specialist role within the Scrum Team, in the same way as a UX Architect or a Designer; but it left me feeling like my role had somehow become less valuable or irrelevant overnight and I certainly didn’t want to make anyone else feel that way.
I guess that emotional baggage remained with me for a long time and that was why I remained so adamant that the two roles should be fulfilled by one person, fully empowered to make real product decisions.
“What’s the most important question a Business Analyst can ask in Scrum?” “Do you want fries with that?” — a ‘joke’ a colleague shared with me early in the transition to Agile
The problem I found, however, as I moved from BA to Proxy PO and from PO to Product Manager, was that being a Product Owner on a Scrum Team is in itself a full-time job!
Does this mean that Pereira and Sperber are right and it is in fact two roles cunningly disguised as one?
The Product Manager role is an Iceberg
I have always likened the Product Owner role to an iceberg. There’s the part the Scrum Team sees, where you attend daily stand-ups, sprint planning, backlog refinement and retrospectives, create user stories, sign off demos and are the “go-to person” for clarifications on product requirements. As far as they’re concerned, that’s all you do all day long. You are at their beck and call.
Then there’s the part the rest of the business and customers or clients see. Strategy workshops, meetings with stakeholders (and ideally real-life customers!) to better understand their needs, data analysis, discussions about resources, budgets, timelines, risks & issues, catch-ups with sales and marketing and delivering product training… Another full-time job.
As my role evolved, I found I was spending more and more of my time on the second set of activities and struggling to find time for the first.
I allocated a slot in my diary for “PO Question Time” after the daily stand-up but this felt like a compromise. If something urgent came up, I didn’t want the team to feel they were blocked until the next day’s “question time” or, worse still, to forge ahead without asking and potentially make a decision that would need to be reversed later, resulting in dreaded rework.
I tried having my own Slack channel, where team members would tag me with their questions and I would respond as soon as I practically could between meetings… but I quickly found myself trying to answer during meetings, meaning that I wasn’t fully focused on the meeting and my answers to the team’s questions were often rushed and poorly thought out, resulting in me making decisions that would need to be reversed later! I could also see my notifications lighting up like a Christmas tree during those meetings when I couldn’t reply, compounding my stress to an almost unbearable level.
Admittedly, I could have managed the Slack channel better. I could have turned notifications off during meetings and avoided the temptation to respond in haste and repent at leisure. I also found that, on occasions where I didn’t reply straight away, the team member sometimes either answered their own question or someone else from the team responded and solved it for them. This was usually a positive thing and didn’t always result in a wrong decision, but I still felt like I was being negligent.
The arrival of the ‘Huddle’ feature on Slack made it easier to have real-time conversations with team members, giving them my undivided attention when I did have a few moments, but it quickly started to feel like I was being asked “Do you have 5 minutes for a huddle?” every time my “in a meeting” status icon disappeared and with it my opportunity to take comfort breaks between meetings. It got to the point where I envied cats’ litter trays and seriously considered buying a home office commode…
At the same time, the team had grown from 4 developers and 1 QA to 10 developers and 2–3 QAs. If my Slack notifications were like a Christmas Tree when the team was small, they were more like the sky at midnight on New Year’s Eve when the team scaled up. It was unsustainable.
Delegation of Roles & Responsibilities within Agile
I finally had to acknowledge that it wasn’t possible for one person to perform what was increasingly starting to look like two full-time jobs; or at least not and do both well.
I therefore created a Venn diagram of the various aspects of my role and how they could potentially be delegated, based on other roles’ skill profiles.
The most obvious solution, staring me right there in the face, was for the Business Analyst to take on some of the requirements refinement and analysis work and the Scrum Master (or Project Manager) to take some of the ‘project management’ activities that, in my experience, never really went away, despite the mass migration to Agile.
I then identified some other areas of my work that could be delegated to other team members. As a Product Owner, I often created low-fidelity, black & white wireframes to illustrate my vision for user interactions, but this wasn’t strictly speaking my job either!
Different elements of competitor analysis can also be undertaken by a BA, UX specialist (for UI-centric products) and Sales, as they often hear first-hand why a client might prefer a competitor’s product. Similarly, I have traditionally picked up device usage data analysis to prioritise browsers, operating systems and screen sizes for compatibility testing, but this too could be carried out by UX and Design, to advise on best practice, or the Data Science or Marketing teams if they are responsible for analytics.
So there it was, I was forced to admit that the Product Manager and Requirements Analyst can and do indeed need to be different people in order for the role (or a product portfolio) to scale, but what about David Pereira’s initial proclamation that got me thinking about it all in the first place?
Should Product Owners be Backlog Owners?
On this point, I concur with the Scrum Guide that the Product Owner should maintain accountability for communicating and prioritising the product backlog and to me this makes them the true ‘owner’ of the backlog.
“The Product Owner is one person, not a committee…. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.” — Scrum Guide, November 2020
The Requirements Engineer / BA is perhaps therefore more its ‘custodian’?
Ok… So what about story writers?
I often hear the glib phrase “user stories are just a placeholder for a conversation” but this assumes the PO has time for all those conversations, which I clearly didn’t and that was with fairly detailed and well-refined user stories and acceptance criteria!
In his article, Pereira advocates “writing broken items” i.e. proffering deliberately vague requirements, in order to provoke the team’s collaborative and creative problem-solving skills and leaving them to figure it out. This sounds utopian but, given my experience, it overlooks the reality that not all teams or team members work that way and not everyone is comfortable with such a degree of ambiguity.
I’ve always found teams to be an extremely broad church, with members that want total creative free rein at one end and those that need every Given When Then scenario comprehensively documented at the other. It is rare to have a team covering the full spectrum and even more rare indeed for them all to be at the creative extreme. Certainly I have never seen it. In 15 years, working with a variety of in-house, off-shore, near-shore, remote, distributed and blended teams in 3 different organisations, I have never been able to waft a vague product goal at a team and just leave them to get on with it.
It might work in a start-up, or an organisation where a ‘squad’ or team is responsible for optimising a particular metric and it’s up to them how they do it, but not in more established enterprises with complex stakeholders and users’ needs to be coalesced and prioritised. Without wanting to sound arrogant, that’s why the Product Owner / Manager role was created in the first place.
NB: I am not talking about the ‘how’ here — the technical solution architecture and design should always be left to the development team — I am purely talking about the ‘what’.
To me, the Product Owner needs to articulate a bare minimum level of detail for every piece of functionality:
1. What the functionality needs to do
2. Its business objective(s)
I personally prefer to write these in the traditional user story format, with the ‘what’ summarised in the “As a... I want to…” and the business objective in the “So that…” followed by what I call the business acceptance criteria in narrative form (not necessarily Gherkin format at this stage), explaining in more detail what the functionality has to do for the user story to pass.
For example:
As a superuser, I want to be able to suspend users… So that users, who have left the business or acted nefariously can be prevented from accessing the site; reducing financial and reputational risk resulting from unauthorised activity.
A superuser can suspend any user within a business they manage at any time.
Superusers cannot suspend users outside the business(es) they manage.
On-screen confirmation of the action is required.
Suspended users are notified they have been suspended.
Suspended users are unable to log in and are instead shown messaging telling them to contact their administrator for more information if they attempt to do so. If a user is logged in at the point they are suspended, they are logged out upon their next interaction
At this point, I try my best to avoid solutionising or prescribing the design. It sounds like semantics but there is a clear difference, for example, between “there must be a button to…” and “the user can…” or “upon their next interaction” vs. “on page load”.
Crucially though, I still see the Product Owner as the author of the user stories at this level. I believe this means we are story writers and we still need the skills to articulate good quality user stories to our teams; otherwise how will they understand the business requirements and the all-important context that gives them their value?
It is however at this juncture that I see the potential to place the split.
How Product Management Artefacts can be split
The Business or Requirements Analyst can take high-level user stories and work with the designers, developers and QA to break down the business acceptance criteria into further, smaller user stories with a sufficient degree of detail for the team to estimate and start work without too much additional input:
UX and design specialists can create wireframes, prototypes and mockups.
Architects and Developers can add technical and non-functional requirements.
The QA and BA can write behaviour-driven (BDD) or Gherkin-style (GWT) acceptance criteria and test scripts.
The resulting artefacts should then be shared, reviewed and discussed with the PO to get feedback and ensure nothing is misunderstood or missed before development starts.
“But wait!” I hear you cry. “Doesn’t this sound like mini-waterfall? The creation of business requirements and a solution design up-front?”
It may sound like a “bad smell” but, even in extreme agile, it would be unusual for development to start without any designs or user stories in place. Even the vast majority of text books and David Pereira himself recommend having at least two sprints’ work ready for development and with that I wholeheartedly agree.
I’m not recommending that high-level stories be created and refined in this way for the whole product roadmap before development gets started but an iterative, cyclical approach of creating, refining, and planning 1–2 sprints at a time.
Once work is underway, the PO and BA / Requirements Engineer should meet weekly to:
Review the user stories and business acceptance criteria for future sprints in preparation for refinement.
Review the broken down user stories and detailed acceptance criteria, wireframes, workflows, designs, etc. for the upcoming sprint, before sprint planning, with the aim of having a set of candidate user stories prioritised and “ready” for estimation and commitment.
This means the PO doesn’t have to attend sprint planning, or even daily stand-ups (although I personally would draw the line here!); instead focusing on the session where they add the most value i.e. refinement. Retrospectives could also be optional but I think it useful for the PO to attend at least one a month, or every 2 sprints, depending on sprint duration.
For this to work well, though, there has to be excellent communication and a high level of trust between the PO, Requirements Engineer / BA and development team, with very regular demos to minimise rework. It is also critical the relationship doesn’t take on a “them and us” dynamic, where the PO is considered extraneous to the team and “transparency” starts to cloud over. I believe this can be best achieved by the PO attending daily stand-ups and retros but others may have a different view.
The BA / Requirements Engineer must also not become a barrier. If the PO is the voice of the customer, then the Business or Requirements Analyst should be the voice of the PO, but any member of the team should feel they can approach the PO directly with suggestions or ideas at any time. Only clarifications on requirements should first be directed to the Requirements / Business Analyst, so they can act as a “filter” to make more efficient use of the Product Owner’s time. When I think about the proportion of “PO questions” where my answer was to go back to the story and re-read the ACs, it was probably about 30–50%, so still a significant time saving!
Conclusion
If the PO spends 1 hour a week 1:1 with the BA, attends 1 refinement session (2 hours) and 1 or more demos totalling ~30 minutes per week, it is possible for them, theoretically at least, to spend fewer than 4 hours per week on backlog refinement activities.
I disagree however that this is best achieved by the PO ceasing to be involved in backlog management and refinement altogether, as David Pereira suggests. Experience has shown me that Scrum teams need fairly detailed user stories and QAs, in particular, need detailed acceptance criteria, in order to carry out their roles without needing to ask too many questions of the PO (or Requirements Engineer) mid-sprint, when everyone is trying to get on with the rest of their day-jobs.
Requirements analysis and user story refinement need to happen, even in an Agile environment, but I am now more comfortable with the idea that it doesn’t have to be done or even led by the Product Owner or Manager.
I also disagree that Product Owners and Managers are not backlog owners. Detailed requirements analysis and other aspects of the PO role may be delegated, but the ownership and accountability for the backlog content and prioritisation should, in my opinion, remain squarely with the PO; as we are best-placed to assess the holistic business value of each user story, based on all the contextual information we absorb doing the ‘other half’ of our day-jobs.
As for my fear of putting someone in the “demoralising” position of being my BA… Well, when I think about it, that was how I learned my craft as a PO, so maybe that wasn’t such a bad thing after all, frustrating though it may have seemed at the time because I knew, in my heart, that I wanted to be the "real" Product Owner.
I did however make the incorrect assumption that all Business Analysts have the same outlook I did. I now realise that everyone has different career aspirations and I know some excellent BAs, who have made highly successful careers out of pure business, requirements and systems analysis, without wanting to get involved in the politics that often comes with product management. I also know some fantastic Product Owners, who have grown ‘organically’ into the role like I did — learning the ropes by shadowing a PO and observing how they prioritise the backlog, interact with senior stakeholders, clients, etc. Furthermore, not all Product Owners are detail-oriented or from an analytical background and might prefer to draw the line at writing high-level (but not “broken”!) user stories, without getting into requirements analysis or writing gherkin acceptance criteria.
In conclusion, I am inclined to agree with Florian Sperber’s comment that the Product Owner / Manager role is, or can be, two separate roles with distinct but overlapping skill sets. I however won’t be throwing my user story writing and backlog management handbooks out the window any time soon.
Comentarios