Advanced Product Owner Questions

Neil Benson:  [00:00:00]Welcome to the Amazing Applications podcast for Microsoft Business Applications creators who want to build amazing applications that everyone will love. 

 Hi, I'm your host Neil Benson. Our goal on this show is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks and create amazing, agile Microsoft Dynamics 365 and Power Platform applications.

Welcome back to the Amazing Applications podcast. If this is your first time tuning in, then a very special welcome to you. I'm glad you're here. 

Show notes for this episode can be found at customery.com/043, where you'll find a transcript for this episode, as well as resources to dive deeper into the [00:01:00] topics we're going to cover.

Today's topic is advanced product owner questions. 

But just before we get started, I want to congratulate Kevin Lo at ITK consulting from Vancouver in Canada. Kevin recently completed my Scrum for Microsoft Business Apps course and achieved his Professional Scrum Master level one certification. Well done, Kevin. You're a legend. 

My Scrum from Microsoft Business Apps course has recently been updated with over 30 new videos to help you learn the Scrum framework, proven practices for applying it to Dynamics 365 and Power Platform projects. I've extended the quizzes, expanded the case studies, and revamped the practice exam. You can find out more at customery.com/scrum. 

  This episode's topic is advanced product owner questions. If your podcast player supports chapter markers, you should be able to jump between the chapters quickly to find the one that interested you [00:02:00] most and you can play it back again later. 

Let's go.

Linda the product owner: Hay Neil, this is Linda. I'm a product owner for a Dynamics three sixty-five application, and I have a few questions for you. First of all, can the product owner role be combined with scrum master or developer? 

Neil Benson: There's nothing stopping teams having a joint product owner-developer or product owner-scrum master. And there probably are some business apps teams who have built good business apps with a small team where the product owner role was combined. But I wouldn't recommend it. 

First of all, the product owner role is a tough role to fulfill. There's a lot to do: managing the product backlog, working alongside the scrum team and looking after all the application stakeholders is a full-time role for most product owners. Where are you going to find the time to also build increments of the application or coach the scrum team? So capacity is one issue.

Another is skillset. The type of people who make a great product owner [00:03:00] rarely also make great developers or coaches. That doesn't mean it's impossible, of course, but it's highly unlikely that if you're a good Dynamics 365 or Power Platform developer, that you're also going to be a good product owner. 

Perhaps product management is a career path that you want to pursue, and you'd like to develop your skills there, but trying to fulfill the product owner role at the same time as a developer role, it's going to drive you crazy.

Lastly, I think there's an inherent conflict of interest between the product owner's accountabilities and those of the scrum master and the developers. The scrum master serves the developers and the product owner, and also serves the organization in its adoption of Scrum. The developers serve the product owner and are collectively responsible for their progress building the product. The product owner serves the application's stakeholders and is accountable for the value that the application brings to them. 

One of my clients, Frieda Maher at the University of New South Wales, [00:04:00] compared it to building a house. You have the homeowner, the architect, and the builder, and there will always be some tension between them.

Sometimes, the homeowner and the builder will think the architect's plans are crazy. Or the architect and the homeowner will be frustrated with the builder's quality. Or the builder and the architect will find the homeowner to be completely unreasonable. 

But no one has ever built a house where the homeowner, the architect and the builder were always perfectly content with one another for the entire build. I think that's a great analogy for our scrum team, where we have the product owner, the scrum master, and the developers.

 If the product owner has to combine her roles, she has to split her accountabilities and whom she serves. For tactical applications built by a small team, you might find it's possible to have a product owner combo, but I wouldn't risk it on an enterprise application with a larger team.

Linda the product owner: Hi Neil, it's Linda again. [00:05:00] Which product owner certification would you recommend? 

Neil Benson: Debbie D'Arcy, a Dynamics 365 consultant in Philadelphia, asked me about Professional Scrum Product Owner certification with Scrum.org recently. I took my Professional Scrum Product Owner, the PSPO, certification assessment a couple of years ago because I believed I'd be a better scrum master and able to coach my product owner if I understood the product owner role better. And I still believe that's true. 

Whether you want to pursue a career in product management or just to be a better scrum team member or scrum master, the PSPO is a worthwhile certification to pursue. It'll help you understand the role of the product owner and the art of product backlog management, whether or not you ever go on to fulfill the product owner role. I definitely recommend it if you are a product owner, or a business analyst, or scrum master that supports product owners. 

If you already have the Professional Scrum master [00:06:00] certification, PSM, which is the first certification I recommend for all Scrum team members, you'll find that there's a lot of overlap between the Professional Scrum Product Owner's certification assessment and the Professional Scrum Master certification assessment.

As you'd expect, the PSPO covers backlog management in greater depth. If you already have the PSM certification and experience as a product owner, then you could study a couple of books and achieve the PSPS certification assessment. Save your training investment for a PSPO II class, which is much more intensive than PSPO I, and it's where I would invest my training budget if I wanted to pursue a career as a product manager. 

The three books I'd recommend for PSPO 1 are The Professional Scrum Product Owner, Product Mastery, and Agile Product Management with Scrum. I'll include links to those books in the show notes.

Linda the product owner: As a product owner, how would you recommend I make decisions about the product [00:07:00] backlog? 

Neil Benson: The product owner accountable for the product backlog. I recently read that the difference between accountability and a responsibility is that a responsibility can be shared and or delegated, but accountability can't. I really like that definition. 

The product owner is accountable for the product backlog. She can delegate some responsibility for managing it but remains accountable. 

There are often lots of small decisions about the product backlog that the product owner can make on her own. Not every decision needs everyone's buy-in or involvement. Judging which decisions are minor and can be made alone and which decisions are major and will benefit from consultation is a key product management skill. 

A great product owner involves her stakeholders and developers in any decisions that involve the product strategy or the product roadmap. For example, if you decide to deliver a Power App with offline capability or decide to drop offline [00:08:00] capability, when you had previously set the expectation that it was included, that's a product strategy decision. Or if you determined that you're going to spend an extra four sprints nailing the offline functionality for your users, that would be a roadmap decision worth consulting with your stakeholders and developers. 

When it comes to involving your stakeholders in your decisions, you might want to map out your stakeholders based on their level of interest or engagement on one axis and their level of influence on the other.

The stakeholders you need to involve are those with the highest levels of interest and influence. So, if you plotted them on that axis in a grid, those would be the stakeholders in the top right-hand box. Make sure you engage those ones in your product strategy and roadmap workshops. 

It's a good idea to have those workshops facilitated. Hopefully, your scrum master has the facilitation skills and experience to help you manage a room full of highly engaged and influential stakeholders and your developers. [00:09:00] Keep an open mind to the feedback coming from your developers and stakeholders and listen actively to different points of view. 

Then you'll need to decide how you're going to make decisions. Are you going to seek a unanimous decision that requires everyone's consent or is a majority sufficient, or you as the product owner going to decide on your own after discussion?

Unanimous decisions are great but can take a long time to reach and will usually involve making compromises. Whereas, unilateral decisions made by you, the product owner on your own are much faster, but probably won't achieve the same levels of buy-in and could even alienate stakeholders with dissenting views.

Don't rush important decisions. Take your time to consult with the appropriate stakeholders and gather the data necessary to support rational decision making. 

Finally, don't let your stakeholders dictate your product backlog decisions. By all means, [00:10:00] listen to their requests and ensure you understand their perspective, but you're not going to be able to please everyone all of the time. Make the best possible decision you can so that you build the best possible business application and don't agree to a weak compromise.

Linda the product owner: Neil, do you think the product owner needs to be technical?

 Neil Benson:  No, I don't think the product owner is a technical role. I don't think you need to be a technical person to be a good product owner. Product owners don't need to be certified or experienced in Dynamics 365 or Power Apps or Power BI. They'll certainly learn something about their technology as they're part of the team building the applications. But none of the amazing product owners I've worked with started out as technical experts. Most of them didn't end up as technical experts either. 

In the types of business applications that we work on, it's common for the product owner to be a business stakeholder, with experience in whatever domain relates to your application, it could be marketing or sales or HR or procurement or finance, [00:11:00] or whatever.

That's the expertise we need them to have. The technical expertise is supplied by the developers, and they can draw upon the deeper experts outside the Scrum, if and when they need it. 

I've seen scrum teams have a business product owner and a technical product owner, and I've never understood the rationale for having a technical product owner.

It's fine for the product owner to have a technical advisor, like a solution architect or a technical architect or a CTO, either in the scrum team or outside of it. That technical advisor can provide those technical insights, perspectives, advice, and maybe be some policy guidance. But I think it confuses the team to have a technical product owner, as well as a business product owner.

Let's just have one product owner with business domain expertise who is supported by technical stakeholders when required.

Linda the product owner: In your opinion, Neil, what's the difference between a product owner and a project manager? 

Neil Benson: Okay to answer this one, [00:12:00] I'm going to try and avoid going too philosophical and keep it brief. Here goes. 

The product owner is accountable for maximizing the value of the product to the organization. That is, the product owner sets the vision, the goals, and manages the scope of the application by managing the backlog to maximize the impact that it has for its stakeholders. The product owner role lasts as long as the product lasts. If your application is still in production, it should have a product owner. 

On the other hand, a project manager is a temporary role. Projects start up and they are closed down. They're not supposed to last forever. Although we've probably all been on projects that we thought would never end. Um. Most project managers are concerned with completing the project on time and on budget. The value or the impact that the application has is not usually the project manager's concern because in a traditional project, it's a project [00:13:00] sponsor's role or somebody else's job to ensure that there was a valuable business case and the application we're building is worthwhile. 

Having said all of that, when I'm using Scrum to build Dynamics 365 and Power Platform apps, it's almost always as part of a project. My Scrum projects often have a product owner and a project manager. The product owner is there to do what product owners do, maximize the application's value and impact. The project manager is there to assist the product owner with things that project managers are good at: managing resources and budgets, risks, and contracts, and all those other things that great project managers excel at. 

Eventually, the project to build the application will come to an end and the project manager and most of the Scrum team will go off to greener pastures. The product owner will still be the product owner, managing a backlog of enhancement requests, upgrades, and fixes that will usually be developed by a different [00:14:00] often smaller team of developers in a business-as-usual capacity.

Linda the product owner: Does the product owner have to accept the developers' increments in the sprint review? 

Neil Benson: When I learned Scrum in about 2008, the developers presented completed sprint backlog items at the sprint review. It was the product owner's role to assess whether the items were acceptable and could be considered done. 

Today, we use a definition of done, which is agreed upfront so that they Scrum team can tell at any time during the sprint, whether an item is done. If it's been verified as having met its acceptance criteria and the team's definition of done then a sprint backlog item is a done increment. 

The product owner should be checking to ensure that verification takes place either by reviewing the system test results or user acceptance testing feedback, but she doesn't have to do that verification herself, and it doesn't have to wait until the sprint review.

Linda the product owner: In [00:15:00] your experience, what does a typical sprint look like for a product owner?

 Neil Benson: I get asked this question a lot, usually by Microsoft partners who want to know what expectations they should set with their customers about the capacity required of the customer's product owner. 

Let's walk through a sprint from a product owner's perspective and see how much time it takes.

 Imagine Linda, she is the product owner for a team running a two-week sprint.

She's got the Scrum events to start with:  sprint planning, daily scrums, which Linda is happy to be invited to, the sprint review, and the sprint retrospective. There's often some follow-up after daily scrums, maybe a session or two with a developer to discuss any particular items or impediments. So, let's call that a day and a half's worth of work. 

When the developers are close to done with an item, Linda likes to give them some early feedback before all the development and testing is complete. And she schedules a few of these feedback sessions each sprint, which [00:16:00] takes another half day it total. 

Backlog refinement is a major activity for Linda. She usually spends a day each sprint thinking about the medium-term or long-term roadmap. Most of that time is spent in workshops with her stakeholders to ensure she understands what they need, and then drafting sprint goals for sprints a couple of months from now and starting to refine epics into smaller user stories. 

She spends another two days each sprint working with the developers on near-term product backlog refinement. Reviewing items near the top of the backlog, refining them further and reordering them for the team.

One of the developers is a business analyst that supports Linda with the work of writing the user stories, adding acceptance criteria, and BDD scenarios. Linda likes to check in with the business analyst and review the stories before the developer's backlog refinement workshops, where they discuss the items further, clarify them, discuss different design options, and estimate them. All told that's another two days’ worth of effort. [00:17:00]

Linda's application is in production. There's a proof of concept out there with one of the organizations divisions, and she spends one day each week reviewing feedback and help desk issues, meeting with the users, and reviewing telemetry from the Power Platform Admin Center and Application Insights. That's another half days’ worth of work. 

Engaging her stakeholders and keeping them updated on the team's progress and gaining their assistance or approvals is where Linda spends the majority of her time. She has workshops with her manager and several senior stakeholders, every sprint. And she has to prepare a few presentations, review timelines and budgets with the steering group, review risks and issues with the internal auditor and risk management teams. That's another two days’ worth. 

She meets with the IT group often as well: information security, enterprise architecture, enterprise integration, data and analytics, and the operations and support groups, as well as identity and access management. There are normally several [00:18:00] workshops each sprint handling all that IT stuff. A developer or two might join her but Linda likes to get to understand the technical issues that the team needs to deal with. She spends one day each sprint in technical workshops. 

Working with her stakeholders in procurement, contract management, and finance, Linda spends half a day each sprint ensuring the budgets are on track. 

Linda also gets involved in recruitment and resource management tasks, like giving feedback to the scrum team members. She has meetings with Microsoft and her Microsoft partner account team. On average that's another half a day each sprint. 

So that's, I don't know, eight or nine, 10 days in total, I'd have a maximum capacity of 10 days in a sprint. That workload is fairly typical among the product owners I've worked with to build enterprise business applications.

What about you? Has it been any different in your projects? 

So now you can see why I think the product owner role is a full-time role. Being accountable for an enterprise business application is not something that someone should try and do [00:19:00] in their spare time or in addition to their line of business role.

That's all we've got time for in this episode. Remember, you can find show notes for the episode at customery.com/043. And find out more about my Scrum from Microsoft Business Apps online course at Customery.com/Scrum. That's the word CUSTOMER with a Y on the end dot com slash Scrum. 

I'm going to try and keep the regular podcast episodes going while at the same time continuing to improve my course and produce new courses, create more videos on YouTube and LinkedIn, and I'm starting up a new consulting project. So, forgive me if I miss the occasional podcast episode. 

But I do appreciate all your support for the show. I love it when somebody joins the Customery Academy and says they've been listening to the Amazing Applications podcast for a while. That makes it all worthwhile. Thanks very much, I really appreciate you. Until next time, stay safe and keep [00:20:00] sprinting.