We’ve all seen the flow of a sprint and the flow of a sprint planning meeting. What we have yet to see in our little Agile adventure is what exactly is a sprint demo meeting and what happens during said meeting.
A typical sprint demo meeting is usually held on the last day of the sprint, which in most cases is a Friday. The reason behind this is probably to get your weekend to a great start because of all the hard work you’ve put in these last two weeks and because of the praise you will undoubtedly receive for your work.
Of course, the reality is different and the team will find itself in a state of constant panic for a variety of reasons:
- the server is not starting
- the internet connection is down
- you’re desperately trying to add in some late extra touches to a user story
- nothing seems to be working
Now there are two possible scenarios for you, our hopeless optimist not-yet-jaded developer or tester. The most likely one is that you are NOT the presenter of the demo (you know, the scapegoat that will receive all the hate if or more likely when something goes wrong) and you don’t have to care about it. Worst case scenario is you have to answer one or two questions with regards to your user stories. Be sure not to zone out during those questions though. Timing has to be right.
The other possible scenario is that you have to be the presenter of the demo. That means that you have to know the details about every user story that the team resources…ugh sorry, I mean members…worked on during this sprint in order to know what you’re talking about during the meeting. Now unless you happen to be the team leader or Scrum master, it’s very unlikely that you’ll draw the short straw. However, every now and then your Line Manager will come up with this brilliant idea that you need to improve your presentation skills and be more proactive in your corporate life and volunteer to present the demo.
Nevertheless, the dreaded hour is upon you. As the Product Owner and several other people with vague titles and even vaguer responsibilities join the meeting, you go over your notes one last time before the meeting.
The next hour or so is filled with you showing the client the marvelous work the team has put in. Of course, may the Deities have mercy on your soul should the application not look good, because no one really cares about the inner workings of your abused app unless it also looks good. So be sure to prepare the area where the sun never shines for a truck load of reproaches with regards to this. Also, from time to time, beware of the silent listeners from the client side. You know, the ones that join, say hello and NOTHING else for 95% of the meeting, only to pitch in at the end with a bunch of stuff they didn’t like, ranging from looks and functionality to requirements that were never discussed and somehow appeared in the last 10 minutes.
And as these discussions role on, you find yourself wishing for some good old fashioned laser vision, so you could cut a hole in the wall and be gone when no one’s looking. Alternatively, you wonder if there is a parallel Universe where all this makes sense and you actually enjoy slaving away as someone else’s amusement, all for the great realization of never seeing your work used by more than 100 people, since the application you’re working on is probably an internal one which your client decided to externalize because it was cumbersome and everyone else at the client’s company is busy working on applications and inventions that actually matter in this life.