When Prioritizing Stories, Don’t Forget the Stakeholders

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.

However, there are two potential downsides here. First, if story x has a value of a hundred thousand dollars put on it and story y has a statement, not a value, then story x will probably get prioritized, even though it might not have the highest value. People tend to put more trust in numbers.

Second, those who don’t agree with the valuation or who wish to fight for another story may endlessly ask for details of calculations and find fault. It’s hard to argue against “making the numbers more accurate,” but to do so can represent a diversion of time and energy, and it can be a distraction from actually getting on and doing the work.

Evaluation: Closing the Loop

However you go about evaluating your stories—by financial analyst, stakeholder analyst, or something else—there is one more step that is often lacking: Evaluation.

This should probably fall to the business analysts or product manager. After development and deployment, a story (or anything else) needs to be reviewed again to see if it delivered the expected result. Is the new functionality even used? Does it deliver the anticipated benefit?

If the benefit is not delivered, then why not? Maybe the benefit was wrongly identified or valued in the beginning, in which case development should never have worked on the story. Or maybe the work was insufficient, and the story just needs more work to realize the anticipated benefit.

Evaluating also allows teams to calibrate and adjust the current and new work to incorporate the findings from past work. It’s just another feedback loop, but it’s an important one, particularly in corporate IT settings.

If you follow this cycle of consulting those who will be affected by a story, ascertaining what benefits will be gained, and then revisiting stories to evaluate whether the predicted benefit was realized, you can streamline your story prioritization process and, ultimately, develop more stories that really matter.