Final Presentation for SDL

Each team will present their projects:

• Your primary audience is the other students in SDL. A successful presentation is one that gives good takeaways for the other students.
• Give a small bit of introduction to the project - at most a couple slides - but quickly move on to the demonstration. Knowing what the system does is critical to understanding any other points you make, and seeing the system working is far superior to just hearing about it.
• Other students may know a bit about your project, but they will not remember details. Describe goals and remind students who the customer is.
• The demonstration should make it clear what was implemented this term.
• At some point in the presentation, discuss what is planned for the next term. If it is the last term for the project, discussed future directions.
• Demonstrate key improvements to the system. All demonstration should be based on code in the main branch (or a staging branch, if appropriate) for the project. Demonstrations should be against live servers where relevant. Any demonstration against localhost requires instructor approval.
  • If you do not have a lot completed, talk to your instructor about presenting prototypes, wireframes, or other concrete artifacts that show a basis for future directions. One of the goals is to spark conversation about what features your system should support.
• Discuss CI (continuous integration) activities supported by the team. This would be centered on any pipelines you have set up and automated testing (including coverage metrics), but could include other tools you use for quality control. Testing on GitLab pipelines is required for SWE 3720 but not SWE 3710, but you should be able to at least include a discussion of future testing work in SWE 3710.
• The expectation is that all students will present a share of the material and that all will either help prepare the presentation, at least in review.
  • If there was a midterm presentation and only some presented at it, not all need present on the final presentation. But there should be at least two presenters and all will participate in answering questions.
• Practice your presentation! This includes practicing the demonstration.
  • Once you have a successful system running, make no changes to it on the demonstration system.
  • Your complete presentation should be close to 20 minutes in length. If there are more than 5 teams, presentations will need to be shorter. If you are having difficulty finding material to cover, discuss this with your instructor.
• Discuss your what you learned about process and any identified process improvements. What did you do well, what could you improve, how did you make improvements, what could you improve further? In SWE 3710 (SDL I), discuss how successful you were at applying the Scrum model. In SWE 3720 (SDL II), discuss how you measured the process improvements.
  • Your process improvement discussion should include story point burndowns, but always include discussion with any burndown chart since the chart itself will not convey much to the audience.
  • Feel free to include other process-oriented charts as appropriate.
• If you learned something useful about the technologies in your project or how they impacted your process, be sure to discuss it. This includes technical challenges the team overcame.
  • You should always discuss your system design at a high level in SWE 3720. Since there is a design-oriented presentation in SWE 3710, you may not need to discuss the design and technologies at all in the SWE 3710 final presentation.
• Discuss what the team did well and where they could have improved.

It's important to stay within your time limits. You won't be able to present everything listed above, so pick and chose what you think will be useful. Remember that your goal is to give other students good takeaways. The process improvement discussion is the most likely takeaway for other students, though experience with the chosen technology can also be useful.

A classic order is

1. Problem Statement/Goals
2. Demo, focusing on user-visible improvements made this semester
3. Discussions around requirements, design, technologies, and challenges
4. Discussions around process, process improvement, and CI
5. Future Plans

You can use this order to help guide your development, but do not feel constrained by this order. Organize the material around the points your team wants to make. It is good if different teams have different orders both because that allows you to present your points more clearly and because it is boring if every team follows exactly the same presentation structure. The one requirement is that demos must be early in the presentation to give context to other material.

Do's and Dont's of Presentations

• Do practice at least enough to have confidence in what you are saying.
• Do practice all demos, including making sure all details will work as anticipated at the presentation.
• All demos are to use software from the main branch unless your instructor approves otherwise in advance.
• Avoid overwhelming the audience with information. You are trying to get one or two points across about your successes or failures, not make attempt to make the audience into experts about your project.
• Avoid the sprint play-by-play; be purposeful in what is presented.
• Do not interrupt teammates during presentations. Discuss during preparation, not during presentation.
• Be attentive during the presentations by others: turn off cell phones and computers.
• Be there! Attendance is required at the final presentation, and being late will impact your grade.

Submit a PDF of your presentation as instructed.

Scoring Presentations

Different instructors will evaluate presentations in different ways, but one model is to break the total points into four areas:

1. Strong, early demonstration from the main branch against non-local servers
2. Clear takeaways
3. Practiced; having an appropriate length
4. Good audience member

Author: Robert W. Hasker; last updated Fall, 2023