With Scrum becoming extremely popular, sprint planning , sprint demos are every day words. We all know that every iteration, we create potentially shippable product increment and gather together to give a demo to the stakeholders. But there is more to a demo than meets the eye..
A sprint demo - is literally a demonstration of the work we have done in the last 2 or 3 or 4 weeks (or as long as an iteration is). Demos need to be planned. Else there is a good chance they will fall flat and cause a lot of embarrassment. A demo is a place where we are proudly show casing our work, so everything has to be as perfect as possible. Here are some guidelines for making demos better.
1. Who is giving the demo: A team member with good communication skills
2. A script for the demo. - Assigned member needs to know what they are talking about, cover all the developed features in a logical coherent way.
3. Hosted or deployed code: Code has to be deployed and at least bug free during the demo. (we do not want any crashes in the demo)
4. Test Data is to be set up: We do not want data like 'Test ' address with garbled characters etc. It should look consistent and preferably have names / addresses and other items with which the customer can identify with. For example: International names / address from the city where the customer is located etc. etc. Proper translated data in case we are showing multi language implementation etc.
5. A demo rehearsal: this is preferred, so that the entire team can give feedback on the script / data the communication etc, this can be used to improve the demo. This can also be used to check if all the infra is working fine.
6. Logistics : Using a service like webex / conference bridge with dial in phone numbers / time of the demo / duration of the demo / email to all the stake holders on both sides
7. Other softer aspects like the vendor team (i.e. us) being logged in and ready at least 10 mts before actual start. All other members except the person talking being on mute, no background noise etc. etc..
Needless to say this is a time consuming job. So in a 2 week iteration almost 1 day may go in activities around a demo. This means that code has to be built tested and deployed a day prior. This definitely influences the number of stories that can be committed. This has to be done again and again every iteration..
But the advantages are that we are showing working code as project progress. Demos are a time for applause. To get appreciated for the hard work. Also this is a good chance for the team get over stage fright and talk confidently to customers. And when the customer sees the final deliverable there is no surprise element. They have seen almost all of it before..
One of the customers that we worked with recorded the demos and replayed it to their customers to show project progress. Cool right!!
Posts
8 months ago
