In an agile development process, you typically launch new features into production every 2-3 weeks. Before launch, it is important to ensure that all stakeholders get to know about the new features to be released. It is especially important for Customer Support, Training, Translators, Sales etc. to get to know these new features before customers get their hands on them. I have found the best way to do this is via a sprint demo. When I have organized these demos, here are three guidelines I have followed:
- All key stakeholders have been invited – marketing, sales, product, customer support, qa, …..
- The demo is held a couple of days before the release – stakeholders should have some time to react to the new features and also engineering – in case there are small changes that need to be made (textual changes or other very minor changes).
- The demo is done by engineering. This is very key for me. Engineers toil hard to get everything done and it is their work that is being shown in the demo. Given this, they are the best ones to show case what they have built. It also ensures that everything to be released is completed before these demoes.
What are your experiences? How do you do your sprint demos?
Software Product Manager by Gopal Shenoy 
Agree with Avijit on point 1, sprint demo is not for all stake holders to ensure that sprint met it’s criteria, it is Product Manager’s job. PM can then later do demo with other cross functional team and take the feedback. However, I agree with author on part that demo should be done by engineering team to rest of team members including product manager. This makes them feel good about the work that they have delivered, and makes them motivated for furhter work. Main objective of sprint demo in my opinion is to accept user stories being completed as per acceptance criteria that have been set before sprint started.
I agree that it’s crucial to bring all stakeholders on the same page when a feature is developed. Usually in an agile environment, stakeholders know what is expected. However, there is always a potential for change once the feature is developed and the sprint demo session can be used to brainstorm.
My experience:
1. When a change is suggested, often it requires some discussion and a spring demo may not be right place to have those conversations. I usually take action items and have a follow up meeting for discussions. It also hps to assign owners of the action items in the sprint demo meeting for accountability.
2. I think, it’s the responsibility of the Product Managers for the demo. Product Manager is represetative of customer community and by doing the demo, it ensures that the product is customer ready. Ideally, the acceptance of the features should happen before demo which is done in collaboration with dev and qa.
3. Product Managers should also demo the product to the Cross-functional team outside the sprint demo to ensure the meeting of expectations. This kind of demo sessions can also bring food for thoughts for future release or product roadmap.