Practical .NET

Agile Development: How to Pick the Most Valuable User Stories

Some of the critical problems for any team working in an Agile way are managing the backlog of user stories, converting epics into stories, preventing scope creep, and -- most importantly -- picking the most valuable stories for the next sprint. Impact mapping provides a visual solution for all these issues.

• By Peter Vogel
• 08/23/2019

One of the most time-consuming problems faced by the teams I work on is just managing the list of potential changes. In software maintenance we used to call this "the backlog" and we knew we'd never get to the end of it. If we're not careful, just managing that backlog can become a significant task, taking time away from delivering functionality.

Right off the bat, applications worth doing tend to have lots of requests. The standard process in the Agile world for handling requests only makes this worse.

In the Agile world, user stories ("As an employee I want to be able to review my hours worked so that I can know when I'm earning overtime"), are the standard way to record the initial state of those requests. Good user stories are "small" (so that they can be implemented in a single sprint) and "valuable" (delivers something that matters). To get to "small" it's often necessary to break a story down into multiple stories (an "epic").

As I said, stories also tend to be "many." Splitting stories into epics just makes the "many" problem worse while creating the new problem of making sure that all of the stories that make up an epic maintain their relationship to one another.

Which all leads to the most challenging problem: making sure that you're picking the most valuable story/requirement/request to work on next out of this huge backlog. It's also the task that's the most important to the organization's (and your) success and it can be ... fractious. Plus, I often suspect that some of the requirements/user stories that make it into a sprint are an example of scope creep rather than a case of maximizing value for the organization.

On the various teams I've worked on, I've seen several solutions applied to address these problems. It's only recently, though, that I've been part of a comprehensive solution that addresses all of them: impact mapping.

Creating an Epic Hierarchy
Impact maps create a hierarchy that leverages the standard user story template of "<role>, <need/goal>, <reason>" to reduce the apparent size of the backlog. In an impact map, the highest level of organization is a goal that matters to the business and is too big to accomplish by implementing a single story. "Improving customer loyalty" would be a good example of a goal. A good goal has a measure associated with it so that the organization can tell if the goal has been achieved.

A goal that's big enough to be worthwhile will usually have multiple actors involved -- these correspond to the roles of the standard user story template. In a retail environment, improving customer loyalty would involve not only the customer but also the parts of the company that the customer interacts with (shipping, ordering, marketing). This is the second level of the hierarchy: the actors involved in achieving the goal.

For any actor, there are probably multiple "impacts" that need to be achieved. For example, if we want to improve customer loyalty, then we want customers to be more satisfied with us, to order more frequently from us and to buy more stuff when they do order from us.

These impacts form the third level of an impact map and correspond to both the needs and reasons portions of the standard user template. This means that an impact isn't a deliverable: "Improving shipping" isn't an impact; instead "improving shipping" is a deliverable that might contribute to achieving that "improved customer satisfaction" impact. A good impact also has a measure associated with it that allows the organization to tell when it's been achieved.

The fourth (and final) level is where our stories (and, eventually, our deliverables) live.

Improving Story Management
This process has multiple impacts on story management. When it comes to splitting stories, for example, the hierarchy provides a way of thinking about how a story can be broken up: by goal, by actor and by impact. A story could be attached to multiple impacts if it contributes to, for example, several goals.

This mapping also changes the process for picking stories for the next sprint. With an impact map in place, the obvious place to begin is with the organization's current, critical goal. Impact planning pulls all the stories for any goal together so that the team focuses on what currently is most important to the organization. Story management is simplified because, essentially, the team now focuses on managing goals and only has to pay attention to those stories associated with the critical goals.

Impact planning also allows stories to be reprioritized as times change. If an impact has been achieved, then unimplemented stories associated with the impact can be ignored (at least for now). As the organization's goals shift or are eliminated, stories associated move with the goals. Again, instead of managing stories, the team is managing goals.

Impact planning also helps manage the number of stories. For example, stories that can't be assigned to an impact on an actor that achieves a goal just disappear, reducing scope creep.

On top of all that, it's easy to make the hierarchy visual. When the hierarchy is drawn from the goal down to the story then, given any goal, it's easy to see what the relevant stories are.

One of the reasons that I find this approach appealing is that it reflects the way most of the teams I'm part of work. In practice, not all stories are equal and the stories that are "more equal than others" are the ones that are most closely associated with the organization's current goals. Within those goals, it's the roles and the benefit that often make one story more valuable to implement than another.

Credit Where Credit Is Due
If you're interested in more about this, there's a site devoted to it. If you want more comprehensive coverage, there's the book "Impact Planning: Making a Big Impact with Software Products and Projects." For more succinct coverage there's a good section on impact planning in "Fifty Quick Ideas To Improve Your User Stories" (which, despite its title, has a lot of worthwhile things to say about user stories though I think that it does focus a little too much on software for startups).

After all, isn't that what you want to do: Make an impact?