Purpose

Your in-progress project demonstration “assignment” is intended to be relatively short and informal. It’s a mechanism to:

• Encourage progress through accountability and deadlines. As much as we hate them, deadlines do push us to make measurable progress and are part of creating SMART goals. With a demonstration due during most sprints, we will hopefully avoid a last-minute rush at the end of the term.
• Practice the process of preparing for a demonstration and doing some public speaking rehearsal. 
• Get feedback early on whether or not the project work and accomplishments are what the instructor is expecting. It is a way to avoid surprises at the end of the term. 
• Learn from other teams.  Most of your projects have similar components, and you can learn from the successes and struggles of other teams.  

Demonstrations are usually the responsibility of the Product Owner. They might not be the one who does the actual demonstration, but they usually manage the process of scheduling, getting ready for the demonstration, deciding what features will be shown during the presentation and guiding the discussion with the stakeholders to determine if the features are meeting expectations and set goals for the next sprint.

Demonstrations will be semi-formal and (ideally) synchronous.  That means that each team needs to join the scheduled class meeting time on Fridays.  Your group will  “take the floor” and elect one member to share their screen while the entire team joins in on the audio presentation  in order to give the class an overview of what progress you have made during this sprint.  When you are a member of the audience, think about what questions you have about the presenting group’s project.  At the end of the presentation, raise your hand (if the software allows) in order to be called upon to ask your question.  Feel free to ask technical questions, particularly if that group is doing any work similar to yours …. they may be able to help you.

If necessary, your team may record a video or do a voice-over of slides that you will share in PioneerWeb.  Make sure that everyone in the class will be able to access both the slides and the audio!!!  (This has been a particular problem when using Google slides ….).  I recommend that you test your presentation with someone in the class (not on your team) to be sure that they will be able to see and hear your recorded presentation.

What to Prepare

1. If this is your demo for Sprint 1, describe your community partner, their mission, and the purpose for your project.  During the first demo, expect to tell the audience details about what the desired app will do, and remember to give a brief overview again in subsequent sprint demos.  If you are starting up where another team left off, you should talk about what you have learned about the state of the project and the user requirements so far.  It is perfectly acceptable to take your time to understand what was done prior to your team before you start adding to the code, tests, or documentation!!
2. Present a list of user stories or features that you targeted for the sprint. This can be done by showing your backlog and pointing to the set of cards (or equivalent) that are in progress or recently marked “complete” during this sprint.  
3. If you have already done a demo for your community partner, what feedback did they have for the team? What did you think of the process of showing your work to stakeholders in this way? 
4. Show the current version of the product, if applicable,  and point out/talk about – as much as possible – what changes you have made to get to this point. OR you might be at a stage in which it is easier to talk about what tests you have written and why. OR you might need to talk about the “less visible 2/3 of the project” …. which is the bug squashing, error handling defensive programming, or security improvements that are hard to demonstrate but essential in a product that will go live soon. For early phase projects, your first few sprints may center around discussion of the user requirements and software constraints.  You might be showing us user interface mockups or example, non-working, HTML pages/views or showing sketches of planned model UMLs.  
5. Talk about what challenges your team has encountered, what strategies you are using to solve problems, and show off what you have done. 

Plan for this to be fairly short. 15 to 20 minutes should be more than enough time for an interim walkthrough of your app. 

Ideally, everyone in the group should talk, at least briefly.  You MUST be present at the demo to receive credit for this assignment, unless previous arrangements have been approved by your instructor. 

You may decide to show us a live demo of the software as it is running on a computer or the Heroku server.  OR you can decide to use a PowerPoint type of presentation software and include screenshots of the app.

Expect technical difficulties!!  We have so many apps that need to work together that we can assume that there will be times when a presentation just doesn’t work.  Practice in advance as much as you can, be ready to skip your turn as your group tries to troubleshoot an issue, and when all else fails, be ready to give a quick summary without your app or slides.

What to Hand In

Nothing.