Stakeholder Management in Agile Projects: Many Requests, One Order

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.

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 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.

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.

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.

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.

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?