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) is 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 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 possible 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 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 way 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.