Mid Sprint Demo
In every project, each story goes to the product owner or stakeholder for completion after the testing cycle. When the story is ready for PO(Product Owner) review, we can record a 2-3 mins functionality demo and present it to the product owner. If the product owner feels that story is completed as per acceptance criteria, he/she can mark the story as completed. If PO or stakeholder finds any scenario missing, we can cover within the sprint itself. The benefit of doing this practice is that we can avoid carrying the story forward to the next sprint and can deliver a 100% sprint.
When we do only one demo at the end of the sprint and if PO or stakeholders finds any scenario missing, we have to carry forward the story to the next sprint to cover that scenario. By following the above practice, we can avoid such scenarios.
In most of the sprints, few stories could be ready for PO review by 5th or 7th day. We can have a 30 mins call on 5th or 7th day to show demo for those stories. We can have a final demo on Demo day(10th day). This would really help to deliver a 100% sprint.
How sprint demos impact QA
Sprint demos can have a positive impact on the quality assurance of your product, whether or not you have a dedicated QA team at your company or not. A good sprint demo session involves teammates asking questions and raising concerns. These interactions can ultimately lead to improvements in the product, and sometimes a complete shift in direction on how something is being built. As someone shows their work, the rest of the room is able to consider potential risks, which can be discussed and then addressed in upcoming sprints.
Sprint demos prepare others for what’s to come
When doing team-wide demos with cross functional roles, marketing and support are able to get up to speed on what’s changing. This is a great way to bake in a handoff process with your marketing and support teams. From here, marketing and support teams can prepare content, messaging, and updates to existing documentation. Support is also now in the loop on how an upcoming change or feature will work so they can truly “support” the feature.
Key aspects of the Sprint Demo
Be present and engaged: The Sprint Demo is the Development Team’s opportunity to interact directly with stakeholders of the product. It is important that members of the Development Team put their best foot forward, so take at least a little time to prepare.
Talk in terms of business value: Stakeholders want to know that the Development Team understands the business impact of what they are building. The more they speak in language familiar to stakeholders while demonstrating the product, the more likely the Scrum Team is to unlock a treasure trove of valuable business context and feedback crucial for the product’s success.
Avoid reacting to feedback or questions defensively: The Development Team has worked hard and may have an immediate reaction to tough feedback. Stay curious and ask open-ended questions and try your best to not become defensive if stakeholders do not immediately connect with what you are doing or building. As soon as you feel overly defensive, you’ll miss the gems of insight stakeholders can provide.
Work on the Feedback: A member from the development team should take notes on the feedback provided by the customer. After the demo these notes should be circulated within the team and assigned action item owners (if required) for the feedbacks to add value.