A Scrum Master’s guide to eliciting feedback.
If you’ve never watched Little Shop of Horrors, I highly recommend that you do. It’s a 1986 musical comedy (yes, it’s a musical) about a flower shop worker named Seymour, who discovers a bizarre singing plant. Caring for it proved to be an exercise in frustration. Water, nor light helped the plant grow. Seymour then accidentally discovers the one simple thing that it requires to sustain itself… blood. Yikes! I know, a little dark. The titular song says it all.
You might wonder where I’m going with this. Well, just like Audrey II (Seymour named the plant after Audrey, his coworker that he secretly in love with), Scrum teams also sustain themselves with one simple thing… feedback.
Cool! We have an event for that. The why of the Sprint Review is to provide a forum “…to elicit feedback, and foster collaboration.” The audience for this informal session should include those who have a vested interest in what the team is building. Ya know, stakeholders.
In this post, I’m not gonna talk about how to run a Sprint Review. There’s plenty how-to articles out there on that topic. Instead, I wanna discuss that little nugget of nourishment that teams require: feedback, and how to elicit some that’s actually useful .
“Feedback is a gift. Ideas are the currency of our next success. Let people see you value both feedback, and ideas.” — Jim Trinka & Les Wallace
At a spot where I previously worked, we held combined Sprint Reviews. Three teams worked on three different products. However, by architectural design, all three products shared the same code base. With about twenty people in attendance, developers showed off whatever they’d completed each Sprint. One after another, developers would ramble in stream-of-consciousness technobabble to bored Product Owners, and when they finished, the entire entourage applauded. What actions could one possibly take based on a group of people clapping to express approval? That’s not the type of feedback that sustains a team.
So, what kind of feedback you do want from stakeholders? Before we move to that, let’s press pause. It’s important to clarify what makes a stakeholder. The Scrum Guide is vague on this one, so of course there’s gonna be different interpretations. Over the years, I’ve seen seen Product Owners, business sponsors, managers, product managers, and even architects invited to Sprint Reviews. While these can be stakeholders, we have a tendency to skip the folks that can provide some of the most valuable feedback: customers, and end users.
To help uncover the folks with a vested interest (or have a stake) in what teams are building, Barry Overeem poses these questions:
- Are they going to use, or are they using the product on a regular basis?
- Are they investing significantly in the development of the product?
- Are they personally invested in solving a challenge that your product addresses?
From what I’ve seen, the first question tends to get ignored. With stakeholders comprised primarily of business folks, and managers, feedback in Sprint Reviews runs the gamut from “Great job, team. You finished lots of work this Sprint,” or “Thanks for putting in extra hours, and working weekends,” or even “You rock! This meets all the defined use cases, and business requirements.” This isn’t to say that sentiments like these aren’t valuable for the team to hear — it’s absolutely important to celebrate their efforts. Celebration is valuable, not actionable.
When you spend copious amounts of time, and money working on something, but it doesn’t solve a problem, or address a concern, it’s wasted effort. Worse, it’s wasted money. By primarily focusing on metrics during a Sprint Review, showing stakeholders things like burn-down charts, or velocity calculations, you’re delivering outputs. We’re all familiar with the expression “outcomes over outputs,” right? In a recent video, Kent Beck further illustrated the distinction by calling out where outcomes exist: after the consumer uses something.
I won’t downplay the usefulness of things such as metrics, but outcomes are validated, or invalidated by asking customers, and end users for their feedback. That’s part of the learning bit (empiricism).
So, how do you elicit useful feedback? First, and foremost, those values that Scrum holds dear need to be more than simply words on a page. If you haven’t taken the time to cultivate an open environment where people feel free to express their honest opinions, getting something useful might prove difficult.
When it comes to asking people what they think, delete any yes-or-no type questions from your lexicon. Yes, and no responses don’t provide context, nor actionable direction, so you’ll need to dig deeper. Consider probing, or open-ended questions instead; ones that make people think before they answer. In the past, I’ve started off with questions like these:
- “What’s one thing you like about it?”
- “What’s one thing you hate about it?”
- “If you could change one thing about it, what would that be?”
These are decent enough to get you started, but don’t forget to dig deeper. To start, follow up with 5 Whys. They can help with that. Keep in mind it’s vital to be deliberate when eliciting feedback, so ask folks to be 100% open, and honest. That kind of transparency isn’t always easy to achieve, but it’s essential to work toward.
Feedback also needs to be timely. Thankfully, Sprint Reviews are a great, recurring event for this expressed purpose. Finally, don’t forget to follow up in the next Sprint Review. After stakeholders have had time to kick the tires, and actually use what you delivered, ask what their experience with the product was like.
At the end of the day, actively eliciting feedback ensures that you’ve built the right thing, and solved a customer, or end user’s problem. It also helps you understand whether you’ve wildly miss the mark. Feedback is what teams crave, so feed them. You’d be surprised how eliciting effective feedback during Sprint Reviews can bolster the team’s morale, and motivation.