6. Experiments
Are we all just Dark Age doctors, swearing by our leeches?
We crave a greater science. We want to be proven wrong . . .”
—Isaac Marion, Warm Bodies
In This Chapter
• Explore ten experiments to learn the needs of your stakeholders.
• Learn what impact the experiments have on surviving Zombie Scrum.
• Discover how to perform each experiment and what to look for.
This chapter presents experiments to help Scrum Teams build what their stakeholders need. Some are designed specifically to better understand the needs of your stakeholders, while others are more focused on distinguishing what is valuable and what isn’t. While the experiments vary in their difficulty, each one will make the subsequent step easier.
Experiments: Getting to Know Your Stakeholders
How can you help Scrum Teams develop a better understanding of what it is their stakeholders are looking for? The next section contains three simple experiments you can try to make that possible.
Start a Stakeholder Treasure Hunt
Before any interaction with stakeholders can take place, Scrum Teams need to find out who these stakeholders actually are. This experiment helps Zombie Scrum Teams identify the people who care about their product by clarifying the product’s purpose. This is the first step towards interacting with those stakeholders.
Effort/Impact Ratio
Steps
Gather your team and ask the following questions to understand the purpose of your product:
• “What is the product we are building? Why does it need to exist?”
• “What would be missing if we stopped building this product?”
• “How do we justify using our precious time, money, and mental energy?”
There are many ways to engage participants in this conversation. For this particular experiment, and for many others in this book, we recommend using one or more Liberating Structures.1 For example, you can use “1-2-4-All” and ask the participants to reflect silently on the question for one minute. Then ask them to form pairs and discuss the question for two minutes before they join another pair and discuss for another four minutes. When the time is up, ask the quartets to share their results with the large groups. You can also use other Liberating Structures, such as “Conversation Café” or “User Experience Fishbowl.”
1 Lipmanowicz, H., and K. McCandless. 2014. The Surprising Power of Liberating Structures: Simple Rules to Unleash a Culture of Innovation. Liberating Structures Press. ASN: 978-0615975306.
After you have successfully clarified the purpose of the product, have a look at the experiment “Decorate the Team Room with the Product Purpose” later in this chapter to put the purpose to good use. Now that you have clarity on the purpose of your product, ask these questions to hunt for your stakeholders:
• “Who actually uses our product?”
• “Who benefits from our product?”
• “Whose problem are we solving?”
• “How are we engaging these people?”
It’s easy for some teams to answer these questions. Other teams don’t have a clue. When the team has no clue, we recommend making your way up the chain. Ask the team:
• “Who tells us what to work on?”
• “Who tells them what to work on?”
• “What happens before that?”
Once you have identified your stakeholders successfully, you can try other experiments in this book to start interacting with them. “Give the Stakeholder a Desk Close to the Scrum Team” and “Invite Stakeholders to a ‘Feedback Party’” from this chapter as well as “Measure Stakeholder Satisfaction” from Chapter 8 are great choices.
Our Findings
• Zombie Scrum Teams often know very little about where their requirements are coming from. It’s entirely possible that asking the previous questions will earn you a lot of shrugs and confused looks. Start with the Product Owner and see how far you get. If you can’t go any further, ask around within your organization.
• Some stakeholders will receive you with open arms once you start interacting with them. Others will be just as skeptical as Zombie Scrum Teams and won’t see the benefits. Find a way of showing how closer contact with the Development Team can help them!
Create Transparency with the Stakeholder Distance Metric
One of the most important ways Scrum Masters can help organizations improve is to create transparency. This experiment is about creating transparency about the distance between developers and stakeholders (see Figure 6.1) and what happens because of that.
Figure 6.1 Periodically measuring the distance from the people building the product to the people using or paying for it can reveal many impediments to agility.
Effort/Impact Ratio
Steps
The Stakeholder Distance Metric tracks the average number of people, departments, or roles you have to go through (“hops”) in order to convey a question or get feedback from someone who is actually paying for the product or actively using it:
1. Take a selection of items from your Product Backlog that are representative of the kind of work that your team does.
2. Taking one item at a time, draw the chain of people, departments, and roles you have to go through—or get permission from—in order to test this item with an actual stakeholder—that is, someone who is actively using your product or is investing in it significantly.
3. For each hop, come up with a rough estimate for how many hours or days it takes to go through this hop.
4. Repeat this process a couple of times for different kinds of items. Then calculate the average number of hops and the average time the hops take. For extra effect, you can calculate how much time and money is spent waiting for the chain to complete.
5. Write the number of hops and the time they take clearly on a big board or panel that is visible to all. For an extra dramatic effect, you can periodically redraw these numbers on a prominent window or wall.
6. Have a conversation with your team about what the results of this distance are. How is it affecting your team’s ability to work on the right things? How much money and time is being wasted? What is going wrong because of this distance?
Teams recovering from Zombie Scrum will slowly lose their fear of stakeholders. A good way to monitor recovery is to periodically recalculate the Stakeholder Distance Metric. You can use it to drive conversations during Sprint Retrospectives on how to decrease the distance as much as possible. Many of the experiments in this book can help you do that.
Our Findings
• Metrics don’t have meaning in themselves, but they are given meaning through context and conversation. Make sure that you have this conversation with your entire team. You should never use metrics to judge, compare, or evaluate teams that you yourself do not belong to.
• Shortening the distance to the stakeholder might require you to break an existing, highly elaborate product development process. Depending on your position in the system, disrupting that process might not be possible. Nevertheless, see if you can raise awareness for the problem or circumvent the issue by still talking to users and then getting involved in discussions about requirements as early as possible.
Give the Stakeholder a Desk Close to the Scrum Team
Being distant from the stakeholder is a great excuse not to involve them. This experiment removes that excuse by bringing the stakeholder so close that there’s no escaping them. It’s like “Encounter Therapy,” really, and it’s one of the most effective ways to make progress.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Create a desk close to your Scrum Team where one or more stakeholders can comfortably do their own work. Candy helps!
2. Invite one or more stakeholders to make use of this desk whenever they can be available for the Scrum Team. Invite stakeholders who actively use the product or are significantly investing in it. Organize a short event to get to know each other and to clarify the purpose of this experiment.
3. If helpful, create a schedule together of when the stakeholder(s) will be there and put it somewhere clearly visible for the Scrum Team. Working arrangements also help to balance focus and interaction.
4. Observe what happens next.
When stakeholders and teams are not used to this kind of close proximity, some awkwardness is natural. Gently connect the team and the stakeholders wherever relevant if it doesn’t happen on its own. Encourage the team to test assumptions with the stakeholder, such as a new design or a feature under development. Or invite them to work together on refining work for the next Sprint.
This is a great experiment to help people understand what makes product development complex. During Sprints, you’re bound to run into many unforeseen issues. Having the stakeholders present allows you to resolve those problems more quickly. It also allows stakeholders to increase their appreciation of the value they add by being present.
Our Findings
• Some stakeholders assume they have little to contribute while the Scrum Team is doing their work. Having delivered their requirements, they may prefer to wait until the product is done. In that case, invite stakeholders to be present for one or two Sprints and decide afterward how useful their presence was and whether to continue being present.
• This is a great opportunity to celebrate small successes together. Keep an eye out for those moments. Simply going for lunch together is already a great help.
• You can easily flip this experiment around by giving the Development Team desks close to the stakeholders. Two of the authors of this book, in separate instances, arranged with their Scrum Teams to work on a customer site for a while. Aside from easier access to stakeholders, simply sharing the same coffee machine, celebrating the same birthdays, and having lunch together created a productive working environment.
Decorate the Team Room with the Product Purpose
Zombie Scrum Teams tend to appear in environments where nothing reminds them that their purpose is something other than “complete all the work” or “write lots of code.” A first step towards recovery is to change the environment to signal and clarify that purpose.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Considering that it is their team room, you really want to do this with your team. Let them decide how to do it, and take initiative when they don’t. This is also a good opportunity to encourage the Product Owner to take the lead.
2. If no clear purpose statement is at hand for your product, you can use one of the other experiments in this chapter to begin clarifying it (such as “Start a Stakeholder Treasure Hunt”). The purpose statement doesn’t have to be earth-shatteringly brilliant and can be refined over time.
3. Once you’ve made the product purpose visible in the team room, you can start gently using it in your day-to-day conversations with the team: “How is this item from the Product Backlog helping us work on that purpose?”, “If we keep the product purpose in mind, what should we let go of?” and “Considering our product purpose, what is the next step forward?”
There are many ways to decorate the team room with the product purpose:
• Order coffee mugs that have the purpose of the product printed on them.
• Order stickers for laptops, roll-up banners, party flags, buttons, or whatever other material your team fancies that capture the purpose of the product.
• Write down the purpose statement of the product (“This product exists in order to . . .”) on a banner and place it above or below the Sprint Backlog or Scrum Board.
• Create a “The User Says” wall with pictures of real users and quotes about what the product makes possible for them.
• Pick a team name or inspiring motto that captures the purpose of the product.
Our Findings
• In environments with severe Zombie Scrum, where “purpose” is just a word from a vocabulary, these kinds of experiments may understandably be frowned upon as “unnecessary” or “ridiculous.” Be resilient. Even the most cynical members will start appreciating the decorations, visuals, and other artifacts.
• A good purpose statement captures why the product matters to users. What does it simplify, improve, enable, or make better for its users? How is it valuable? A statement like “This product exists to process time cards from flex workers” merely describes what it does, but not why. This statement doesn’t give a lot of guidance on making user-based decisions about which features should be included. A better formulation would be: “This product exists to reduce the time flex workers have to spend on entering time cards and managers have to spend on verifying them.”
Experiments: Involving Stakeholders in Product Development
Scrum without stakeholders is like a race car without a driver. It might look incredible and go really fast, but it doesn’t get you anywhere in particular if there’s nobody to guide it. Involving stakeholders isn’t always easy. This section offers three experiments you can do to involve them in novel and creative ways.
Invite Stakeholders to a “Feedback Party”
Do stakeholders regularly miss or avoid your Sprint Review? Or do your Sprint Reviews usually take the shape of a static presentation with a silent audience? A good Sprint Review is all about gathering feedback and validating assumptions with the people present. The purpose of this experiment is to invite stakeholders to your next Sprint Review, and to use them to gather valuable feedback (see Figure 6.2). This experiment is based on the Liberating Structure “Shift & Share.”2
2 Lipmanowicz and McCandless, The Surprising Power of Liberating Structures.
Figure 6.2 Take your best guerrilla gear and crawl around your users as discreetly as you can.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Together with your Product Owner, identify which stakeholders are most likely to have ideas and feedback on the Sprint Goal that the team has been working on and the work selected for it. Invite them to the next Sprint Review. If you have to, offer cake and coffee to lure them in.
2. Before the Sprint Review, prepare together with the Scrum Team. Together, identify five to seven features or items from the Product Backlog that the team would like to get feedback on. For each of feature or item, set up a station—a flip chart with some information, a laptop, tablet, or desktop—and make sure that each station has one or two members of the team present as “station owners.” Provide each station with stickies or postcards to capture feedback.
3. At the start of the Sprint Review, welcome the stakeholders and make sure to reiterate why their presence is helpful. Proceed to introduce the various stations and explain that stakeholders will be “touring” the stations in short ten-minute time boxes. At each station, stakeholders have the opportunity to try and give feedback on aspects of the Increment.
4. Invite the “station owners” briefly to introduce what their station is about. Everyone else then divides equally across the stations. In rounds of ten minutes, groups tour the stations in a clockwise fashion. Instead of demonstrating new features, the “station owners” invite stakeholders to take control of the laptop, tablet, or desktop and give the new features a try with only minimal guidance.
5. When the groups have visited all stations, invite everyone in the room to take a moment and silently reflect on the following question: “Based on what we’ve seen, what seems to be a next step for us?” After a minute, invite people to form pairs and share their ideas. Give them a few minutes, then invite the pairs to pair up again into groups of four and build on their ideas for five minutes. With the whole group, debrief and capture the most important ideas.
6. If the stakeholders have the time, you can dig deeper into next steps and their feedback. If they don’t, this is a good opportunity for the Product Owner and the team to thank them for their time and extend an invitation to the next Sprint Review. With the Scrum Team, proceed by further digesting the feedback into tangible items and potential objectives for upcoming Sprints.
Our Findings
• Stick to a light-hearted, informal approach and have some fun with it. You’ll notice that users may be quick to apologize for not being able to find their way around a feature or causing errors (“Sorry, I didn’t mean to break it!”). Although such difficulty demonstrates a shortcoming of the product, users often feel “dumb” or “slow” if they can’t figure something out. Especially when others are watching.
• If you’re doing this experiment for the first time, expect things to be awkward. But persist and keep doing the Sprint Reviews like this, and you’ll notice how stakeholders become increasingly engaged over time when they see how their feedback is integrated into the product.
Go on a User Safari
The purpose of this experiment is to help Scrum Teams get to know their users and what their challenges are by spending time with them. Not only does this give developers a much better understanding of the environments in which products are used and by whom, it also helps Development Teams see the purpose of their work.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Working with the Product Owner, identify one or more locations where you’re likely to find (many) users of the product your team is developing. For example, if your team is building a product for managing rail traffic, go visit rail operators in their control rooms.
2. Prepare the User Safari with the Scrum Team by identifying what you’d like to know from stakeholders and their environment. What are things you can observe? What questions can you ask? Also decide how you’re going to record observations. Are you going to take notes? Record audio or video?
3. When you’re at the location, it’s best to break up into pairs to not overwhelm users. Encourage pairs to observe users as they interact with the product and gently ask some open-ended questions now and then. For extra insight, users can verbalize the steps they are taking or considering and what it is they expect will happen.
4. When you’re done observing and taking notes, gather the entire Scrum Team and do a shared debrief of what you noticed. What was surprising for the team? What new ideas or improvements emerged? Capture ideas on the Product Backlog.
Here are some of tips of what to ask or look for:
• Observe what sort of devices people use to view the product.
• Observe the environment that users operate in.
• Ask: “How does this feature help you in your day-to-day work?”
• Ask: “What can we do to make it easier for you to use this product?”
• Ask: “If we had to rebuild this product from the ground up, starting from scratch, what would be the first thing you’d want us to bring back?”
Our Findings
• Some users may be hesitant to let developers observe. If necessary, agree on a time box and specific work agreements up front. And always be clear about how their feedback can help make the product—and their work—easier.
• Prepare your Development Team for a scenario where users are critical of their work. Some people are better able to express criticism than others. It’s helpful for Development Teams to avoid becoming disheartened or defensive, but instead explore openly where the criticism is coming from. Critical users can turn into your biggest proponents when they notice that they are being listened to.
Experience: Small Discoveries with a Lot of Feedback
Here’s a tale of firsthand experience from one of this book’s authors:
With four developers, we drove to a facility with a lot of planners: our users. On the site, we quickly noticed how noisy and chaotic the environment was. Telephones rang all the time, people inquired loudly about the availability of certain flex workers, and other people walked in with questions. We discovered something crucial. While on the telephone—the telephone tightly jammed between a planner’s head and shoulder—the planner used our product to change the planning for a particular flex worker. Keeping the phone between the head and shoulder meant that the planner’s head was tilted. Combined with the small screens that planners used, this made reading the text and navigating with the cursor difficult. Back at our office, we quickly updated the application to increase the font size and use larger buttons. It was a small change that really improved the usability of the application.
Guerrilla Testing
Finding users isn’t easy. The purpose of this experiment is to perform playful user testing by getting Development Teams out of the office and close to actual and potential users.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. With your Development Team, pick a discrete number of Product Backlog items or assumptions you’d like to test. This can be anything from working software to a paper prototype or a design.
2. Go to a place where you’re likely to meet real users. This can be the lunchroom or a meeting point in your building if your product is for internal use. If you have external users, visit locations where you might find them. Or go to a coffee shop or the park. In some organizations, you can also find plenty of potential users in the public waiting lounge.
3. Form pairs and walk around. With a laptop in hand, ask people if they can spare a few minutes to help you improve a product. The best feedback comes from goal-based behavior. Ask a user to perform a particular action or achieve a particular goal. Write down any observations or feedback. You can even film the session if the user doesn’t mind. Rinse and repeat to gather feedback from different users. It’s also a great way to get a sense of who your users are and what they’re looking for.
4. Periodically, gather the entire Scrum Team and do a shared debrief of what you noticed. Allow people to blow off some steam and share their excitement and discoveries. Together, explore what was surprising, what new ideas or improvements emerged, and what other things you should be looking for. Repeat with additional rounds of testing as needed.
Our Findings
• If this is the first time you’re doing this, the Development Team will be understandably nervous. Working in pairs is a good way to back each other up. You can also do some role-play to practice potential interactions. Some guerrilla gear, ranging from walkie-talkies to caps, may come in handy (see Figure 6.2).
• When you do this experiment in a coffeehouse, you can offer participants free coffee in return for their time and feedback.
Experience: Researching the Users
Here’s another tale of firsthand experience from one of this book’s authors:
We arranged the opportunity to set up a stand at a conference that was related to our platform. This was an excellent way to do some guerrilla testing on a new workflow in our latest release. We got ourselves two monitors, a keyboard, and a mouse and set up the stand. We decorated the stand with banners and a large map, and we dressed up as “researchers,” wearing lab coats and carrying clipboards. We asked each passerby if they’d like to give us feedback on our platform. Thankfully many did and sat down with us to click through the workflow. We recorded their feedback, asked what they liked and didn’t like, and identified what parts of the application people often struggled with. This extended testing session not only resulted in invaluable feedback, but it also yielded a lot of people interested in our platform.
Experiments: Keeping Your Focus on What Is Valuable
Instinctively we all seem to understand the power of focus. But finding that focus, and holding onto it, is challenging. This section offers three experiments to help make this possible.
Limit the Maximum Length of Your Product Backlog
It’s easy to have a huge Product Backlog. Keeping it short requires many things to be in place, including a guiding purpose and a Product Owner with a mandate and the ability to say “No” to potentially great ideas that don’t fit the time and budget you have. The purpose of this experiment is to add a constraint to the length of the Product Backlog and to see what happens next.
Effort/Impact Ratio
Steps
To try this experiment, do the following:
1. Together with the Product Owner, define a constraint for how long the Product Backlog can be before items have to be removed. There is no single number that works best for all scenarios. But in our experience, you want a number that results in a Product Backlog that you can view in one (long) look and have a sense of what is going to happen. Generally, shorter is better. Many teams like limits between 30 and 60 items.
2. If the Product Backlog of your team is already ordered, you can jump to the next step. If not, work together with the Product Owner, the team, and stakeholders to reorder the Product Backlog with the purpose of the product in mind.
3. Invite the Product Owner to remove all the items that are beyond the constraint. Moving them elsewhere on the wall or to another list in Jira doesn’t count. Actually throw them away. If teams have physical boards, we always like to bring in a trash can to do this in a very visible way. Does it hurt? Yes. Will people object or faint? Probably. But by being very clear about what is going to happen and what isn’t, you create transparency for your stakeholders about what to expect.
4. Visualize the constraint on your Product Backlog. If you have a physical one, you can simply limit the space you have. Most digital tools support list constraints. Make sure to clearly show the purpose of the product next to the constraint, as this is the touchstone for each decision about what to keep and what to throw away.
5. Encourage the Product Owner to clean up the Product Backlog frequently to make the best use of the items you can put up there.
Our Findings
• This experiment can expose many impediments. It may show that your Product Owner has no say in what goes on the Product Backlog. Or it may show that your team spends too much time refining items way down the Product Backlog, making it feel wasteful to throw all those specifications away. But this experiment can also show that there is no clear guiding purpose for your product, something that helps to make decisions about what goes on the Product Backlog. Whatever the case, sticking to the constraint is a great way to keep focus on solving those impediments instead of working around them.
• Be clear, but also be respectful of the items you remove. Each of them represents a potentially great idea for the product. And when items are removed from the current Product Backlog, they may reappear if they are great enough for the product you’re trying to build.
Map Your Product Backlog on an Ecocycle
In environments where Zombie Scrum is present, you find teams stuck in an endless trudge. Sprint after Sprint, they keep working on products that themselves have become lifeless. The purpose of this experiment is to reinvigorate the Product Backlog and create space for innovation and focus.
Effort/Impact Ratio
Steps
Ecocycle Planning is part of the repertoire of Liberating Structures.3 Its purpose is to analyze the full portfolio of activities and identify obstacles and opportunities for progress. That makes it an excellent way to periodically clean up and refocus your Product Backlog. It is based on the life cycle in nature, as shown in Figure 6.3.
3 Lipmanowicz and McCandless, The Surprising Power of Liberating Structures.
Figure 6.3 Map Your Product Backlog on an Ecocycle4
4 Source: Lipmanowicz and McCandless, The Surprising Power of Liberating Structures. Modified by Fisher Qua.
Within the context of Product Development, all work that happens as part of the life cycle for a product can be plotted on the Ecocycle as follows:
• Renewal represents ideas for future work that is completely new and innovative. It may involve ideas for exploring new technologies, new features, or new markets.
• Birth represents work to turn an idea from gestation into something tangible. This can involve building a prototype, testing a new design with stakeholders, or trying out the very first part of a feature.
• Maturity represents work on stable and mature parts of the product. This may involve support, fixing bugs, and making small, incremental tweaks to what is already there.
• Creative Destruction represents work on parts of the product that are on their way out, or work that is itself no longer valuable.
All activities flow through the Ecocycle. But they can also get stuck. Or there can be disbalances such as all energy going to the right side of the Ecocycle, leaving no time and space for innovation. Work that you know is important, but is never picked up, gets stuck in the Poverty Trap. This could be automating certain parts of deployment, updating to a new framework, or fixing that annoying bug that people keep complaining about. Work that you keep doing, but isn’t really adding any value any longer, is in the Rigidity Trap. This could be maintenance on a feature that isn’t being used or doing a certain kind of work in one way while there may be a better way to do it. By plotting all the work across the Ecocycle, you can identify patterns that tell you something about where the product, and the work you have planned for it, is in its life cycle:
• A healthy Product Backlog has work distributed all over the Ecocycle. There is innovation taking place, as evidenced by work on the left side of the model, and there is work to make the product more mature and robust, as evidenced by work on the right. Furthermore, teams are consciously deciding what features and work to let go of, as represented in work that is in Creative Destruction.
• Work that is in the Rigidity Trap or in Creative Destruction is a prime candidate for removal, or at least reinvention. Start there before adding new things, as the removal of work creates space for something new.
• Ecocycle Planning can be done with individual items on the Product Backlog. But you can also apply it to the features of your product. Or to your entire portfolio of products. The applications are endless. But doing it once doesn’t get you far; do it often.
So how do you do this with your team? We like to do it as follows:
1. Work with the Product Owner to invite a group of stakeholders and the Development Team to participate in cleaning up the work and to refocus on what is important.
2. Introduce Ecocycle Planning. Explain the metaphor and the quadrants and give some examples to help people understand it. It’s okay if people don’t get it right away; you really have to experience Ecocycle Planning multiple times for people to start seeing the possibilities.
3. Invite everyone present to draw their own Ecocycle on a piece of paper or in a notebook and distribute the items where they think they are in the Ecocycle for the product. To make this easier, you can number the items on the Product Backlog and invite people to use those instead of writing the items (which is a lot of work).
4. If you have a fairly large group (more than eight to ten people), invite people to pair up and share how they distributed the items across their Ecocycles for a few minutes. Encourage them to work together to finalize the placement.
5. On a prepared larger version of the Ecocycle, perhaps even a huge one on the floor or on a wall, invite everyone to put the items where they think they are in the Ecocycle of this product.
6. Invite people to reflect on the patterns that emerge. Ask: “What does the distribution of items across the Ecocycle seem to be saying about our product, and what is important for it?” Let people do this first individually for a minute, then in pairs for a few minutes and paired up with another pair for four minutes. Encourage the groups to share the most important patterns with the whole group.
7. Invite people to form small groups and identify next steps for cleaning up the Product Backlog. Which items should be removed? What new ideas emerge that should replace existing items on the Product Backlog? Encourage teams to focus on items that are in one of the traps or items that can be creatively destroyed in other ways, as that helps clean up the Product Backlog.
Our Findings
• The way Ecocycle Planning invites us to think about products usually doesn’t come natural to Zombie Scrum Teams. You really have to do this multiple times for people to understand the different quadrants and how to make sense of the patterns.
• Because this experiment gives everyone a voice, teams may sigh with relief when they discover that everyone feels the same way about where certain work is placed. Celebrate those moments: letting go of work because you discover it isn’t valuable is more important than simply adding more work.
• Using Ecocycle to visualize your product shouldn’t be a one-time activity. We recommend that teams create a large Ecocycle poster and put it on the wall in the team room. This encourages updating the Ecocycle continuously and will trigger useful conversations during the Scrum Events.
Express Desired Outcomes, Not Work to Be Done
The way you capture the work that needs to be done on your product has a huge impact on the team doing the work. This experiment changes the way you write your Product Backlog items (PBIs) and makes it easy to have daily conversations about outcomes and stakeholder-centricity.
Effort/Impact Ratio
Steps
Despite what most people believe, you are free to use whatever format you like to describe the work on your Product Backlog. The Scrum Guide never mentions “User Story” once. No matter which format you use, don’t focus on the tasks that need to be done. Focus on what you want to achieve with them and why. If it helps, mention whom you’re developing this for. Here are some options to consider:
• Write your PBIs as conversations to be had with your stakeholder. What do you need to clarify with your stakeholder so you can start building the solution? For example: “The appearance of the option to redeem a discount code has been designed with Jimmy.”
• Write your PBIs as actual needs from actual users. An example might be that “Tessa wants to view all orders from this week so she knows whom to invoice” or “Martin and his team want to send shipment notifications directly so they don’t have to ask Pete every time.”
• Write your PBIs as a final user acceptance test. What is it that the user is going to do that will let you know whether you’ve succeeded? This needs to be clear enough so that you can answer the question “Is the user able to do this?” with a simple yes or no. For example: “The user can add an item to the shopping basket.” These items are perfect candidates for letting actual users try them out in a Sprint Review.
• Write your PBIs as an outcome or target state. What is the specific end state that is going to provide value? For example: “The app displays the final amount to be paid, including taxes.”
So how do you do this with your team? We like to do it as follows:
1. Schedule some time together with your team to develop Product Backlog. We highly recommend inviting actual stakeholders to this workshop to help you answer questions about what is valuable and what isn’t.
2. Either take a selection of items from an existing Product Backlog or perform a high-level overview of potential work if you don’t already have one. A Liberating Structure such “1-2-4-All,” “Min Specs,” or “Impromptu Networking” is helpful here.5
5 Lipmanowicz and McCandless, The Surprising Power of Liberating Structures.
3. For each item, use the Liberating Structure “1-2-4-All” to have the group consider these questions for each item: “Who benefits when this is done?”, “What is different when this is done?”, “Why is that important?” and “What happens if we don’t do this?” Based on the answers, decide together on the best way to capture it on the Product Backlog.
4. Repeat until you have a good enough sense of the work that is coming up to continue for the coming Sprints. Resist the temptation to spend a lot of time on items that lie further into the future. The further down the Product Backlog you go, and the further into potential futures that may or may not happen, the rougher and larger the items can remain. Conserve your energy for the nearer future.
Our Findings
It is easy to slip back into the pattern of describing things that need to be done instead of outcomes you would like to achieve. If you are struggling to slice your items in a way that the outcomes stay visible and testable, the experiment “Slice Your Product Backlog Items” in Chapter 8 is helpful.
Now What?
In this chapter, we explored ten experiments to start building what stakeholders need. Some are easier than others and the expected impact varies. But each experiment can be done in environments where Zombie Scrum is rife. Give them a try and see what happens.
However, in the past we also discovered that building what stakeholders need goes hand in hand with being able to ship fast to meet their needs. When it takes months for changes to reach stakeholders, there’s no urgency for them to provide their feedback as early as possible. Even the most stakeholder-oriented Scrum Teams zombify when they lose this stream of feedback. In the next part, we explore what Scrum Teams can do to start shipping faster.
Looking for more experiments, recruit? There is an extensive arsenal available at zombiescrum.org. You can also help expand our arsenal by suggesting what worked well for you.”
