AoAD2 Practice: Stakeholder Demos

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 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.

Stakeholder Demos

Product Managers, Whole Team

We keep it real.

Agile teams produce working software every week, starting with 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 they need. They’re just what they sound like: a demonstration, to stakeholders, of what your team has completed recently, along with a way for stakeholders to try the software for themselves.

The feedback comes in multiple ways. First, the obvious feedback: stakeholders will tell you what they think.

Incremental Requirements
Real Customer Involvement

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 the team is 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 demo is also a “rubber meets the road” moment for the team. That gives you good feedback about your team’s ability to finish their work. It’s harder to fool yourself into thinking work is done when stakeholders expect a demo they can use.

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. Be consistent: 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.

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 they won’t be able to stretch work into the next iteration.

Feature Toggles

In addition to the demo presentation, provide a way for stakeholders to try the changes on their own. This might take the form of a staging server or—if you’re using feature toggles—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 demo meetings, continue to share demo software that stakeholders can use every week, or at least every iteration, if your iterations are longer than one week.

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, this will be 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.

Incremental Requirements
Real Customer Involvement

Product managers often request that developers 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.

Anybody’s who’s interested may attend the demo. 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 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.

If there are no interruptions, the demo itself should only take five to ten minutes. Questions and feedback can stretch that to half an hour. 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.

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.

Once everyone is together, briefly remind 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 that stakeholders 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 user... click “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.)

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 story 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 to explain.)

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 2-D 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 followup for more feedback or questions.

Two Key Questions

At the end of the demo, leave time to ask your executive sponsor two key questions:1

1Thanks to Joshua Kerievsky of Industrial Logic for introducing me to this technique.

  1. Is our work to date satisfactory?

  2. May we continue?

These questions help keep the team on track and remind your sponsor to speak up if they’re unhappy. You should be communicating well enough with your sponsor that their answers are never a surprise.

Your sponsor isn’t likely to attend all demos, although that’s preferable. You can increase the likelihood of them attending by keeping the demo short. If they don’t attend at all, a team member with product management skills should conduct a private demo, including the two key questions, at least once per month.

Your sponsor may answer “no” to the first question, or they may be clearly reluctant as they answer “yes.” These are valuable early indicators that something is going wrong. After the demo, talk with your sponsor privately and find out what they’re unhappy about. Take immediate action to correct the problem.

Sometimes your sponsor will be unhappy because they expect you to be more productive. The “How to Improve Capacity” section describes how you can do more in the time available.

In rare cases, your sponsor will answer “no” to the second question, meaning that you can’t continue. You should never hear this answer—it indicates a serious breakdown in communication. It’s good to ask anyway. It reminds your sponsor to tell you when they’re unhappy.


If you do hear a “no,” you’re done. Meet with your sponsor after the demo and confirm that they want the team to stop. Let them know that you’re prepared to release what was demonstrated today and you’d like a final week to put the code into mothballs. (See the “As-Built Documentation” section.) Try to find out what went wrong, determine if your team will disband or take on a new purpose, and schedule a milestone retrospective that includes your sponsor, if possible.

Be Prepared

Done Done
Visual Planning

Before the demo, make sure all the stories being demoed are “done done” and you have an installation of the software—on a staging server, perhaps—that includes them. Make sure attendees have a way to try the demo for themselves.

The demo itself doesn’t need to be a polished presentation with glitzy graphics, 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.

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 increment, your next 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 and 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 time, the 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 and 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 user interface 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 back-end 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 one particularly engaged individual—you can ask people to hold further questions until after the meeting.

If you have a lot of questions, it’s okay to plan for meetings longer than 30 minutes, especially in the first month or two. Your most important stakeholders often have a lot of demands on their time, though, so it’s better to plan short meetings so they attend regularly.

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 have the on-site customers 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 the 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 don’t have time for them—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, the 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.


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.

Inability to demo is a clear danger sign.
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 their 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 executive sponsor is 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 sponsors 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, to check in with your sponsor, and to learn from your stakeholders.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, 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.