When Prioritizing Stories, Don’t Forget the Stakeholders

[article]
Summary:

Instead of choosing what to develop based solely on a cold, hard dollar amount, you might try approaching the person who originally requested a story—or who will be most affected by it—and asking, “What benefit will this bring you?” Armed with a list of stakeholders and interests, you can find out the real difference a story will make.

Bill was a software development manager at a logistics company. One of his responsibilities was to decide what his team would develop next. There was no shortage of ideas; people would regularly come to him with requests to change or enhance one system or another. Usually, though, it was the account managers who got what they wanted, because they could link their requests back to customer revenue.

Bill had a varied bunch of stakeholders who all had an interest in the company systems, what his team was working on, and how his work would affect them, both directly and indirectly. Bill’s answer was to step back and let his stakeholders prioritize the work.

Every two weeks Bill convened a meeting of the people who sent him requests. He put all the requests on the table and stepped back. The stakeholders would discuss the work requests among themselves and put them in priority order. At the end, Bill would get the result and set about delivery.

How they arrived at this priority is less important than the fact that they did. Those who could pin revenue to a story still stood a better chance of getting their request done, but those who couldn’t put a financial figure on their story got a chance to argue their case, too.

Seeking Out the Real Benefit

Instead of choosing what to develop based solely on a cold, hard dollar amount, you might try approaching the person who originally requested the story and asking, “What benefit will this bring you?” or “What will x allow you to achieve that you can’t at the moment?” An experienced business analyst may well be able to turn an answer like “This will allow us to reduce the time we spend answering customer calls” into a financial value.

You needn’t have all stakeholders in the same room; you might not even want them to fight it out among themselves. But this way you can still get an understanding of the potential benefit of each proposed story.

You may also try talking to people other than those who originally requested the story; the potential new functionality could benefit different groups. Conversely, some stakeholders may actively not want changes made.

My friend Benjamin tells a story of receiving a stream for feature requests for his team. He made a point of tracking the requests back to the people who would receive the benefit, rather than the people who suggested the story. When he did so, he found the actual benefits could be negligible.

Stakeholder analysis—understanding who has an interest in a system under development, and what that interest is—is an old business analysis technique. Many tools and practices traditionally deployed by business analysts are still valid in today’s agile world; analysts just need to accelerate the techniques for use in conjunction with development—days, not months, in advance.

Armed with a list of stakeholders and interests, you can find out the real difference a story will make. Having a statement that speaks to the business benefit can substitute for a financial valuation and is often a lot easier to obtain.

User Comments

1 comment
Leyton Collins's picture

Kudos for highlighting an all too common happenstance where something is produced because it's perceived to be 'cool' or whatever rather than something users (customers) will actually benefit from. 

December 12, 2015 - 10:07am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.