AoAD2 Practice: Stakeholder Demos

This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!

This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

📖 The full text of this section is available below, courtesy of the Art of Agile Development book club! Join us on Fridays from 8-8:45am Pacific for wide-ranging discussions about Agile. Details here.

Stakeholder Demos

Product Managers, Whole Team

We keep it real.

Agile teams can produce working software every week, starting from their very first week. This may sound impossible, but it’s not; it’s merely difficult. And the key to learning how to do it well is feedback.

Stakeholder demos are a powerful way of providing your team with the feedback it needs. They’re just what they sound like: a demonstration, to key stakeholders, of what your team has completed recently, along with a way for stakeholders to try the software for themselves.

Feedback Loops

Incremental Requirements
Real Customer Involvement

Stakeholder demos provide feedback in multiple ways. First, the obvious: stakeholders will tell you what they think of your software.

Although this feedback is valuable, it’s not the most valuable feedback you get from a stakeholder demo. The team’s on-site customers work with stakeholders throughout development, so they should already know what stakeholders want and expect.

So the real feedback provided by stakeholder comments is not the feedback itself, but how surprising that feedback is. If you’re surprised, you’ve learned that you need to work harder to understand your stakeholders.

Another type of feedback is the reactions of the people involved. If team members are proud of their work and stakeholders are happy to see it, that’s a good sign. If team members aren’t proud, or are burned out, or stakeholders are unhappy, something is wrong.

The people who attend are another form of feedback. If there are people attending whom you didn’t consider stakeholders, consider reaching out to them to learn more, especially if they’re active participants. Similarly, if there are people who you expected to be vitally interested in your work, and they’re not present, it’s a good idea to learn why.

The demo itself is a “rubber meets the road” moment for the team. It gives you feedback about your team’s ability to finish its work. It’s harder to fool yourself into thinking work is done when you can’t demo it to stakeholders.

Stakeholder Trust

Finally, the demo provides feedback to stakeholders, too. It shows them that your team is accountable: that you’re listening to their needs and making steady progress. This is vital for helping stakeholders trust that your team has their best interests at heart.

The Demo Cadence

Start by conducting a stakeholder demo every week, or every iteration, if you use iterations that are longer than a week. Always conduct the demo at the same time and place. This will help you establish a rhythm, make it easier for people to attend, and show strong momentum right from the start.

Real Customer Involvement

Unless your team’s work is secret, invite anybody in your company who might be interested. The whole team, key stakeholders, and executive sponsor should attend as often as possible. Include real customers when appropriate. Other teams working nearby and people who are curious about Agile are welcome as well.

If you use iterations, conduct the demo immediately after the iteration ends. I like to have mine first thing the following morning. This will help your team stay disciplined, because you won’t be able to stretch work into the next iteration.

The demo should typically be scheduled for 30 minutes. It can be longer, but your most important stakeholders have a lot of demands on their time, so it’s better to plan short meetings so they can attend regularly. Let their interest and availability guide your decision. Remember that you can always follow up with people after the demo, too.

Feature Flags

In addition to the demo presentation, provide a way for stakeholders to try the demo on their own. This might take the form of a staging server, or, if you’re using feature flags, special permissions on stakeholders’ accounts.

After you’ve conducted several demos and the excitement of the new work dies down, you’re likely to find that a weekly demo is too frequent for some of your key stakeholders. You can start holding the demo every two weeks instead, or even once a month. Don’t wait longer than that, though. It’s too infrequent for good feedback. Regardless of the frequency of your presentations, continue to share demo software every week or iteration.

How to Conduct a Stakeholder Demo

Anybody on the team can lead the stakeholder demo. The best person to do so is whoever works most closely with stakeholders—typically, the team’s product manager. They’ll speak stakeholders’ language and have the best understanding of their point of view. It also emphasizes how stakeholder needs steer the team’s work.

Product managers often ask developers to lead the demo instead. I see this most often when the product manager doesn’t see themselves as part of the team, or doesn’t feel that they know the software well. Push back on this request. Developers aren’t building the software for the product manager; the whole team, including the product manager, is building the software for stakeholders. The product manager is the face of that effort, so they should lead the demo. Help the product manager be more involved and comfortable by reviewing stories with them as they’re built.

The prepared portion of the demo should be less than 10 minutes. You don’t need to show every detail. As you present, allow interruptions for questions and feedback, but keep an eye on the clock so that you end on time. If you need more time because you’re getting a lot of feedback, that’s a sign that you should conduct demos more often. On the other hand, if you’re having trouble attracting attendees, or they don’t seem interested, conducting demos less often may give you more meat to share.

If you have a particularly large audience, you may need to set some ground rules about questions and interruptions to prevent the demo from taking too long.

Because the meeting is so short, it’s good to start on time, even if some attendees are late. This will send the message that you value attendees’ time. Both the presenter and demo should remain available for further discussion and exploration after the meeting.

Begin the presentation by briefly reminding attendees about the valuable increment the team is currently working on and why it’s the most important use of the team’s time. Set the stage and provide context for people who haven’t been paying full attention. Then provide an overview of the stories the team worked on since the last demo.

Calmly describe problems and how you handled them.

If you’ve made any changes to your plan that stakeholders will care about, explain what happened. Don’t sugarcoat or gloss over problems. Full disclosure will raise your credibility. By neither simplifying nor exaggerating problems, you demonstrate your team’s ability to deal with problems professionally. For example:

Demonstrator: In the past two weeks, we’ve been focusing on adding polish to our flight reservation system. It’s already complete, in that we could release it as-is, but we’ve been adding “delighters” to make it more impressive and usable for our customers.

We finished all the stories we had planned, but we had to change the itinerary visualization, as I’ll show you in a moment. It turned out to be too expensive, so we had to find another solution. It’s not exactly what we had planned, but we’re happy with the result.

After your introduction, go through the stories the team worked on. Rather than literally reading each story, paraphrase them to provide context. It’s okay to combine stories or gloss over details that stakeholders might not be interested in. Then demonstrate the result in the software. Stories without a user interface can be glossed over or just described verbally.

Demonstrator: Our first two stories involved automatically filling in the user’s billing information if they’re logged in. First, I’ll log in with our test “reservations”...and there, you can see that the billing information fills in automatically.

Audience member: What if they change their billing information?

Demonstrator: Then we ask them if they want to save the changed information. (Demonstrates.)

Stakeholders will often have feedback. Most of the time, the feedback will be minor. If it’s a substantial change in direction, think about how you can better engage your stakeholders during development next time, so that you’re not surprised. Either way, make a note of the suggestion and promise to follow up.

Audience member: Does it alert customers when their saved billing information is out of date?

Demonstrator: Not at present, but that’s a good idea. (Makes note.) I’ll look into it and get back to you.

If you come to a story that didn’t work out as planned, provide a straightforward explanation. Don’t be defensive; simply explain what happened.

Demonstrator: Our next story involves the itinerary visualization. As I mentioned, we had to change our plans for this. You may remember that our original plan was to show flight segments with an animated 3D fly-through. Programmers had some concerns about performance, so they did a test, and it turned out that rendering the animation would be a big hit on our cloud costs.

Audience member: Why is it so expensive? (Demonstrator motions to a programmer.)

Programmer: Some mobile devices don’t have the ability to render 3-D animation in the browser, or can’t do it smoothly. So we would have had to do it in the cloud. But cloud GPU time is very expensive. We could have built a cloud version and a client-side version, or maybe cached some of the animations, but we’d need to take a close look at usage stats before we could say how much that would help.

Demonstrator: This was always a nice-to-have, and the increased cloud costs weren’t worth it. We didn’t want to spend extra development time on it either, so we dialed it back to a normal 2D map. None of our competitors have a map of flight segments at all. We didn’t have enough time left over to animate the map, but after seeing the result (demonstrates), we decided that this was a nice, clean look. We’re going to move on rather than spending more time on it.

Once the demo is complete, tell stakeholders how they can run the software themselves. This is a good way of wrapping up if the demo is running long: let the audience know how they can try it for themselves, then ask if anybody would like a private follow-up for more feedback or questions.

Be Prepared

Done Done

Before the demo, make sure all the stories being demoed are “done done” and that you have a version of the software that includes them. Make sure attendees have a way to try the demo for themselves.

You don’t need to create a polished presentation with glitzy graphics for the demo, but you still need to be prepared. You should be able to present the demo in 5–10 minutes, so that means knowing your material and being concise.

Visual Planning

To prepare, review the stories that have been finished since the last demo and organize them into a coherent narrative. Decide which stories can be combined for the purpose of your explanation. Look at your team’s purpose and visual plan and decide how each set of stories connects to your current valuable increment, your upcoming release, and the team’s overall mission and vision. Create an outline of what you want to say.

Finally, conduct a few rehearsals. You don’t need a script—speaking off the cuff sounds more natural—but you do want to be practiced. Walk through the things you’re planning to demonstrate to make sure everything works the way you expect and all your example data is present. Then practice what you’re going to say. Do this a few times until you’re calm and confident.

Each demo will take less and less preparation and practice. Eventually, it will become second nature, and preparing for it will only take a few minutes.

When Things Go Wrong

Sometimes, things just don’t work out. You won’t have anything to show, or what you do have will be disappointing.

It’s very tempting in this situation to fake the demo. You might be tempted to show a UI that doesn’t have any logic behind it, or purposefully avoid showing an action that has a significant defect.

Be clear about your software’s limitations and what you intend to do about them.

It’s hard, but you need to be honest about what happened. Be clear about your software’s limitations and what you intend to do about them. Faking progress leads stakeholders to believe you have greater capacity than you actually do. They’ll expect you to continue at the inflated rate, and you’ll steadily fall behind.

Instead, take responsibility as a team (rather than blaming individuals or other groups), try not to be defensive, and let stakeholders know what you’re doing to prevent the same thing from happening again. Here’s an example:

This week, I’m afraid we have nothing to show. We planned to show you live flight tracking, but we underestimated the difficulty of interfacing with the backend airline systems. We expected the data to be cleaner than it is, and we didn’t realize we’d need to build out our own test environment.

We identified these problems early on, and we thought we could work around them. We did, but not in time to finish anything we can show you. We should have replanned around smaller slices of functionality so we could still have something to show. Now we know, and we’ll be more proactive about replanning next time.

We expect similar problems with the airline systems in the future. We’ve had to add more stories to account for the changes. That’s used up most of our buffer. We’re still on target for the go-live marketing date, but we’ll have to cut features if we encounter any other major problems between now and then.

I’m sorry for the bad news and I’m available to answer your questions. I can take some now, and we’ll have more information after we finish revising our plans later this week.


What do we do if stakeholders keep interrupting and asking questions during the demo?

Questions and interruptions are wonderful. It means stakeholders are engaged and interested.

If you’re getting so many interruptions and questions that you have trouble sticking with the 30-minute time limit, you might need to hold demos more often. Otherwise—especially if it’s just one particularly engaged individual—you can ask them to hold further questions until after the meeting. It’s also okay to plan for meetings longer than 30 minutes, especially in the first month or two.

What do we do if stakeholders keep nitpicking our choices?

Nitpicking is also normal, and a sign of interest, when you start giving demos. Don’t take it too personally. Write the ideas down on cards, as with any story, and prioritize them after the meeting. Resist the temptation to address, prioritize, or begin designing solutions in the meeting. Not only does this extend the meeting, it avoids the discipline of the normal planning practices.

If nitpicking continues after the first month or two, it may be a sign that on-site customers are missing something. Take a closer look at the complaints to see if there’s a deeper problem.

Stakeholders are excited by what they see and want to add a bunch of features. They’re good ideas, but we need to move on to something else. What should we do?

Don’t say “no” during the demo. Don’t say “yes,” either. Simply thank the stakeholders for their suggestions and write them down as stories. After the demo is over, on-site customers should take a close look at the suggestions and their value relative to the team’s purpose. If they don’t fit into the team’s schedule, a team member with product management skills can communicate that back to stakeholders.

What if people don’t come to the demo, or aren’t engaged?

You may be holding the demo too frequently, or taking too long. Try conducting the demo less frequently and practicing speaking concisely. It’s also possible that people don’t see your software as relevant to them. Ask key stakeholders what you can do to make the demo more useful and relevant.

What if we have multiple teams working on the same software?

It might make sense to combine the teams’ work into a single demo. In that case, choose one person to show everyone’s work. This requires cross-team coordination, which is out of the scope of this book, but you should have cross-team coordination in place as part of your scaling approach. See the “Scaling Agility” chapter for ideas.

If it doesn’t make sense to combine the teams’ work into a single demo, then you can continue to have separate demos. Some organizations prefer to schedule them all together in one large meeting, but that doesn’t scale well. Instead, create multiple combined demos—for example, one for customer-facing teams, one for internal administration, one for development support, etc.—and schedule them so that people can pick and choose which they attend.


Never fake a stakeholder demo by hiding bugs or showing a story that isn’t complete. You’ll just set yourself up for trouble down the line.

Task Planning

If you can’t demonstrate progress without faking it, it’s a clear sign that your team is in trouble. Slow down and try to figure out what’s going wrong. If you aren’t using iterations, try using them. If you are, see the “Making and Meeting Iteration Commitments” section and ask a mentor for help. The problem may be as simple as trying to do too much in parallel.


When your team conducts stakeholder demos well:

  • You generate trust with stakeholders.

  • You learn what stakeholders are most passionate about.

  • The team is confident in its ability to deliver.

  • You’re forthright about problems, which allows your team to prevent them from ballooning out of control.

Alternatives and Experiments

Stakeholder demos are a clear indication of your ability to deliver. Either you have completed stories to demonstrate, or you don’t. Either your stakeholders are satisfied with your work, or they’re not. I’m not aware of any alternatives that provide such valuable feedback.

And it’s feedback that’s the important part of the stakeholder demo. Feedback about your team’s ability to deliver, feedback about your stakeholders’ satisfaction, and also the feedback you get from observing stakeholders’ responses and hearing their questions and comments.

As you experiment with stakeholder demos, be sure to keep that feedback in mind. The demo isn’t just a way of sharing what you’re doing. It’s also a way of learning from your stakeholders. Some teams streamline their demos by creating a brief video recording. It’s a clever idea, and worth trying. But it doesn’t give you as much feedback. Be sure any experiments you try include a way to confirm your ability to complete work and learn from your stakeholders.

Some teams reverse the demo: rather than showing stakeholders what they’ve done, they observe stakeholders as they try the software themselves. This works best in an in-person setting. It also works well when you have multiple in-person teams: you can put them all in the same large room and conduct a “bazaar” or “trade show” style demo, where stakeholders can move from team to team and see their work.1

1I learned about this approach from Bas Vodde. The “bazaar” approach is loosely based on the “science fair” technique discussed in [Schatz2004].

Share your thoughts about this excerpt on the AoAD2 mailing list or Discord server. Or come to the weekly book club!

For more excerpts from the book, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.