Message sent!

Someone from our support team will contact you shortly.

Get a Quote

Your email *

Tell us why you're considering making a switch:

Schedule a demo

Your name *

Your email *

Number of team members *

Industry

Tell us why you're considering making a switch:

Blog

Stakeholder Management in Scrum

31 Jan 2020

We are all well aware of the importance of building a working product that will drive both business and customer value. To create such a product, we must have stakeholder input at all times. This is why we need to get as much feedback and other information from the various stakeholders. 

But how to effectively manage stakeholders in Scrum? 

In short, that's the responsibility of the Product Owner. The long version is in the rest of this article. 

What is or who is a stakeholder?

Before we proceed, we must first define who the stakeholders in the project are. A simple definition would be; anyone who has any stake in the project or will be impacted by the product in one way or another. 

However, that would include a lot of people and no PO on this earth is able to manage that many people at once, while communicating their needs to the development team. 

Therefore, you need to prioritize stakeholders. The main reason is that not all stakeholders are equally important. That's just the way it is. Here are a few examples of who the stakeholders may be.

  • Users or customers.
  • Clients.
  • Managers.
  • Organizational leaders.
  • Suppliers.
  • Sponsors.
  • Third parties and vendors.
  • Other teams.

The list can go on and on. So, who is actually important in your organization? Your responsibility as a PO is to find a way to maximize the value of the product. That includes business value and value for the customers/end users. 

It can be a tricky balancing act and it will depend on a number of factors, but in most general, your users will be among the most important stakeholders whose input you will be looking for as often as possible.

 If the need arises, you can always prioritize stakeholders by their involvement in the project, as well as based on their influence. 

You can start by saying "No"

It's important to remember that you're not supposed to please every stakeholder. As much as you're responsible for communicating stakeholder needs to the development team. On the other hand, you're also as equally responsible for communicating what's possible and what's not to the stakeholders. 

That means you'll have to start saying "no" to people around you. POs may be torn between the involved parties but they're still responsible for the product being made and its value. 

Therefore, it's up to you to decide how to proceed and it's also up to you to ensure that everyone understands what needs to be built, what can be built and what should be built. 

After all, in most cases, stakeholders are not always as tech-savvy as you'd want them to be so you must rely on your soft skills to explain to them what's within reach and what's impossible to achieve. 

Treat customers as a stakeholder

In any scenario, the customer, as far as Agile goes, is the most important stakeholder. They're the ones you're building a product for. A lot of POs are afraid of portraying what's been built so far to the customers because they would like to avoid any negative reviews and potentially bad publicity. 

However, even negative feedback is still feedback. You can't make improvements to the product unless you know something didn't go as planned. Consumers love to be involved and they want to be involved so don't hesitate to collaborate with them.

Any input is valuable for future features, improvements and functionality aspects of the product. It's safe to say that customers if you prefer, are the best source of feedback aside from other relevant stakeholders. 

Avoid individual management

Aside from managing the less important stakeholders, a lot of POs tend to manage stakeholders individually. This is a monumental waste of both time and resources. What's more, you're not being very productive. 

Instead of focusing on individuals, try managing stakeholders in groups. A good example of this is inviting a group of stakeholders for a product demo after each successfully completed sprint. During Sprint reviews, more stakeholders can familiarize themselves with a working piece of the products. 

Furthermore, they can collaborate with the rest of the team on what to do next and how to proceed. Instead of gaining individual input, you can save time and energy by involving an entire group of people in the project. 

Understand your stakeholders

As a PO, you'll be spending a lot of time communicating with a lot of people from both outside and inside of your organization. You can take this time to get to know your stakeholders better and make an effort to truly understand them. 

This will allow you to make more informed and more strategic decisions when it comes to product development. A lot of POs involve stakeholders in various aspects of product development. They will ask for permission to develop a feature, reduce costs, spend more time on bug fixing and so on. This is all well and fine but it can be overwhelming at times. 

Just imagine consulting with stakeholders every time there's a decision to be made. if you understand your stakeholders well, you can make the decision knowing that you have their best interest in mind and that they will agree with your decision when it's time to inform them.

Own the product

The role of a PO doesn't mean you are the owner of the product and that it's being made for you. However, that also doesn't mean you cannot own the product you're responsible for. As mentioned before, you're responsible for the product's value and it's up to you that everyone is satisfied with the end result. 

Therefore, create your own plan for how this should happen and don't become a part of someone else's plan. After all, you are a Product Owner, not a Product Proxy. 

You must show that you can ensure that the product will be a success without becoming a scribe in the process. If you have difficulties maintaining your mandate you can always ask the Scrum Master or an Agile Coach for advice.  

Closing word

Working with people can oftentimes be more challenging than developing software. That's why POs have the necessary soft and hard skills to match their role. Managing stakeholders isn't easy, to say the least. However, if you have the value of the product in mind it becomes much easier to manage the people involved.