CompSci 308
Spring 2024
Advanced Software Design and Implementation

OOGASalad : Sprint 1 Implementation

In fact, in an Agile project, technical excellence is measured by both capacity to deliver customer value today and create an adaptable product for tomorrow. ― Jim Highsmith

Working together as a team, collaborate to create your planned API functionality using the priorities decided on by your team to determine what features should be implemented (expressed as Gitlab Issues).

Each Sprint ends with a short in-class demo.

Everyone should expect to complete at least their assigned Gitlab Issues during the Sprint.


GIT: Managing the Project using Issues

As a reminder, each commit is expected to:

Based on the entire team's comfort level with:

Everyone must use this template when creating a Merge Request to integrate code into the the team repository's main branch.

Use GIT to tag your final Sprint commit as Sprint1.


As a reminder, create well named tests for both "happy" and "sad" possible code paths (here are many, many, many examples in case you are having trouble thinking of possible negative tests), such as:

Although you are not required to practice TDD strictly (always writing a test before writing any code) or test sad paths first, you are expected to create tests frequently during the coding process rather than waiting until the end.

To demonstrate that you are following good testing practices, every GIT commit to the main branch that adds new features or fixes bugs (i.e., not refactoring) must include new or updated tests.

End of Sprint Demo Presentation

The Sprint ends with a short in-class demo of your progress that is no longer than 8 minutes. The demo should be given by 2-3 students (that rotate for each demo so all students present at least once). Thus, it is also a chance to practice giving a public demo before the final.

Start by presenting your team's goals for the project:

Then show off the features of your running program:

Conclude by presenting what was learned during this Sprint and the implementation plan for the next Sprint:

To prepare for the demo, the main branch must be frozen, i.e., no new features should be added, for at least 12 hours prior to the start of class to prevent a last minute bug or commit crashing the project. Instead, focus on bug fixes, small refactorings that solidify your design, and building example game(s) to show off.

Submitting your Work

Use GIT to push any materials specifically for your presentation in the folder doc/presentation01 to the main branch, such as code, images, UML diagrams, or written text (using Markdown, Javadoc or a wiki page on Gitlab) specifically to support your presentation.

If you choose to use slides, PowerPoint is discouraged because it is a separate from the code and unlikely to be maintained even if added to the repository. Here are some tools to convert Markdown to a slide style format.

Individual Requirements

When you are not on the team presenting, provide feedback using this form that is focused on the content rather than the quality of the presentation itself (e.g., things you did not understand, felt were incomplete, or ideas you had to improve their work). You are especially encouraged to share things you intend to borrow for your own team (from their project design or features to their presentation style or teamwork ideas).


Good presentations are practiced, presenting features in a planned order and using specific input values, rather than just capturing a team meeting — you do not have a lot of time to fit in everything asked of you. Beyond that, here are some slides to help you get started. The classic demo from 2007 of the original iPhone by Steve Jobs, Apple is something worth studying.

Giving demos is a skill you can work on!