Sprint Demo - are you involved?


As part of a development team, I was wondering how to improve the demo presentations (Scrum). They are shared with other teams, so it’d be great if they were both informative and entertaining. (Now they are informative.) I’ve added animations recently (as intro/summary). Do you have any recommendations or concepts? PS. No, karaoke is not a clever idea. :wink:


I guess it depends on your role and creativity. I work on a workflow product. Our lead developer has been known to secretly log in and change the color scheme for the product on the day before a demo so that it fits with the holiday (red/white/blue before July 4th, red & green before Christmas).

One year, he turned it red and pink for Valentine’s Day, and then renamed the product and some of the pages to “Love Connection.” Then he proceeded to create a workflow (using our new functions) that was like an online dating site. So instead of processing print jobs, the workflow was basically a decision making engine to help someone find their “perfect match.” It was a bit of work, but it was wildly entertaining. :smile:

Other times, our scrum master or other team members have actually recorded the demo in advance-- so they could do them in their best “radio announcer” voices and work up a little routine.

All of those things might be a little much to do for every demo, but changing it up on occasion can be fun.


I think just getting involved is an accomplishment.

Every now and then, I’ve set up doc for a procedure that nobody else has demo’d.

At that time, like any other dev, I’ll share my screen and run through my procedure.


Thanks, this sounds fun :wink: I like the idea to add a holiday touch to a demo. Will try that and tell you how it works out.


Why an accomplishment? I’m wondering.
Does this mean you have to deal with the issue of “us vs them”?


No, not at all.

In an ideal sprint demo, deva will demo their work, and we’ll say either the docs are complete, or will be in review shortly.

The “accomplishment” comes typically in one of two circumstances:

  1. We find something (usually related to deployment) that needs doc
  2. We do our own dev work on something (typically something other than doc tools) and show that work