# Stakeholder Management in Agile Projects: Many Requests, One Order

Author: Marin Niehues, Niehues Consulting · Published: 2024-04-25 · Delivery & Steering
Source: https://www.niehuesconsulting.de/en/blog/stakeholder-management-agile-projects/

Stakeholder management in agile projects means collecting requests in one intake, scoring them against fixed criteria and turning them into exactly one order that a single person owns. The methods are established: a stakeholder map shows whom to involve and how often, a scoring model such as Weighted Shortest Job First ranks the requests, and a fixed rhythm of reviews and a published order keeps expectations in check.

This article shows how product owners and project leads deal with competing requirements from business units, executives and customers. It contains a worked example for prioritisation, a grid for involvement and a checklist.

**Many requests need exactly one order and exactly one person who decides it. Everyone else gets visibility, a right to be heard and a reason.**

## Why does stakeholder management get difficult in agile projects?

It gets difficult because agile teams accept requirements continuously, which gives every stakeholder the chance to ask for something at any time. In a classic project, requests flow into a requirements phase. In an iterative project the backlog stays open, and every executive and every business unit proposes additions, usually with good reason and a reference to urgency. The team ends up between requests that cannot all be met at once, because its capacity is limited, as the article on [capacity planning in agile teams](/en/blog/capacity-planning-agile-teams/) shows.

The 2020 Scrum Guide resolves the conflict through the role of the product owner: the product owner is accountable for maximising the value of the product and is a single person. The product owner may represent the needs of many stakeholders in the Product Backlog, and anyone who wants to change the backlog has to convince that person. The guide also states that the entire organisation must respect the product owner's decisions. In many mid-sized projects this role exists only on paper, because executives reach directly into the team when they see the need. How the role is shaped is described in the article on the [product owner in mid-sized firms](/en/blog/product-owner-mid-sized-companies/).

## Whom do you need to involve, and how?

You involve stakeholders according to power and interest: those with high power and high interest are managed closely, those with high power and low interest are kept satisfied, those with low power and high interest are kept informed, and those with little of either are monitored. The grid goes back to the stakeholder concept of Aubrey Mendelow, which he presented in 1981 at a conference on information systems, and it remains one of the widespread bases for stakeholder analysis. In teaching, power and interest are the usual axes.

**Involvement by power and interest (grid after Mendelow)**
Group | Power | Interest | Involvement | Example
Manage closely | High | High | Regular exchange, a say in goals and order | Sponsor, head of the affected business unit
Keep satisfied | High | Low | Short alignment at milestones, prepare decisions | Finance, executives outside the project
Keep informed | Low | High | Invitation to reviews, feedback channel | Users, staff of the business unit
Monitor | Low | Low | Short note on major changes | Adjacent areas

A grid is a snapshot. Power and interest change over the course of an undertaking, so the map belongs in every planning rhythm. An example: a business unit with no interest at the start becomes the most important stakeholder as soon as its processes are touched. Anyone who draws the map only once at the start of a project misses this shift.

## How do you prioritise competing requirements fairly?

Prioritising fairly means assessing all requests against the same criteria and making the result public. A widespread method is Weighted Shortest Job First (WSJF): the cost of delay of a request is divided by its size, and the request with the highest result comes first. The method goes back to Donald Reinertsen, who argued in "The Principles of Product Development Flow" (2009) that cost of delay divided by duration is the right measure for sequencing. The breakdown of cost of delay into user and business value, time criticality and risk reduction comes from the widespread form used in the Scaled Agile Framework. An introduction is offered by the article on [cost of delay](/en/blog/cost-of-delay/).

**Worked example: WSJF with four requests**
Request | Value | Time criticality | Risk reduction | Cost of delay | Size | WSJF | Rank
B Report export for controlling | 5 | 8 | 2 | 15 | 3 | 5.0 | 1
D Dashboard for the executive board | 8 | 2 | 2 | 12 | 5 | 2.4 | 2
A Quotation module for sales | 8 | 5 | 3 | 16 | 8 | 2.0 | 3
C Self-service portal for customer service | 13 | 3 | 5 | 21 | 13 | 1.6 | 4

The values in the example are illustrative. They are assigned relatively, usually on a scale of 1, 2, 3, 5, 8 and 13, and assigned together with the stakeholders. The example shows an effect that defuses discussions: the request with the highest value, the portal, lands in last place because it ties up a lot of effort. It stays in the backlog and gets a comprehensible position, and the stakeholder sees what happens if the request is cut smaller. The method provides a basis for discussion. Anyone who applies it mechanically overlooks dependencies between requests and has to re-cut them later.

## How do you say no without losing the stakeholder?

A no holds when it contains a reason based on criteria and a prospect: the request is at position four for these reasons, and moves up if value or size change. The reason follows from the published order, which every participant can inspect. A refusal then becomes information that can be negotiated on the facts.

Three habits help. First, there is a single intake for requests, such as a form or a board, and no shortcut through corridor conversations and e-mails to team members. Second, the order is visible to everyone, with the date of the last change. Third, there is a feedback channel: in the review, stakeholders see what is done and can restate their requests. How a review produces decisions rather than demonstrations is described in the article on the [sprint review](/en/blog/sprint-review-decisions/).

## Checklist: is your stakeholder management robust?

A project's stakeholder management is robust when you can answer the following questions with yes.

1. Is there a stakeholder map that is reviewed in every planning rhythm?
2. Is exactly one person responsible for the order of the backlog, with the backing of the executive team?
3. Is there a single intake for requests?
4. Are all requests assessed against the same criteria, and can the assessment be inspected?
5. Is it settled who decides when two departments claim the same place in the order?
6. Do stakeholders know the date of the next review, and do the decision-makers attend?
7. Does every rejected or postponed request receive a reason and a prospect?
8. Does a metric show how much work is pushed past the team outside the order?

**Typical mistakes in stakeholder management**
- The loudest voice determines the order, and quiet departments with high value wait.
- The product owner represents everyone's wishes without being allowed to decide, and the team receives contradictory orders.
- Stakeholders are consulted once at the start and are not seen again until the end.
- Dates are promised before capacity and order are settled.:::

## Stakeholder management with Niehues Consulting

[Niehues Consulting](/en/) is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues works as delivery manager, project manager and product owner in projects ranging from VC-funded scale-ups to DAX 40 corporations, in more than 20 countries on six continents. Clarifying decision paths and interfaces between the business units, the executive team and the delivery team is part of the work in the service area of delivery management and organisation design.

The approach follows the Niehues Delivery Model. Three review questions matter for stakeholder management: who decides, who delivers, who uses? Which roles and decision paths does operations need, and which interfaces? Who owns operations from day one? The scope and terms of an engagement are discussed in the free initial consultation, which you can arrange through the [contact form](/en/#kontakt).

**Conclusion**
Many requests become manageable when one intake, scoring against fixed criteria and one person for the order come together. The stakeholder map steers involvement, WSJF supplies the basis for discussion, and an open review keeps expectations current. A no with a reason and a prospect preserves the relationship.

**Sources**
- Schwaber, Sutherland: The Scrum Guide, 2020
- Mendelow: Environmental Scanning, the Impact of the Stakeholder Concept, Proceedings of the Second International Conference on Information Systems, 1981
- Reinertsen: The Principles of Product Development Flow, book, 2009

## Frequently asked questions

### What is stakeholder management in an agile project?

Stakeholder management in an agile project is the steering of involvement for everyone who is affected by the product or can influence it. It includes analysing the stakeholders, one intake for requests, an open assessment and regular reviews. One person decides the order, in Scrum the product owner.

### Who decides when requirements compete?

The product owner decides, with the backing of the executive team. Stakeholders contribute requests and arguments, and the decision follows the published criteria. In a dispute between departments, the authority designated beforehand decides.

### What is WSJF?

Weighted Shortest Job First is a prioritisation method that divides the cost of delay of a request by its size. The highest result goes first. In the widespread form, cost of delay is made up of value, time criticality and risk reduction.

### How often should you engage stakeholders?

Frequency follows the power and interest grid: stakeholders managed closely are met at least once per cycle, those to be kept satisfied before milestones. Inform everyone else through the review. Check the allocation in every planning rhythm.

### How do you deal with stakeholders who demand deadlines?

Give a date as a range with a probability and the scope it refers to. Show the order and the capacity it follows from. If the stakeholder needs an earlier date, they help decide which requests are postponed to get it.

### What should you do when executives give orders past the product owner?

Bring the order into the intake and assess it against the same criteria. Show the executives what the inserted work pushes out of the order. Anyone who takes executive influence seriously involves the executives in the review.

### How many stakeholders can one product owner manage?

The number follows the intensity of involvement, and the product owner's time sets the limit. The product owner looks after the "manage closely" group from the grid in person and reaches everyone else through the review and through representatives who bundle groups.

### How do you document prioritisation decisions?

Record every decision with date and criteria as well as the reason, in the order that everyone can see. When something changes, note what changed. That makes it possible to understand later why a request stood further forward or back.