The Product Owner

Hi, I'm your host, Neil Benson. In this episode, I describe the role of the product owner in Scrum and how it applies to our Dynamics 365 and Power Platform projects. You'll find show notes for this episode at Ireland beat England this weekend, when the rugby union six nations grand slam trophy on St. Patrick's day and Dermot tells me he's been on a training course for the last three days. And as they are unable to join me for this episode, I reckon he's still celebrating and dancing in the streets somewhere. Good on your Dermot. I hope you make it back safely for our next episode. And this session I wanted to highlight the role of the product owner and dynamics 365 projects.

Let's start. The product owner is the person ultimately responsible for maximizing the value of dynamics 365. If you're the most senior stakeholder in the organization implementing dynamics 365 and the projects, your responsibility, then you're the product owner as your job to decide the goal for each sprint to prioritize the product backlog, to accept completed features and decide when to release them into production.

The product owner makes the trade-off between features, timelines, budget, and quality to achieve. As many of the projects I'd comes as come. The product owner is the critical link between the scrum team and the project stakeholders. And it's their job to represent the users by defining and prioritizing the user's requirements.

The product owners also communicates the scum team's progress back to the other stakeholders in the organization. And my experience product backlog management is the key to successfully maximizing the value of the scrum team. Here are five ways. The product owner managers to product X. Number one, optimizing the development team's work by participating in sprint planning, sprint review, and sprint retrospective meetings.

Participating in these Scrum events is crucial to by clearly expressing product backlog items in my dynamics, 365 projects. This means writing good user stories with meaningful titles and descriptions. Number three. By helping the dev team understand the product backlog items by adding acceptance criteria and discussing the items during backlog refinement and sprint planning events, number four, prioritizing the product backlog so that the most valuable items are at the top.

Highest value usually means the most valuable to the organization, but their product owners can take any other factors into account to achieve the organization's goals. I'm number five, making the product backlog transparent and highly visible to both this com team under dynamics 365 users and the organizations, other stakeholders.

Everyone should know what's in the product backlog and what's going to be worked on next. I've worked with lots of grid, product owners of my dynamics, CRM and dynamics 365 projects. Here's a quick shout out to Debbie at premier medical, Peter guys, hospital Beth at advantage solutions, Steve at American homes and Frieda I, one of our current goals.

Here are some characteristics. All those product owners shared domain expertise. The product owner needs to understand their organization's industry, the organization itself, including history structure, processes, their organization's stakeholders, including their objectives and some of their politics and having a deep appreciation of the users and what they want and need leadership expertise, including a compelling vision for how dynamics 365 is going to help the organization.

The ability to make decisions that involve those trade-offs between features, budget, timelines, and quality, and the authority to make those decisions stick. Even when some stakeholders don't get their way and the communication and people skills to engage and become trusted by the users, the scrum team on the project, stakeholders, accountability, accountability for the success of dynamics 365.

This involves being committed to meeting the project's objectives as the highest priority. Being comfortable as the person responsible for making decisions and owning the outcomes of those decisions and making him or herself available to the scrum team. The perfect product owner then is somebody who is expert in their industry expert in the organization with the stakeholders and the users as a leader, possesses a vision decisive decision making authority and has the people skills to engage the stakeholders on the scrum team and as a credible, by being committed to the project, responsible for its outcomes and available to the scrum.

But you know what the perfect product owner doesn't exist. I've worked with some fantastic product owners, a massively successful dynamics, 365 projects, and none of them met all of those criteria. Sometimes you just have to do the best with who you've got and have your scrum master coach, the product owner as far as possible.

So how does that successful product on our spend their time product owner has spent a significant amount of their time managing the bank. They write the user stories, prioritize them out acceptance criteria and explain them and answer questions about them. With the dev team, they'll spend a few hours in the sprint planning meeting to help the dev team understand the sprint goal and develop the sprint backlog.

They'll often attend the daily scrums to get a sense of the dev team's progress to answer any questions and resolve any day-to-day issues. They'll accept completed items during the sprint review and confirm the priority of items at the top of the. Most product owners also have got some project governance responsibilities working with the project management office or the project steering group that leaves them to the less than 50% of their time for their real job.

I've never worked with a product owner that could just give up whatever their job was before the dynamics project to become a full-time product on it. Let's take a look at how we can help product owners with this capacity. So help can come from proxy product owners, a proxy product owner is someone that the ultimate product owner has delegated some of their responsibility to.

Here's a couple of examples. I proxy product owners. It could be a business analyst who can help put it on our express product, backlog items, but writing user stories and helping the dev team understand those stories. It could be a quality analyst who helps the product only with writing good acceptance criteria and testing the stories to make sure that they meet the acceptance criteria and the definition of.

It could be a change manager to work with the project stakeholders to communicate progress and organize user training and the features being deployed in the next release, or perhaps a project analyst to manage budgets, risks, and resources. If you're a product owner is going to be assisted by proxy product owner, make sure that there's still one single person acting as the chief product owner ended up person still responsible for prioritizing the product.

In many situations, one or two proxy product owners can help, but ensure that you don't end up with a committee of product owners. If you've got two product owners, because you're deploying dynamics 365 to two different divisions within an organization, then really you've got two different projects, either split your scrum team into two or deploy dynamics in one division after the other, here are my top 10 tips for product owners.

Number one. Find a scrum master. You can trust the relationship between the product owner and the scrum master is critical to the success of your project. Usually as the product owner, you're employed by the Microsoft customer implementing dynamics 365 and the scrum masters employed by Microsoft partner, or maybe your internal it department, there should be a healthy tension in that relationship.

I was one of my clients puts it the relationship between a product owner, the scrum master and the dev team should be like the relationship between someone building a house, their architect, and the builder. Usually two of those parties going up and don't like the other one at some point in time. Number two, know your stakeholders.

One of the smartest things you can do politically unproductively is to get really close to your stakeholders, especially your users. Get to understand their perspective, good product owners, sit with our users and understand their roles today and what they want from the new system, separate what they want from what they really need and be clear on their needs inside of node, validate that you're prioritizing the product backlog based on what the stakeholders really need rather than your own.

Number three, realize that you're part of the team. The scrum team includes you, the product owner, but you don't run the team. It's your job to make the hard decisions and prioritize the team's work, but you're not in control. You're part of the team you're not running the team. Number four, let the dev team design and develop the features.

I've seen product owners, clash with dev teams when they try and tell developers how to implement it. It's your role to provide guidelines regarding things like the acceptability of custom development or third-party apps or which system is going to be the system of record, but work with your dev team to understand the options on their recommends.

Number five, you don't only estimates. It's the dev team's role to estimate the complexity of product backlog items. The product line can definitely work with the dev team to understand surprisingly high estimates, but don't try and force developers into your estimates. They're the ones performing them.

Number six, let the dev team organize itself. Don't ask Leon to implement this feature or Vanessa to implement that one. Trust the developers to organize themselves work with your scrum master. If you see an issues, but step back and allow the dev team to self-organize. Number seven, minimize meetings, scums already got planning, review and retro meetings, every sprint and ideally Scrum.

Some product owners get carried away with long backlog refinement meetings. I recommend short story time sessions to clarify future backlog guidance with some of the developers. Timebox every meeting and stick to your time books. Number eight, here's all the tools you can, as well as the scrum board, try using burnup or burn down charts, reminders by the definition of done story maps and any other tools you can to help the dev team or to help make your life here.

Number nine, be negotiable work collaboratively with your scrum masters and dev team, especially when they request to work on technical debt. Technical debt is when dynamics 365 has become more complex than necessary and could be simplified so that it's easier to extend, maintain, or upgrade. Let your team pay down technical debt by refactoring the system occasionally.

And finally, number 10, get certified. There's lots of good resources available for product owners, including books and training. If this is your first time as a product owner, consider the professional scrum product owner certification from Scrum dot org. To help you learn the basics. Finally, where do good product owners come from?

I find it the best product owner is a senior stakeholder in your organization within the division or department that will be using dynamics 365. This could be a sales marketing customer service executive, maybe even an operations or finance leader, unless you're deploying dynamics 365 as an it service management.

The product owner, shouldn't be an it person. And don't try and mix the product on a role with another scrum team role, such as the scrum master or developer. The product owners role is to choose which problems to solve the developer's role is to solve those problems. And the scrum masters role is to coach everyone else in the application of the scrum framework to solving complex problems.

Okay. That's it for product owners, the expert be visionary, pick huntable and. I'll see you in the next episode when termin spike, I hope. And we'll be discussing the role of the scrum master.

Thanks so much for listening to the Amazing Apps podcast. You can join the show's mailing list at https://AmazingApps.Show. You'll get a personalized welcome video from yours truly, and a notification when there's a new episode available. 

There are also shortcuts so you can follow the show on all major podcast players and you can follow Amazing Apps Show on Twitter, LinkedIn, YouTube, Instagram, and Facebook.

You can send me a message or a voicemail if you'd like your question answered on a future episode and even support the show through BuyMeACoffee or by buying an Amazing Apps t-shirt.

 Visit https://Amazing.Apps.Show. 

Thanks again for listening. I really appreciate you. Until next time, take care and keep sprinting!