Harvesting Stakeholder Perspectives to Organize Your Backlog

Every agile or Scrum team knows the dilemma of organizing the backlog of project requirements. It’s like cleaning out the garage. You know you’ll have to handle everything sooner or later, but where do you start? How do you organize the work to get the most out of it? 

It’s easiest to follow the squeaky wheel methodology—fulfill the desires of whoever is complaining loudest this week—but that’s not the path to delivering the highest value for your customer. The key to organizing the stories in your backlog is to explore their value from a number of perspectives.

This lesson was the goal of a game Mary co-created earlier this year at the New England Agile Bazaar’s Deep Agile Games weekend event. The game is called “The Backlog Is in the Eye of the Beholder.” Recently, at the Boston chapter of the International Institute of Business Analysis (IIBA), we facilitated this game for a group of more than sixty people.  The gamers learned a lot, and we learned even more.

Sowing the Seeds
The game consists of four rounds, each focused on a different persona related to a farm: the producer/farmer, the customer/buyer, the land owner, and the Farm Bureau inspector. In small teams, the participants analyze a group of tasks (e.g., fertilize crops, spray insecticide, rotate crops, and assure organic). The players organize the tasks according to the perspective of that round’s persona.

This game has two purposes. The obvious one is to explore the views of multiple stakeholders and organize the tasks according to who wants what. The less-obvious (but related) one is to illuminate the value of organizing the work without prioritizing. If that concept leaves you puzzled, read on. As we said, IIBA participants weren’t the only ones who learned valuable lessons.

What the Gamers Gleaned
The game worked quickly to meet our first purpose. Exploring different stakeholders’ perspectives (in this case, using personas) indeed allowed for progressively deeper understanding of the product needs.

 In one example of that deeper understanding, the players realized that a number of stakeholder needs were shared among personas, whereas other needs did not overlap at all—a key discovery in organizing a backlog. How do you apply the lesson? You use a gradient of “don’t care” to “really care” for each persona for each product need—a practice that quickly illuminates shared value versus conflicting value. Many of the gamers were surprised to find that understanding the “don’t care” perspective was just as important as comprehending the “really care.”

When it comes to understanding product needs, the players learned a needed lesson in setting priorities (the second purpose of the game)—namely that it’s important to resist the urge to prioritize requirements too soon. Instead, you should learn more about the stakeholders and their needs before making delivery decisions. You can organize the backlog in different ways, and each has benefits and drawbacks that you need to identify and analyze. When you delay prioritizing, it lets you “walk around” the product needs, looking at them from different perspectives.

It also helps you remain open to discovering dependencies among the requirements. Interestingly, we overheard only one of the fourteen teams discuss this topic during each game round. But, we know that requirements interdependencies are a virtual certainty in most projects, and the longer they go unrecognized, the more headaches you’ll have.

Speaking of remaining open, the gamers also learned that the persona you analyze first can mislead you, prematurely narrowing your thinking about the requirements. You can also cramp your process by reducing the number of personas you invite to the party. As facilitators, we noticed that the participants stuck only with the personas we provided, although during the retrospective several people spoke about other roles or personas.

When team members are open to discovery, the very act of collaborating to organize the backlog—discussing, sorting, and evaluating various stakeholders’ needs—helps build the project community.

What We Reaped
After the event, we conducted our facilitators’ retrospective and learned some key lessons.

First, when you’re exploring product needs, evaluate time as a factor. For each backlog item, factor how time:

• Erodes (or increases) the value of the delivered requirement
• Increases (or reduces) the cost to deliver
• Alters implementation options (because of emerging technologies)
• Heightens the need to retire older technologies

Second, always take into account how the backlog is affected by regulations and policies.There is a cost for noncompliance, such as fines and negative market perception. Consider the probability that changes in regulations will devalue the implementation of a given set of requirements.  And, if your business has volatile business rules, consider the value of separating rules from requirements to enable business capability and agility.  

A Welcome Windfall
Moments before the groups debriefed their last round of play, we realized there was another learning opportunity: cross-persona theme analysis.

Here’s a bit of background. During each of the four persona rounds, the players had used uniquely colored index cards to label themes (or categories) of the backlog items for each persona. For example, the farmer’s category cards were blue, the land owner’s category cards were yellow, and so on. 

At the end of the four rounds, we noticed the colored cards strewn on the tables, and we wondered what would happen if we asked the teams to cluster the entire set and order them according to importance. We decided to take a chance and go for it.

The activity was fascinating to watch. Most teams ordered categories by persona; they clustered all the yellow cards together, all the blue cards, and so on. Only a few ordered them across personas. Perhaps, if we had had more time, it would have allowed them to explore this further.

This exercise taught us two things:

• Build in time to understand the “big-view” across all perspectives—a critical dimension when teams are planning product delivery.
• Adapting a game on the fly is exciting and may yield interesting findings—but it may also introduce risks. When you haven’t prepared, your instructions to the players may not be clear. Ours weren’t. Had our instructions been clearer, the players would have better understood the objective. Planning also would have allowed us to factor in sufficient time for the work.

High Yield
The Backlog Is in the Eye of the Beholder learning game aligns with our real-world experiences in facilitating and coaching teams. Eliciting, analyzing, and prioritizing needs—prerequisites for planning releases to deliver value—rely on a rich understanding of all stakeholders. You must learn about your stakeholders—their goals, motivations, preferences, and unique definitions of value—before you can organize your backlog for greatest value. And, because you often serve multiple stakeholders, it’s crucial to learn how their needs both intersect and depart.

We’re grateful to everyone who helped us arrange the game in Boston—in particular, Helen Strickland, who made sure the room was set up for the game, and Norm Sybert, who took the wonderful photos! Also, thanks to our newest EBG-er, Sue Burk, for helping us during the game rounds.

Resources

• In “Playing at Work: Games that Deliver Value,” Mary Gorman describes how games for learning and games for working unleash creativity and help you accomplish business goals.
• “Agile Requirements by Collaboration: Making Smart Choices about What and When to Build” (InformIT, August 2009) by Ellen Gottesdiener
• Personas:
  • "The Inmates are Running the Asylum" by Alan Cooper, the originator of personas.
  • “Perfecting Personas” by Kim Goodwin (of Cooper Design)
  • “Pragmatic Personas” by Jeff Patton StickyMinds (January, 2010)