PM Articles > Kent McDonald > Demos Are for Getting Feedback

Demos Are for Getting Feedback

by Kent McDonald

My guideline: Do you need more feedback? Do a demo.

I get the opportunity to talk with many teams and product owners about their software development efforts. A common thread of questions tends to be around demos (also known as sprint reviews, showcases, or any number of other terms).

Before delving into specific questions, it may be helpful to address what value demos provide. Demos exist primarily to get feedback from your stakeholders when you can't get feedback from them during the course of a sprint.

Note I didn't say that they are to get feedback from the product owner. If you are truly doing your job as a product owner you are providing feedback along the way so that your team has a shorter feedback cycle and has an opportunity to act on the feedback you provide within that sprint. If you (as a product owner) are surprised during a demo, something is wrong.

With that thought in mind, here are some frequently asked questions answered from a product ownership perspective.

Should we always do demos?

I am going to answer this question with a question. Should you always look for feedback?

Ok, a little snarky I'll admit.

If you as a product owner have already had an opportunity to provide feedback to the team during the course of the sprint, and you were able to get feedback from the key stakeholders interested in what the team was working on, you probably don't need a demo. You already have the feedback, so now you may just be doing the demo because that's what teams do at the end of sprints. Unless of course you are using a flow approach, in which case you'd better be getting feedback after every item is done.

My guideline: Do you need more feedback? Do a demo.

What if we don't have stakeholder (customer) visible stuff, do we still do a demo?

Some teams (teams working in a mainframe environment or teams with a LARGE, complex code base come to mind) may find themselves working on stuff that provides value to stakeholders or customers, but is not very demonstrable. If you find yourself in that boat, think through what would be a good way to get feedback on the work you did. Mainframe teams I worked with used before and after screen shots. Admittedly not very sexy, but it was sufficient to get the point across and to generate conversation and encourage feedback.

My guideline: Do you need more feedback? Do a demo. Figure out how to show something meaningful to get that feedback.

Who should attend demos?

It's good for the entire team to attend. Is this some "agile mandate"? No. (There is really no such thing.) It's helpful for the entire team to hear the feedback they are getting from stakeholders (customers) so that they get a better understanding of what stakeholders are looking for. They may also pick up on something that other team members don't.

It's also helpful to consider which stakeholders have an interest in the stories the team is working on during the sprint. This is a good discussion to have during sprint planning so that you can specifically invite the people who have a vested interest in the backlog items the team will work on during the sprint. Taking this approach instead of creating a blanket invite to hundreds of people who may possibly be interested in what you are doing some time helps you have more engaged attendees at your demo, and is more respectful of everyone's time and calendars.

If you are working on a software product, identify customers that you would like to include in your demo. You may not include customers in all of your demos, as you may not have something to show meaningful to your customers. (Hopefully that doesn't mean you didn't work on anything that delivered value.)

Remember, whomever you invite, don't make it hard for them to give feedback.

My guideline: Include anyone that you need feedback from and anyone who would benefit from hearing their feedback.

Who should do the demo?

It depends what you are trying to accomplish (beyond receiving feedback that is) and the makeup of your team.

I've seen the developers demo their own stories. This is good if you'd like to get some recognition for the developers and they won't go off the rails and give a 30-minute discourse on the nasty details of how they completed the story.

I've seen analysts or testers do the demos. This is usually the case when they have a strong relationship with the stakeholders and the team feels that they can best convey what the team accomplished.

I've seen product owners do the demos. Same reason as why analysts or testers do the demo. Just make sure you as product owner aren't doing the demo because you don't trust the team to do it properly. This is a sign of a dysfunctional relationship with your team.

I've seen members of the business unit who are working closely with the team do the demo. This is often a method of subtle organizational change management. If other members of a team see someone from their team using the new solution, they likely conclude that it must not be that scary after all and is something they could use.

Perhaps the stakeholders (customers) should do the demo themselves by actually just playing around with the software. In fact, that may be the most effective way of getting meaningful feedback, and certainly something to consider if your solution is in a state that stakeholders could start using.

My guideline: The person who is best positioned to ensure you receive the most useful feedback is the one who should do the demo.

What questions did I miss?

Do you have other questions about demos? Do you have a different perspective on something I suggested above? Do you think demos shouldn't be called demos? Share your questions or thoughts in the comments.

This column appeared previously on Kent McDonald's site Beyond Requirements, and is reproduced here by permission. If you haven't checked out Kent's new site, or his new book Beyond Requirements: Analysis with an Agile Mindset, you're missing out on some great tools that could make your job a lot easier.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Actual this topic has come at the right time when I am planning a sensitization program to electricity consumers about their rights and obligations. What demo do you think I would need to take along to these consumers? I work with Regulator of electricity sector. I need your guidance in this regard

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.