Problem: Business reviews related to sprint demos needs planning and preparation.
A sprint demo is a formal activity where the customer evaluates the delivery. It is not uncommon that the demo is done for an unprepared audience. The reviewers must be prepared in order to avoid waste of effort and risking ending the demo with a non-decision, or just saying yes to the delivery.
Solution: Prepare your review questions BEFORE the sprint.
It is the product owner and friends who needs to make the decision about accepting or rejecting the delivery. This means that they need to gather as much information as possible to ensure that the decision is done on the right foundation – This calls for preparation, before and after the delivery.
This is what I usually recommend as preparations for a demo:
- 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.
Happy testing!
/Nicolai
No comments:
Post a Comment