- Read the back lock items in the release note carefully. Review acceptance criterias and think of positive and negative scenarios, these will serve as a checklist for things that you would like to see in the demo.
- Prepare scenarios for high risk acceptance criterias. Look at daily work and bring some of the cases to the demo, ask for these cases to be used/demonstrated in the demo.
- Review the delivery vs. business process, look for areas where business processes could be obstructed. Ask a lot of questions at the demo, ask for demonstration of these scenarios.
- Put new functionality into context by thinking end to end. Will this have a negative impact on running flows and activities in the system / business?
Remember that the demo is a business review, not a technical review and that is has limitations.
Demo allows a review from the business users checkpoint, it tests the business operability.
Planning and prioritisation is required, not everything can be checked at the demo.
Please remember that the sprint demo is not to substitute more rigorous user acceptance testing. Especially high risk/complexity areas needs much more attention that it could ever get in a sprint demo.