Moving Beyond “The Backlog” – The 4 Quadrants of Product Ownership, Part 2
In part one of this two-part article, we explored the first two quadrants. Here we will complete the quadrants and wrap things up. First up is the notion that the Product Owner is also a “leader” within the team.
Quadrant 3: Leadership
All right you say…enough is enough! Product and project management are both fairly pervasive responsibilities. Now you suggest that a Product Owner has to “worry about” leadership as well?
Well, yes, that’s exactly what I’m saying. In fact, it may be the most important quadrant from an overall team perspective. The first leadership aspect relates to the products themselves. Product Owners have a responsibility to establish a vision for their work. Along with this is goal-setting. So many Scrum teams forget that Sprint Planning starts with a “Sprint Goal” that the Product Owner brings into the meeting.
Beyond goal setting, the Product Owner needs to provide individual leadership to their team. This implies a connection to the team, membership, and loyalty—something that the team ‘feels’ in every interaction.
Perhaps this story can help explain it…
Are you simply a “Business Savant”?
I was presenting an agile workshop not that long ago and I presented the group with this scenario:
One of your team members is pregnant and going on short-term maternity leave. She will be gone for 8 weeks and then return. In terms of your iterations, she’ll be gone for 4 sprints. She happens to be the strongest Database Architect and Engineer on your team. Yes, there are two other less experienced Database Engineers, but they both usually need Susan’s experience to help them along in their tasks. In fact one of those is a college intern, quite bright by the way, but inexperienced nonetheless.
It just so happens that your backlog is filled with Database-centric work at the moment; aligned towards some major features you wanted to get into the next release. Probably 75% of each sprint is heavily skewed in this way.
So here’s the million-dollar question, as the teams Product Owner, do you change the strategy and focus of the backlog based on this event? Or do you continue to drive current priority into the team and expect them to deliver as always? And these changes could be major or subtle; the question is: do you (or should you) change anything in your workflow because of this ‘event’?
I would contend that the answer is a resounding—Yes! That you shouldn’t be solely driven by blind value and priority, but that “situational awareness” is needed on the part of great Product Owners. This to me is an example of principled leadership and having the courage to adjust as required, while still keeping your eye on the overall project and business goals.
Change this example around to shift the Product Backlog flow to amplify your teams’ strengths and minimize their weaknesses.
- Or to give them work that is interesting and challenging;
- Or to be sensitize to the amount of technical challenge you give them on a sprint-x-sprint basis;
- Or to consider the teams’ feedback when planning for defect repairs, refactoring or implementing automation;
- Or to allow (better yet, foster) innovation on the part of the team towards solving the customer’s problems rather than simply implementing by-rote feature lists.
All of these reactions are fair game from my perspective in a Product Owners journey in translating business needs towards team implementation. Point being—there’s a balancing act that needs to be achieved and it’s not totally skewed towards the organization.
Communication & Defense
In my Scrum Product Ownership book, the sub-title is Driving Business Value from the Inside Out. What I meant by that sub-title was that the Product Owners primary responsibilities were toward the team. That only by caring for and feeding the team well, could they deliver on the quality, value, and productivity promises of the agile methods. That delivery of results was through the team.
To that end, part of the leadership responsibility is to be a primary communication mechanism for their team. Sure, the Scrum Master role has communication as a strong responsibility, but rarely does the Scrum Master get the opportunities for communication that the Product Owner receives. You’ll be interacting with senior leadership, stakeholders, and customers. Please take the time to communicate all aspects of your teams’ efforts and progress.
If someone questions an aspect of your teams’ efforts, come to their defense. Keeping in mind that you are also a member of the team; so they’re questioning your efforts as well. Remain fully transparent in communicating your backlogs, plans, and efforts.
A final word on your leadership role relates to the Scrum Master. In my coaching, I strongly encourage each team’s Scrum Master and Product Owner to establish a leadership partnership between them. A part of this is role overlap when it comes to leadership dynamics. But beyond that, I think agile teams need a modicum of leadership in order to inspire them to high performance. This partnership can help provide that balanced leadership.
Quadrant 4: Business Analysis
There’s an incredible amount of discussion in the traditional Business Analysis (BA) community about the role that BA’s should fill within agile teams. Some take the perspective that the role is exactly the same. That is, eliciting and defining upfront requirements and then handing them off to the team for implementation. I would disagree with this view.
Others take the position that the Business Analysis role continues, but it transforms quite a bit. That there are more partnerships required—partnerships with the team, with the testers, and most importantly with the customer or Product Owner. And that the role is not solely an upfront focused role, but rather continuously engaged throughout each release. That Business Analysts are, if you’re lucky enough to have them, a member of the Scrum team. I subscribe to this view.
If we circle back to the definition of a Product Owner being the owner of the Product Backlog, then the Business Analyst quadrant activities become quite clear. Ultimately the backlog is composed of Product Backlog Items, User Stories, or dare I say it, “requirements” for the team. To that end, these stories need to be well written and developed with the team. If the Product Owner has a BA background, then they are nicely suited to lead this work. But what if they don’t have that background? Then it becomes a whole-team activity and BA’s, who are incredibly skilled at writing requirements and specifications, bring a lot of value to the team here.
If you leverage the User Story format for your backlog items, then they are iteratively defined with the team. Not only do they contain a functional description, but they also contain “conditions of acceptance” from a business perspective. Here the Product Owner plays a part in communicating to the team the value proposition and nuance you’re looking for in each feature. It’s so important, that I want to explore it in a bit more detail next.
Acceptance Criteria or Tests
User Stories were invented or developed as a requirement artifact in the Extreme Programming space. The intention was to develop a low fidelity (3×5 card) construct that would be developed to ‘contain’ software features, requirements or work items. These would be low investment artifacts, from the perspective of writing, but they were intended to drive high collaboration and discussion.
Many teams focus on the “story part” of the User Story and don’t attend to the acceptance criteria. I personally feel these are incredibly powerful. First of all, they communicate the aspects of each story that the Product Owner and customer values, what are important or crucial system behaviors, and what are the critical checks that need to be made.
But beyond that, acceptance criteria provide incredible hints to the team. From a developer’s perspective, they communicate key design constraints. From a testing perspective, they communicate much towards the effective risk-based testing strategy for each story. They help the team balance effort to priority to value for each story. They drive questions, answers, and ongoing clarification.
Business Analysts are in a wonderful position to help iterate on story evolution as the team attacks their understanding of the work and its ultimate execution and delivery. Often they serve as a crisp communication and details liaison between the customer and the team.
Partner with Business Analysts
I often find that this quadrant is a challenge for most Product Owners. They have a tendency to be much more comfortable with Product Management and Leadership. Project Management is sometimes a challenge or stretch, but they typically ‘get’ most of the planning aspects of the backlog.
However, writing good agile requirements or User Stories can often be an intimidating chore. Here’s an excerpt from my book that illustrates that challenge…
I met a Product Owner not that long ago who was quite stressed out. He was relatively new to his company. While he had some agile experience, being immersed into a new agile environment, team and domain was quite intimidating.
I came into the organization as a coach and was just trying to get a sense for the environment. He quickly pulled me aside and confronted me with a problem. He complained that he simply didn’t have the time to construct stories, or a backlog for his team.
It turned out that he’d been working into the night for the past 2 weeks to get an initial backlog together. His team was “waiting for it” and it was taking him a long time to get the backlog completed. He was struggling with his domain experience and technical understanding of the products underlying architecture. He was also struggling with writing effective acceptance tests for the stories. Since he was new, he kept working on them; trying to create the “perfect backlog” before ‘presenting’ it to his team.
I can’t tell you how stressed out and exhausted he was.
I suspect my reaction might have seemed odd to him. I asked him to immediately stop working on the backlog stories. Instead, I asked him to schedule a story-writing workshop where he, and his team, would sit down and create the backlog TOGETHER. I told him to bring his current story mix into the meeting – as-is. It would serve as a nice starting point for the team.
I reminded him that the Product Owner shouldn’t ‘own’ writing all the stories; that the Product Owner role was more of a backlog facilitative role. I also reminded him to leverage the whole team in crafting a solid backlog and that he never had to “go it alone” in preparing a backlog.
I ran into him after the first workshop and he appeared incredibly relieved. He said the workshop was outstanding and he was amazed at the ability of his new team to rally around fleshing out his ideas. His renewed energy and enthusiasm were music to my ears.
And beyond the whole-team aspect of this story, imagine if you have Business Analysts available to you as a Product Owner. What a wonderful that partnership that would create as you guide a rich stream of well crafted stories towards your team.
I said in my book that Scrum Product Ownership is arguably the hardest job on an agile team, whether you’re operating as an XP customer, Scrum Product Owner, or other customer-centric role. While collaborating around the Product Backlog is a central part of the role, I think that view is way too narrow.
I hope the 4 Quadrants sensitize current and potential Product Owners and their organizations to the true depth and breadth required to do the role well. It also helps when staffing the role, planning training, and allocating others to support the Product Owners own skills in fully supporting all aspects of the quadrants.
Way too often I see organizations trivialize the role and overwhelm single Product Owners with all aspects of the role—independent of their skill and time. Now our focus should be across the quadrants towards “feeding the team well”.
Thanks for listening,
Don’t forget to leave comments below.
 User Stories are refined within the team during a process called Backlog Grooming or Backlog Maintenance. The team will typically ‘see’ each story several times as it moves from a large-scale Epic or concept definition to an much more finely decomposed, understood, well estimated, and executable story in each sprint. I have a rule of thumb that a story should be groomed 3-4 times by a team as it moves towards execution and as the team decomposes and refines it. This is what I’m implying by “iteratively defined”.
 Scrum Product Ownership, 2’nd Edition