Managing "But We Need This" Requests from Stakeholders
When working as a product owner, you are constantly beset by a continuous stream of requests for the urgent, the important, and the marginal.
Think about the ongoing process of agile software development, using Scrum to set the context. You have a roadmap that identifies the important objectives on a coarse scale—maybe quarter by quarter. You have a product backlog that identifies the things that the team intends to do next. These items reflect the best ideas (at that point in time) for how to meet the objectives for the next roadmap objectives.
The team is chugging away, delivering as efficiently as they can, on the most-important stuff to do next. Keep in mind that the product backlog includes enough items to more than fill the current iteration. This is both pretty much inevitable and one of the characteristics that makes agile work, even though it makes it work differently from traditional “fill the bucket with work” planning approaches.
Rich Mironov describes this situation and the commonly flawed expectations of stakeholders in his recent article “Magical Thinking and the Zero-Sum Roadmap.” In the article, he explores how stakeholders ask for “more”—not “different”—to be built for the current release or iteration. It reflects one of the ways that estimation can be misused by an organization, attempting to treat an effectively continuous process as if it were a batch process. Just put more into the batch, please.
The problem is that creating software is more like making Cheetos than it is like making Chevys. The assumption implicit in the request is that the team is currently underperforming—that there is room for more. If that were true, and the stakeholders didn’t ask for more, what would happen?
The team is not secretly intending to be idle in hopes of not being asked to do more. The team is not a group of middle-school children hoping that if they procrastinate, they will have to do fewer chores. Of course the team is balancing delivering the most important items with improving their ability to deliver future items. The net result is that new items, if done now, will delay items that previously were intended for now.
The problem is that stakeholders tend to not appreciate that what they are asking for is possibly less important to do right now than whatever is currently planned for right now. There are, however, some ways to collaborate to improve a stakeholder’s perception of the context in which their request is received.
Impact mapping is an easy-to-consume framework for organizing backlog items in the context of the goals they support and the owners of those goals. Rich mentions the common response to new requests—“I’ll prioritize it against the existing items.” This is fine for one-way communication, but collaborating—helping the stakeholder appreciate his request in the context of all other ideas—can strengthen the relationship and engagement. When the request comes in, put it into the impact map.
Jeff Patton’s recommendation of having a discovery team that includes stakeholders and the product owner, who may lead the team, is a great way to embody collaboration organizationally. Using something like an impact map as an artifact that sustains knowledge and provides context from one conversation to the next will make this more effective.
