Dynamics 365 Product Owners
This article, and the accompanying podcast episode, introduces the role of the Product Owner in Dynamics 365 projects:
The primary responsibility of the Product Owner
Five ways the Product Owner manages the Product Backlog
Characteristics of great Product Owners
How a Product Owner spends their time
How to use Proxy Product Owners
Top ten tips for Product Owners
Where do Product Owners come from?
What is a Product Owner?
In Scrum, the Product Owner is the person ultimately responsible for maximising the value of Dynamics 365.
If you're the most senior stakeholder in the organisation implementing Dynamics 365 and the project is your responsibility, then you are the Product Owner.
It's your job to decide the goal for each sprint, to prioritise 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 project's outcomes as possible.
The Product Owner is the critical link between the Scrum Team and the project stakeholders. It's your job to represent the users, by defining and prioritising the users' requirements.
The Product Owner also communicates the Scrum Team's progress back to other stakeholders in the organisation.
In my experience, Product Backlog management is the key to successfully maximising the value of the Scrum Team.
Here are five ways that the Product Owner manages the Product Backlog:
Optimising the Development Team's work by participating in Sprint Planning, Sprint Review and Sprint Retrospective meetings. Participating in these Scrum events is crucial.
By clearly expressing Product Backlog Items. In my Dynamics 365 projects, this means writing good users stories with meaningful titles and descriptions.
By helping the Dev Team understand the backlog items by adding acceptance criteria and discuss the items during backlog refinement and sprint planning events.
Prioritising the backlog so that the most valuable items are at the top. Highest value usually means the most valuable to the organisation, but the Product Owner can take other factors into account to achieve the organisation's goals for the project.
Making sure the product backlog is transparent and highly visible to both the Scrum Team, the Dynamics 365 users and the organisation's other stakeholders. Everyone should know what's in the backlog and what's going to be worked on next.
Characteristics of Great Product Owners
I've worked with lots of great Product Owners on my Dynamics CRM and Dynamics 365 projects: Debbie at Premier Medical, Peter at Guy's Hospital, Beth at Advantage Solutions, Steve at American Homes and Frieda at one of my current clients.
Here are some characteristics they all shared:
Domain expertise. The Product Owner needs to understand the organisation’s industry; the organisation itself including its history, structure, processes; the organisation’s stakeholders including their objectives and politics; and have a deep appreciation of the users, what they want and need.
Leadership. Great Product Owner possess a compelling vision for how Dynamics 365 will help the organisation meet its goals; the ability to make decisions that involve trade-offs in 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 and 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 in their work; being comfortable as the person responsible for making decisions and owning the outcomes of those decisions, and making her- or himself available to the Scrum Team.
The perfect Product Owner: is an expert in the industry, the organisation, with the stakeholders and users; is a leader who possesses a vision, decisive decision-making authority and has the people skills to engage the stakeholders and the Scrum Team; and is accountable by being committed to the project, responsible for its outcomes, and available to the Scrum Team.
But the perfect Product Owner doesn’t exist!
I’ve worked with some fantastic Product Owners on massively successful Dynamics 365 projects. None of them met all those criteria. Sometimes you must do your best with who you’ve got and have your Scrum Master coach the Product Owner as far as possible.
How does a successful Product Owner spend their time?
Product Owners spend a significant amount of their time – about 10 hours each week - managing the Backlog. They write stories, prioritise them, add acceptance criteria, explain them, and answer questions about them with the Dev Team.
During a typical sprint, a Product Owner will spend:
Two to three hours in the Sprint Planning meeting help the Dev Team understand the Sprint Goal and develop the Sprint Backlog.
Fifteen minutes a day at the Daily Scrums to get a sense of the Dev Team's progress, answer questions, resolve any issues.
Two to three hours at the Sprint Review accepting completed items and reviewing the Product Backlog with stakeholders.
Ten to fifteen hours in backlog refinement workshops explaining backlog items to the Development Team.
An hour at the Sprint Retrospective working with the team to review their practices the development process.
Three or four hours on their project governance responsibilities, working with the project management office or project steering group.
When you add up all these project responsibilities, most Product Owners spend more than half their time working on the Dynamics 365 project.
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 Owner.
Let's look at how we can help Product Owners with this capacity challenge.
Proxy Product Owners
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. For example:
A business analyst who can help the Product Owner express Backlog Items by writing user stories, and helping the Dev Team understand the stories.
A quality analyst who can help the Product Owner with writing good acceptance criteria and then testing stories to make sure they meet the acceptance criteria and definition of done.
A change manager to work with project stakeholders to communicate our progress and organise user training in the features being deployed in the next release.
A project or finance analyst to manage budgets, risks, benefits and resources.
If your Product Owner is going to be assisted by proxy Product Owners, make sure that there is still a single person acting as the chief Product Owner and that person is still responsible for prioritising the Product Backlog.
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 have two Product Owners because you’re deploying Dynamics 365 to two different divisions within an organisation, then you’ve got two different projects. Either split your Scrum Team into two Scrum Teams or deploy Dynamics in one division after the other.
Top Ten Tips for Product Owners
Find a Scrum Master you can trust. The relationship between the Product Owner and 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 Master is employed a Microsoft partner, or your internal IT department. There should be a healthy tension in the relationship. As one of my clients puts it: the relationship between the Product Owner, Scrum Master and Dev Team is like the relationship between someone building a new house, their architect and the builder.
Know your stakeholders. One of the smartest things you can do politically and productively is to get really close to your stakeholders. Especially you users. Get to understand their perspective. Good product owners sit with users and understand their roles today and what they want from their new system. Separate want they want from what they really need and be clear on their needs inside and out. Validate that you are prioritising the backlog based on what the stakeholders really need, rather than your own assumptions.
Realise that you are part of the team. The Scrum Team includes you, the Product Owner. But you do not run the team. It's your job to make the hard decisions and prioritise the team's work, but you are not in control. You're part of the team but you are not in control of the team.
Let the Dev Team design and develop the features. I've seen Product Owners clash with Dev Teams when they try and tell the Developers how to implement a feature. It's your role to provide guidelines regarding the acceptability of custom development, third-party apps, or systems of record. But work with the Dev Team to understand the options and their recommendations.
Don't try to estimate. It's Dev Team's role to estimate the complexity of backlog items. The Product Owner can work with the Dev Team to understand surprisingly high estimates but don't try and force Developers into your estimates. They are the ones performing the work.
Let the Dev Team organise itself. Don't ask Leon to implement this feature or Wanessa to implement that one. Trust the Developers to organise themselves. Work with your Scrum Master if you see any issues, but step back and allow the Dev Team to self-organise.
Minimise meetings. Scrum has planning, review, and retro meetings every sprint and a daily scrum every day. Some Product Owners get carried away with long backlog refinement meetings. I recommend short story time sessions to clarify future backlog items with some of the Developers. Timebox every meeting and stick to it.
Use all the tools you can. As well as the Scrum board, try using burn up or burn down charts, the Definition of Done reminders, story maps and any other tools you can to help the Dev Team or make your life easier.
Be negotiable. Work collaboratively with your Scrum Master 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.
Get certified. There are lots of good resources available for product owners, including books and training courses. If this is your first time as a product owner, consider the Professional Scrum Product Owner certification from Scrum.org to help you learn the basics.
Where do good Product Owners come from?
I've found that the best product owner is a senior stakeholder in your organisation within the division or department that will be using Dynamics 365. This could be a marketing, sales, customer service executive. Maybe even an operations or finance leader.
Unless you are deploying Dynamics 365 as an IT Service Management system, the Product Owner shouldn't be an IT person.
And don't try to mix the Product Owner role with another Scrum Team role such as the Scrum Master or a Developer. The Product Owner's role is to choose which problems to solve, the Development Team's roles is to solve those problems, and the Scrum Master's role is to coach everyone else in the application of the Scrum framework to solving complex problems. Please don't try and be the Product Owner at the same time as any other role.
That's it for Product Owners. Be expert. Be visionary. Be accountable. And be available.