Your demo is going super-smooth. No cracks. No gaps. Everything is working according to design. A dynamite end to a flawless sprint. Then Dave, who has been absent most of the last quarter, stands up and says:

"It shouldn’t take five steps for a user to submit a request. Nobody is going to go through all that. This is never going to work."

Did he really just say that? The room goes silent. What happens next makes a huge difference for the entire product delivery team.

Anti-patterns

Here are a few things that we’ve seen happen, often with very good intention, but that caused pain down the line.

The product manager disagrees with the stakeholder:

“Well, actually, in 50% of the cases, it’s only 4 steps.”

She wants to convey more detail about additional scenarios...
...but an argument ensues about how often the additional scenarios apply, and the next half-hour is spent showing exception cases.

The designer responds to the stakeholder:

“But you approved the design.”

He wants to stick up for his teammates...
...but the discussion becomes about who is to blame for the wasted time and effort.

The developer running the demo responds:

“I’ve just checked in the change and now it’s just three steps.”

He cares what the stakeholder thinks, and wants to fix it as soon as possible...
...but he skipped ahead of the product and design teams to a result that will likely have to be reversed.

The designer of the feature asks:

“Well Dave, how do you think it should work?”

Perhaps she wants to hear what the stakeholder thinks...
...but what happens is you start redesigning the feature in (a very large, expensive) committee.

The account manager steps in and says:

“Let’s set up time next week to meet one-on-one.”

He wants to save the time of the group, to connect with the stakeholder, and make him feel heard...
...but instead starts a product conversation with the product manager out of the loop.

Negative Feedback is Not a Bad Thing

It’s misguided to expect no reactions from stakeholders during the demo. To hope for ten or twenty busy stakeholders to nod approvingly in unison sprint demo after sprint demo is crazy. If that happens, then your stakeholders are either checked out (bad), or they are silently plotting to replace you (worse). 

Negative feedback, criticism or skepticism isn’t a bad sign. It can happen because:

• Stakeholders have a motivation/incentive you didn’t know about.
• A stakeholder had checked out, and is now checking in again.
• Product direction wasn’t discussed or communicated clearly in advance, and/ or there was a misunderstanding about the direction, so stakeholders are surprised by what they see.
• Prior stakeholder approval/buy-in wasn’t carefully considered (see ‘decision fatigue’).
• There was a real stakeholder who was not identified initially.
• The scope of the project / product has changed over time, and more people are caring about it now.

People really do have different reactions when they see something working all at once that they had previously only seen without real delays, real timings, and real data. Keep in mind that the demo environment, while different and new, is not necessarily more realistic than the other environments the stakeholder may have seen it in. Stakeholders may get called on to give feedback on dozens of things every day that they don’t anticipate seeing again, and approve dozens of things that never get built for some reason or another. This is different to them. This is real.

How We Handle Demo Feedback

We recommend these rules for leading effective sprint demos.

The Product Manager should initially field feedback during the sprint demo, and facilitate a few simple things:

• Guide the discussion in a way that recognizes that feedback is welcome and gathered during these meetings, and is addressed.
• Repeat the feedback in a way that ‘levels’ the speculative and factual content: “You said that five steps is too many steps. Can we generalize and say that we’re looking for the easiest way for users to submit a request, and that we should in general test it with users so that we can actually see what they’re willing to do.”
• If the feedback is critical of the process that got us to this point, the Product Manager should (in a balanced way) briefly describe the process that got us here, and invite feedback on the process during a retrospective.
• Commit to follow up on the feedback, either with additional research or meeting with the stakeholder, to orchestrate others who may need to be involved on behalf of the team.
• At the next meeting (or by email), show what has been done with the feedback so that it’s clear it wasn’t buried. It’s fine to say (for example) that the stakeholder helped weigh the benefit of doing further research against the cost of delay, and decided that we shouldn’t do further research right now.

When making a commitment to follow up, take into consideration the role of the stakeholder: is it an interested bystander? Is it somebody “downstream” whose day-to-day will be drastically affected by the feature they are commenting on? Is it a manager whose direct reports have exerted heavy influence on the process to date?

It’s not always successful, but if you have it at your fingertips, you may also show the evidence the decision was based on. For example, “Dave, we were worried about that, too. So we tested it and here’s what the evidence told us…”. If it’s available, offer to share further data after the demo. This approach has a mixed success rate, because the evidence needs to be presented in a way that does not invalidate the experience of the stakeholder, which may include emotions.

The important thing to keep in mind is that the feedback that arrives during the demo doesn’t necessarily need to be acted upon immediately. You wouldn’t want your engineering team making changes based on one voice in the room. You don’t want your designers to become demoralized because of late or incongruous feedback. It’s just another signal about the product or feature that should inform the whole team over time. Hear it, consider it, then choose the next step together in a balanced, rational way.  

How are your sprint demos going these days? If you see anti-patterns, maybe Lab Zero can help.