How Does the Product Owner Manage Various Stakeholders?
9K- by Ridhi Chhabra
- 04th Sep, 2020
- Last updated on 07th Sep, 2020
- 8 mins read
As you know, Scrum has the 3 most important roles, which are Product Owner, Scrum Master, and the Team. Apart from these core roles, we have involved stakeholders. It is very important to manage various stakeholders to let the project go in the right direction.
Now, when it comes to the Product Owner, one of the most important roles and responsibilities is to manage stakeholders. Managing their requirements, their areas of interests, areas of conflicts, and a lot more.
This article is going to talk about the Product Owner roles and responsibilities. Furthermore, It gives you insights about who all are the stakeholders, what does it mean to manage the stakeholders, what should be the process, and the further best tips to manage stakeholders. Let’s get started with understanding the basics first.
Stakeholder Management
A stakeholder is anyone interested in the product or we can say who is influenced by the product or involved in the product.
This can be anyone who has a certain type of interest in the project, be it financial interest, someone who has invested, or it can be someone who is going to use the product, which could be customers. We will understand the various types of stakeholders in the coming section of this article.
Now, coming to stakeholder management. Stakeholder Management plays a vital role in project success. It is basically about maintaining good relationships with the stakeholders, or we can say manage them to make them respond positively towards the project. We will understand various ways to implement this in the coming sections of the article.
Let us first understand the roles and responsibilities of a Product Owner before we dive deep into managing stakeholders.
Stakeholders and Product Owner
Product Owner Role and Responsibilities
The product owner is the most important person, who “owns” the product. This person is responsible for the Product Vision.
- A key decision-maker and responsible for the ROI of the business
- Responsible for understanding the end customers and creating the product backlog requirements accordingly
- Responsible for product backlog management (Prioritizing and Managing it)
- Responsible for reviewing and checking the potentially shippable product increment deliverable at the end of the sprint
- Providing feedback to the team at the regular intervals to make sure the product development is moving in the right direction
- Refining the product backlog, based on the feedback and changing market needs
- And not to forget, managing stakeholders!
Now that we understand the Product Owner deeply and it’s responsibilities, let us understand the Stakeholders.
Understanding the Various Stakeholders
![Stakeholder]()
A famous “Chicken” and “Pig” story in Scrum is one of the very good examples that explain how “Chicken” represents the stakeholders who are merely “involved” and “Pig” represents roles like Product Owner, Scrum Master, and the team, which are not only involved but “committed”. Someone who is not part of the team but still has an interest and involvement in product or project development and it’s progress. However, someone who would be affected by the project or product development.
This can include:
- Directors, Decision Makers at the organization
- End Users/End Customers
- Product Sponsors
- Marketing team
- Legal entities
- Etc.
It is very important to take care of these Stakeholders and fulfill all their requirements during and after product development. Now, when we see Stakeholders, this will contain different sets of people and with different roles.
This can include some really good stakeholders who would always encourage the team and provide constructive feedback. However, on the other hand, this can include some challenging stakeholders, who don’t support or provide any feedback.
This is where comes the need for management of stakeholders. However, if we go with the management, it’s like managing people, because stakeholders would include people with different roles.
However, we will look at the larger picture here and see how to manage stakeholders. Let’s have a look at it by putting our feet into the Product Owner’s shoes.
Reviewing Stakeholder Management Process
As we got an idea that Stakeholder could be someone who would either support or someone who would either oppose. The process of managing these stakeholders is Stakeholder Management Process. It involves managing their expectations, communication, requirements, etc.
It involves 4 different steps which will talk about:
1. Identifying the Stakeholders
The very first step that comes in the Stakeholder management process is “Identifying the Stakeholders”. This can be anyone who is involved in the project or is affected by the project. Let us have a look at different aspects for identifying the stakeholders:
- Someone who has an impact on the project
- Someone who has an opinion or a point of view on the project
- Someone who has a decision making power
- Someone who would like to see your project successful
- Someone who would like to see your project fail
- Someone who has an impact over your team
- Someone who can help resolve conflicts or remove challenges
- Someone who simply have an interest in the project
Once, we list down and identify the stakeholders, it is easy for us to categorize them based on different aspects. This whole process is identifying the stakeholders. Once we know them, it is easy for us to manage them.
2. Analyzing the Stakeholders![Analyzing the Stakeholders]()
There are several ways to analyze stakeholders. We will have a look at the two most important ones. The first one is Power-Interest Graph.
Power-Interest Graph ![Power-Interest Graph]()
Power-Interest Graph
High Power, High Interest
These stakeholders are mostly the decision-makers or the key-players. They can impact in a way that can make the project successful or fail. They are very easy to identify. Now, when it comes to communication, they should be actively engaged! These stakeholders are highly powerful, so we must try to meet their each and every requirement, otherwise they can even cancel our project if not satisfied.
High Power, Low Interest
These stakeholders again have decision-making abilities but they are not so much interested. A lot of communication can make them disinterested in the project or product. They lack interest and therefore, they should be kept satisfied!
Do whatever it takes to keep them satisfied.
Low Power, High Interest
These stakeholders are the ones who have less power over the project but they are keenly interested in what’s going on. They might impact the project, so it is important to keep them informed!
Low Power, Low Interest
These stakeholders are the ones who are merely present and don’t expect to be involved much. They might not be interested and might not be expecting any sort of communication. It is important, you just monitor them!
Now that we saw the Power-Interest Graph, another interesting way is the Stakeholder SWOT Analysis. Let us have a look at that one as well.
Stakeholder SWOT Analysis.
Another way is to analyze the stakeholders based on their Strengths, Weaknesses, Opportunities, and Threats. What will be their Strengths and Weaknesses? What will be the opportunities and threats they would bring to the project? This will help analyze them better.
SWOT Analysis
3. Prioritizing the Stakeholders
For a product owner, prioritization is like an ongoing activity. Just like they need to prioritize the backlog, a similar way, they need to prioritize the stakeholders. After the successful identification and analysis, once they are prioritized, they can be taken care of accordingly. This way, product owners can develop the communication plan and can further deliver the right message to the right stakeholder at the right time.
4. Engaging the Stakeholders
This is the last step where execution takes place. Now that we have identified, analyzed, and prioritized the stakeholders, this is where we will implement the communication plan. Determine different action plans, whether are going to have one on one conversations, meetings, or going to communicate through emails. We define and execute our plan accordingly and keep the stakeholders engaged as required. Thus, managing all their expectations.
5 tips for the Product Owners to manage stakeholders effectively
By now, we know how to identify the stakeholders, analyse them, and different steps of the management process. Let's have a look at some of the best practices which Product owners can follow to manage stakeholders effectively:
- Don’t treat Stakeholders same. As we have seen the matrix above on identifying, analyzing and prioritizing the stakeholders. It is very important for the Product Owners to treat them accordingly. Based on our analysis, we categorize them and then based on our categorization, Product Owners need to treat them.
- Act like an Owner. Being a Product Owner is a great responsibility. It is the person responsible for the ROI of the business. With responsibility comes the authority. It is very important you act like an “Owner”. This not only gives you the power over stakeholders but also helps manage them more effectively.
- Communicate Upfront. Never hesitate to say “No” to the stakeholders. Being a product owner, you know what is good for the project and what is bad for the project in order to make it successful. As and when needed, for certain decisions and for the benefit of the project, feel free to say “No” to the stakeholders and be upfront in doing so.
- Set Expectations. It is very important that being a Product Owner, you set all the expectations with the stakeholders. Understanding what they need to know and what they are expecting out of the project. Further, You should be communicating with them in terms of their expectations only.
- Involve Scrum Masters. We know that Product Owner is responsible for managing the stakeholders, but this is not mandatory that Product Owner should do it all alone. Have your Scrum Master besides you to support you with all sorts of process questions, which can eventually help you manage the stakeholders more effectively.
These were some of the best tips to manage stakeholders effectively and efficiently.
To conclude, we discussed several types of stakeholders and we looked at the process of managing them. The major takeaway from this article is understanding the stakeholders. For understanding and managing them, Remember the 4 key points, which are Identifying, Analyzing, Prioritizing and Engaging the stakeholders. For engaging with the stakeholders, which involves the execution, we have provided you with 5 tips for the product owners to manage stakeholders effectively. Stay tuned for more such articles!
Ridhi Chhabra
Ridhi Chhabra is working in the field of Project Management from last 8 years. She is also a Certified Scrum Master (CSM). She has been implementing Scrum Framework in 80% of her projects which are resulting in Successful Project Completion and Great Customer Experience. She has great Communication skills and got a proven experience in interacting with customers around the globe, across US, UK, Australia and South Africa.
She is currently working as an Executive Assistant Project Manager at KOHLEX Design India Pvt. Ltd., It is US Based Organization which is having main headquarters in California, United States and is handling operations in Hyderabad, India.
She enjoys meeting new people, traveling and writing blogs and articles. Refer to her LinkedIn for more articles.
Trending blog posts
Suggested Blogs
CSM or CSPO: Which Certification Fits Your Requirement?
By KnowledgeHut
Agile methodology has been gaining a lot of clout in the IT Industry recently. With so much attention and talks around it all companies big and small are making themselves agile ready to deliver better sooner. Some common Certificate courses on Scrum methodology have also gained popularity because Scrum is the least restrictive of all agile approaches. CSM and CSPO are two such known Certifications that are often thought of as next steps in career progression introspection analysis. While both grant the benefit of knowledge, it is important to analyse what Certification makes more sense and can help better in future growth. CSM Certification: It is for professionals seeking the Certified Scrum Master Certification. Its course work is educative to learn about how Scrum methodology works. Moreover, all the principles and practices around scrum are discussed in detail to lay a sound foundation of its conceptual framework. This certification is beneficial to gain an understanding of Scrum for all present and future scrum projects. Gaining a CSM Certification would benefit individuals who would rather want a Certification that validates their scrum knowledge. Hiring decisions based on Certifications are usually a motivator for professionals pursuing the Certification. This could also lead to challenging opportunities in a space that may interest professionals. Also, professionals seeking to change their present roles can also benefit from this certification to project their interest in this field. Other benefits of CSM could be acceptance in scrum based teams based on scrum knowledge. Also since a lot of organisations tend to portray to their respective client base they own the skills and knowledge to deliver, they also rely on certified professionals to join them so that they may use this as their asset over competitors. Another reason to pursue CSM could also be to expand ones’ knowledge of scrum methodology to be at par with peers. Since existing technical courses do not teach these new methodologies in courseware, pursuing a course about Scrum can help deliver work better if you have recently joined a scrum team or if you plan to join one. So, it is beneficial not only for professionals seeking knowledge as fresher but also for experienced professionals who seek work in scrum space. CSPO Training: CSPO is a common IT Certification acronym for Certified Scrum Product Owner. CSPO Certification is beneficial for professionals who are closer to business. This course is also useful to give an end to end view of the feature that traverses from conceptualisation to deployment or ideation to a minimum viable product. Also, aspects related to understanding stakeholder interests in each functionality are reiterated in this course. Also, because a Product Owner’s role is critical for any organisation they tend to seek candidates who can genuinely guide the team well. While Certification is a way to project, that relevant knowledge is present and make way for a baseline to set that a candidate has genuine interest in the area and that they are focused on continuous growth. A Certified Scrum Product Owner training is also a good to have training to be able to handle the work as a Product Owner better. While a lot of professionals learn on the job, this certification is from the very Scrum Alliance dedicated to set guidelines that can help smoothen the learning curve. A Certification decision is hence usually based on career goals, present career role, and future possible roadmap. Having knowledge is always good and to keep refreshing basics helps revisiting decisions and making teams and individuals in scrum space more effective.
- by KnowledgeHut
- 16 Feb 2017
Agile methodology has been gaining a lot of clout ... Read More
Why Do We Use Fibonacci Series for Estimation
By KnowledgeHut
In this article, my focus is on sharing my experience as a Trainer/Mentor/Coach to Agile teams with respect to Agile estimations; and on using the Fibonacci sequence as scale to size the Story. What will you learn in this article? Agile practitioners mostly use Story points as a measure for estimation, typically using the Fibonacci scale. In this article we are going to understand the top reasons why we use the Fibonacci series for estimation, and how it works in practice. Before we get to the details, let us try to understand some of the fundamentals. Why do we need to estimate?Estimates help the project team to: Identify the time & effort required to arrive at the project schedule Identify the right number of people required to do the work Arrive at the budget by rolling up the cost of all activities required to complete the work; and Prioritize the work in conjunction with the value that will be delivered. Some software developers fear to provide effort estimates as they are accountable to complete their work within the time. Hence, they take so much time to get into the details to make sure they have enough information to provide the estimates. This sometimes may not be possible during the beginning of the project as the team may not have enough information on hand to provide the effort estimates for all the tasks to be performed. Hence the order of magnitude (ROM, Budget or Definitive) will be applied at various stages during the project based on the available information to predict the effort needed to complete the activities. Agile Estimation Typically, in traditional project management, effort estimations may or may not be agreed upon by the entire team. Estimates may either be given by the Project Manager/Tech Lead to the team or the developers/testers may estimate for the piece of work that they have been assigned. This way of estimating a project does not provide an opportunity for the team to collaborate. There may be a difference of opinion with the team members in the effort that need to be spent on an activity. The way the estimations are done within an Agile team is little different. It is just not about the measure used to estimate the effort (for example Story Points), but ensures that the team collaborate among themselves, thus providing an opportunity for knowledge sharing. This helps the accuracy of the estimates when compared to doing individual vs group estimates as the team members come from different backgrounds and roles (developers, testers, quality analysts, business analysts). An Agile team effort estimate focuses on relative sizing of user stories and does not focus on the duration; hence it is faster. The team learns to size the story relatively and accurately over a period of a few iterations (sprints), thus improving the predictability (arrived through establishing consistent velocity over a period of few iterations) as well. Planning Poker is commonly used as the planning exercise for the team to collaborate and size the stories. Planning Poker uses Fibonacci sequence to assign a value to the epic/feature/story. What is Fibonacci Series? According to Oxford dictionary, Fibonacci Series is : “ a series of numbers in which each number ( Fibonacci number ) is the sum of the two preceding numbers. The simplest is the series 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144 etc” The formula to arrive at a Fibonacci sequence is: Xn = Xn-1 + Xn-2 This sequence will be slightly modified when used in Agile estimations: typically, it will not have values beyond 100 and may have 0, ½, 1, 2, 3, 5,8, 13, 20, 40, 100. Some teams limit the highest value as 21 and use 0, 1/2, 1, 2, 3, 5, 8, 13, 21. Top 3 Reasons Why Using the Fibonacci Sequence Will Make You Better at Estimating Tasks 1. Weber–Fechner law: “The Weber–Fechner law refers to two related hypotheses in the field of psychophysics, known as Weber's law and Fechner's law. Both laws relate to human perception, more specifically the relation between the actual change in a physical stimulus and the perceived change. This includes stimuli to all senses: vision, hearing, taste, touch, and smell” Applying the law to Numerical Cognition, “Psychological studies show that it becomes increasingly difficult to discriminate between two numbers as the difference between them decreases. This is called the distance effect. This is important in areas of magnitude estimation, such as dealing with large scales and estimating distances. It may also play a role in explaining why consumers neglect to shop around to save a small percentage on a large purchase, but will shop around to save a large percentage on a small purchase which represents a much smaller absolute dollar amount” (source: https://en.wikipedia.org/wiki/Weber%E2%80%93Fechner_law) The Fibonacci sequence very well corresponds to Weber’s law. The values in the Fibonacci sequence are about 60% higher than the previous value, and hence applying relative sizing is much easier. It is very challenging to distinguish the size of two numbers which are adjacent to each other, by just looking at the objects. Let us take an example of a football and cricket ball. The approximate diameter of a cricket ball would be 2.8 to 2.86 inches whereas the diameter of a football would be 8.66 inches. It is easy to distinguish the relative size of these two (i.e., approximately the diameter of a football is 3 times that of a cricket ball). However, it is very challenging to distinguish between two cricket balls that vary 1 inch in diameter, unless you measure both. If you look at the Fibonacci sequence, the relative size between two adjacent numbers is more than 60% and this helps us to be able to size them accordingly. 2. Reflect Uncertainty The smaller value assigned from the Fibonacci sequence to a user story usually means that the story is well understood, and the user story follows INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) guidelines. Whereas the largest value denotes the story is not well understood or it needs to be broken down further. Smaller stories can be confidently estimated by the team in detail. A general practice from matured Agile teams is that the Fibonacci sequence is restricted up to 21 (0,1,1,2,3,5,8,13,21) and any story which is of size beyond 21 will have to be broken down further. This ensures that the team is not giving any room for greater uncertainty and good practice for the team to write better stories under the INVEST guidelines. 3. Comparison Though it is not mandatory to use Fibonacci sequence for story point estimations, the sequence is easier to understand and adoptable by the team. Individuals are better at comparison than estimation. The easy sequence and distinguishable values of Fibonacci sequence helps to estimate by not measuring the objects but by comparison. How Does Fibonacci Agile Estimation Work in Practice? When do you think is the right time for the Agile team to estimate user stories that are prioritized by the Product Owner in the product backlog? In my experience, I would say that the estimates (story point sizing) should happen during the Iteration/Sprint backlog grooming sessions. This gives the team the time to go through the user stories in detail, collaborate and mutually agree using the Planning Poker exercise. Then what do we do in Sprint Planning? – This ceremony should be used to pick the stories from the product backlog (fulfils Definition of Ready), that can be completed within the iteration/sprint and then breakdown the stories into tasks and do one more level of estimation which is effort estimation denoted in hours. Let us say a team is assigned a task to estimate a reporting module to be developed: The team would agree that it is a difficult task to provide an effort estimation and it would take a longer time to complete; but how long will it take? Using Simple, Medium and Complex categorization would simply mean that the estimate falls into the Complex category; but how complex is it? Breaking down the requirement into granularized tasks, getting to the minute details and then arriving at an effort estimation would be a complex process and time consuming as well. Can the team take linear sequence (1,2,4,8,10,12,14,16….) and size them for a high-level estimation? Is it possible to size between 50 and 52? What can be defined as the highest scale? Using Fibonacci series helps the team to size the stories which have a distinguishable value and as discussed earlier, matured Agile teams use modified Fibonacci series and have highest scale of 21 to size a story. As discussed above, the Fibonacci numbers are 60% above than the previous number, and that helps in relative sizing. Summary There are various methods to estimate user stories, like T-Shirt sizing, Dot voting, Affinity Mapping etc. Story points is the widely used measurement for sizing the user stories. Fibonacci series helps the team to compare between two stories; and its very nature of distinguishable values helps them to fit the story into the right size that reflects uncertainties, which further helps the team to refine the story to remove those uncertainties. Hope this article was useful to you.
- by KnowledgeHut
- 25 Sep 2020
- 9 mins read
In this article, my focus is on sharing my expe... Read More
Top Agile Methods for Better Productivity
By KnowledgeHut
When a Scrum development team works on the productivity of a team using the Agile methodology, the first thing that comes to attention is the metric used to measure how much work the team does in an iteration: velocity. On the contrary, using velocity helps a Scrum development team to determine a team’s average capability on a normal sprint followed by how much they will agree to achieve in the next sprint iteration. The velocity is not preferred to determine the team’s productivity as it is just a simple indicator based on past sprints.The thing that matters at the end is the result and what the team has produced. A team is not recommended to be pushed to fasten its velocity. In the end, the outcome might be unpredictable as the team might economize on acceptance testing, avoid fixing bugs, or minimize restructuring to reach the target velocity. The key to increasing the velocity of the team is to resort to focusing on optimal velocity over time instead of maximized velocity. This also determines the overall quality of the finished product. Here are the top Agile methods involved in Scrum to allow the team to be more productive over time. 1. Eradicating obstaclesOne of the most important duties of a Scrum Master is to get rid of obstacles early and throughout the development process. This begins with asking appropriate questions while User Stories are being written. This gives developers space and time to do their work. While they are working, a Scrum Master also protects the development team from any disturbances from the stakeholders.In situations when the team does get interrupted, it is recommended for the team members to contact the Scrum Master to get their queries and issues resolved. Having a clear and focused mind is the key to operating at the highest level.The most obvious step is to avoid distractions as they are the primary reason for decreasing a team’s productivity. The team is unable to focus when they are asked to clarify why their productivity went down.2. Daily scrum meetings An efficient team always has a small group of professionals, the numbers can go to a maximum of 9. Anything more than that leads to communication issues and more consumption of time in meetings or huddles. A bigger team, in cases, can be split into two or more. A big team leads to more complications and misunderstandings and hence, is not a good idea. A larger team means more loss in information while exchanging thoughts and ideas and that will result in everybody in the team spending more time and effort to get any message or data across. 3. Team Capacity It is a known fact that all the team members must attend the daily scrum every day. The meeting can last for not more than 15 minutes every day to get an overview of the proceedings and the advancement of the undertaken work. All the concerns and ideas put across and need solutions during the meetings can be parked so that all of them can be addressed together. Any topic not related to the purpose of the meeting can be talked about at a fixed but separate time of the day.Furthermore, communicating with each other during the meeting will help in exchanging more information.4. Product backlog The backlog is the key to knowing where a product goes and what needs to be created on priority. So, everything in a project must be kept and properly maintained via a backlog. User Stories should have enough details and can be reordered in case of a change in priority. More accurate User Stories lead to less time consumption for the development team to understand them.An up to date and well-maintained backlog during an Agile project should have enough User Stories for at least one or two sprints.5. Constantly improving mindsetScrum is a continuous method that involves development because the whole method can be changed, not just the software. The point is to find something that requires alterations and to achieve it in the next sprint. This allows the team to tackle one issue at a time and move forward.Finding a clear move in the sprint retrospective to support the team is necessary. Someone must take ownership to act and make things work. This can be achieved by initiating small, easy actions that are less time-consuming first. During a sprint retrospective, it is recommended to take suggestions from each attendee and go for the most appropriate one. After that, a plan will be laid out to realize the chosen idea.6. Interruption bufferWhile running an application in production, it is necessary to keep maintaining and providing new features. However, there can be interruptions, like a bug that needs to be reported urgently or another team needing a developer for assistance. The point is, Sprints will be prone to interruptions, and provisions must be made to deal with these problems. A capable Scrum Master will log all these interruptions noting the number of interruptions, the time consumed in dealing with them and then add them to the next sprint.7. Have a vision of the task at handThe team works more efficiently in getting the deliverables when the Scrum Master already has laid out a blueprint to work on. This also includes having metrics and other relevant charts displayed, doing which will also let stakeholders and colleagues track the production rate.Refreshing the burndown chart daily and displaying the desired sprint result will reflect the customer or team satisfaction. Furthermore, a roadmap showing the working of the product will further enhance the vision of the team. There are multiple ways of sharing information to give everybody the idea of how things are going on while working on the product.To concludeWhen looking at the broader picture of the correct way to motivate a team to get the desired output, a successful team follows a very realistic and simple approach by using plain common sense that is instilled by the Scrum Master. Understanding how the team works and realizing the working style of each team member is one of the most important observations of an adept Scrum Master. It is a collaborative effort that cannot be done by one person but needs responsible efforts from every working member on the task. After all, it is not about ‘Me’ but ‘Us’ that helps in building a product successfully on time.
- by KnowledgeHut
- 28 Apr 2020
- 4 mins read
When a Scrum development team works on the product... Read More
Join the Discussion
Your email address will not be published. Required fields are marked *