Back to all blogposts

A Project Manager’s guide to stakeholder management in Agile

Mikołaj Kukurba

Mikołaj Kukurba

QA Engineer/Business Analyst

If you’ve ever been involved in any project (not only IT-related) – most probably you’ve heard about “stakeholders”. They are the most important source of requirements. Thanks to understanding who is a stakeholder in Agile – you can properly prepare the application’s project that your client needs. The success of the project depends on how well you communicate and cooperate with all the people, groups or institutions who have an interest in the final product. The article below will focus on the role of stakeholder management in Agile and their influence on developing software solutions.

Who is a stakeholder?

According to “Mastering Business Analysis Standard Practices”:

A stakeholder is a group or individual with a relationship to the change, the need, or the solution. A stakeholder is any person, group, or organization that may impact, be impacted by, or perceive itself to be impacted by a project, program, initiative, operation, or portfolio

Um, okay… But what does it mean in practice? In order to answer that question, we need to talk about the role stakeholders have in the software development process. They can make the project’s requirements a little bit messy. The reason is simple – people have different opinions on certain aspects of the project (often contradictory with each other) and not everyone will have the same positive attitude towards every idea and solution.

Before stepping into the project, it’s necessary to know who actually is a stakeholder. Is it a user? The development team? Product Owner?

Stakeholders are all the people who have a personal interest in a project. It includes investors, creditors, employees, and suppliers. The interest may come for a variety of reasons. It may be a direct relationship for example – such as employment, ownership, or investment.

Also, it’s important not to mistake a stakeholder for a shareholder. Citing Investopedia

Shareholders are always stakeholders in a corporation, but stakeholders are not always shareholders. A shareholder owns part of a public company through shares of stock, while a stakeholder has an interest in the performance of a company for reasons other than stock performance or appreciation.

How do I know who is a stakeholder in Agile?

In an ideal situation, your client should provide you with a list of all the people engaged in a project. Moreover, if you work in Agile – the Product Owner should know everything about them.

Unfortunately, the reality is not that perfect. That’s why before you start planning anything, you should carry out the analysis of Agile stakeholders with the client and the Product Owner.

It’s a good practice, to write down all the people or groups who will be affected by your software. Remember that the biggest risk when analyzing stakeholders is… to forget about someone. How to avoid that? Let’s use the onion analogy. 

Don't neglect business analysis in software development. Why?

Peeling the onion a.k.a. stakeholders’ analysis

Some people may compare stakeholders’ analysis with… onion layers. And it’s not only because both can make you cry. First and foremost – the analysis of stakeholders may be really crucial for the project.

A meme with Shrek and Donkey – stakeholder management in Agile has layers as onions have layers

One of the most common mistakes is to miss someone. Just imagine what can happen when something like this happens. At the beginning of my adventure with analysis, I experienced something similar. Accidentally, I forgot about the most important group – developers… 

They quickly reminded me that they also wanted to have an impact on the project. Not only in terms of the technical requirements but also in possible solutions – due to their professional experience. It turned out that their solutions were actually easier to implement.

Another example is about focusing only on the decision-making people, forgetting about the real users. One of the recent workshops made me realize that the management’s vision of the need for a solution may be different from how users actually use the system. 

You can have a system that no one uses because it doesn’t address the needs of end-users. A great example is Nokia and some of its phones, e.g. the models 3300, N-Gage, and 7600 which initiated lots of memes.

In the documentary film “Nokia: We Were Connecting People” there is a story of the 3300 model which had buttons… that didn’t work. Why? Because the backend lacked those functionalities. Why? Because they weren’t properly discussed with all the stakeholders. Simple as that. No to mention that the shape of this phone, in my opinion, was not really user-friendly.

Now you know that any mistake at this point may cause some big changes in the architecture in the later stages of the project – and worst-case scenario – it may destroy the whole project. That’s why it’s important to invest some time and energy to study:

  • client’s business,
  • project’s goal,
  • organizational structure,
  • existing processes, reports, data,
  • internal or external media such as blogs, online chat forums, newsletters, and social media.

During analysis, most probably you’ll have a chance to talk to some stakeholders. There will be some brainstorming, workshops, and so on. It’s necessary to remember that the process of analyzing stakeholders starts with the project kick-off and it lasts until the whole project ends. That’s why you should update the list of stakeholders regularly.  

Once you wrote down the list, you should discuss and agree on channels of communication. Also, it’s good to set the groups of people who will be involved in a project and their roles. Remember though,  that not everyone will be involved in a project in the same way. That’s why you can use the aforementioned onion analogy to set priorities. 

It’s one of the techniques which can help you determine who is the most important. You can use “onion layers” to divide stakeholders from the closest to your project (layer 1) to the farthest ones (layer 5).

Layer 1

Solution: the product, service, or result being created;

Layer 2

Solution delivery: the solution domain stakeholders, PM and/or Scrum Master, BA and/or Product Owner;

Layer 3

Domain: the stakeholders in the area of the business being affected;

Layer 4

Business, organization, or enterprise: the stakeholders who interact with the affected domain stakeholders;

Layer 5

External: the stakeholders who are outside the business, organization, or enterprise.

There are, obviously, different methods for group stakeholders. If you read through some specialist literature, you’ll find the division to external/internal or active/passive. However, the “onion diagram” is the one I find the most accurate. 

How to properly prioritize the requirements?

So, once you determined all the groups of stakeholders, now it’s time to establish whose requirements will be the most important ones. How to prioritize those? According to the “I pay – I demand” rule, the investor of your solution might have the most to say in this matter.

Nonetheless, it’s good to try and break through this barrier to reach the real user. I know from my personal experience that sometimes the vision of management is extremely different in comparison to the user’s needs. The end-users who are the target group are able to report different issues and needs than sponsors and other superiors. That’s why it’s so important to reach the target group. Finding people who have a positive approach towards your solution and who can help you encourage others – ideally through mentoring.

To do it, you can use a technique that is used in marketing and divide your stakeholders into four groups.

  • Opposer: a stakeholder who is resistant to the change and isn’t concerned with implementing the change. An opposer has important requirements associated with the potential risk that you will need to elicit.
  • Conductor: a stakeholder who provides advice and direction regarding the requirements for the change. A conductor also has important requirements associated with potential issues and risks.
  • Advocate: a stakeholder who is an active promoter of specific requirements associated with the change. An advocate often has technical advice and specific knowledge that will help you throughout the change life cycle.
  • Change Agent: a stakeholder who is completely integrated into the change. A change agent is ultimately responsible for ensuring that the delivery of the change activities results in success.

The diagram below shows it more clearly.

Stakeholder matrix example

It’s one of the methods of using the so-called stakeholders’ map or stakeholders’ matrix. The map presented above shows the engagement of your stakeholders in your solution. It doesn’t answer the question: “whose requirement is more important” though. To answer it, you can use another stakeholders map. 

The power/influence matrix compares the stakeholder’s level of authority with the stakeholder’s amount of active involvement.

Another example of Agile stakeholder matrix

In the top right corner, you place the most engaged stakeholder, who has the biggest influence on your project (for example sponsor). Once you group stakeholders and you know which requirements have the top priority – it’s time for a more difficult phase – stakeholders management.  

As I mentioned above, the biggest risk during the analysis is to skip any groups which are important for the project. Another risk is about managing them. You can use yet another map to make it easier. 

The power/interest matrix compares the stakeholder’s level of authority with the stakeholder’s level of concern.

One more image with stakeholder analysis matrix

In the bottom left corner, you place people who should be contacted from time to time to check if they engaged in the project more than in the previous phases. On the opposite side, there are people who manage the project closely and who present requirements.

Thanks to the map above, you can take care of the stakeholders’ satisfaction. Also, you can build trust in your work. Citing one of the texts from below bibliography: 

When trust is low, the speed slows down and costs go up. Conversely, when trust is high, the speed accelerates, and costs go down.


Summing up, Agile stakeholder analysis is not easy but with the proper background is doable. Theoretically, it might seem like the Product Owner’s job, however, it’s good for you to go through this analysis on your own to make sure you understand stakeholders and the requirements’ priority. It’s important to remember not to omit anyone. Once you have the list of stakeholders, it’s important to define their engagement and set priorities. It can significantly improve stakeholder management in Agile. Also, you should agree on certain communication channels to build trust and improve cooperation. The last step is to create the list of persons for the chosen groups from the map. But this is the topic for a completely different story. 


Mastering Business Analysis Standard Practices; Kelley Bruns, Billie Johnson

Hanna Wesołowska, 

Dawid Lewandowicz

CTO vs Status Quo

Find the exact rules Tech Managers used to organize IT & deliver solutions the Board praised.

Read here

The Software House is promoting EU projects and driving innovation with the support of EU funds

What would you like to do?

    Your personal data will be processed in order to handle your question, and their administrator will be The Software House sp. z o.o. with its registered office in Gliwice. Other information regarding the processing of personal data, including information on your rights, can be found in our Privacy Policy.

    This site is protected by reCAPTCHA and the Google
    Privacy Policy and Terms of Service apply.

    We regard the TSH team as co-founders in our business. The entire team from The Software House has invested an incredible amount of time to truly understand our business, our users and their needs.

    Eyass Shakrah

    Co-Founder of Pet Media Group


    Thank you for your inquiry!

    We'll be back to you shortly to discuss your needs in more detail.