Course Info
Team Project
Sprint Format

Sprint Format

During active development, you will be working in 2 week cycles (aka sprints). All sprints share the same basic structure:

Design of an iteration
Sprint activities span two weeks, and always end with a user demo.

Step 1. Kickoff

Your team should have an initial meeting to set your goals for the sprint, and assign issues.

  • Determine what you should be working on.
  • Assign issues to everyone on the team, suitable to cover the required features, plus any other features that you wish to implement. As a team, you should have enough capacity to complete the required tasks while still making progress on other advanced features.
  • Make sure that there is enough detail in each issue for the team to proceed.

When assigning work, make sure that you address feedback from the previous Demo (or Project Proposal) if you have any.

How do you decide what to work on?

  • Review specific requirements. Consider everything you need to have in-place to deliver required functionality. e.g., “implementing the UI” might not sound too difficult, but it probably requires that a number of other features are implemented first.
  • Address high-risk items. You should be trying to reduce risk by either “figuring out” how to implement the risky items, or changing your designs to remove the risk. You can do this at every stage.
  • Address long-lead items. Some items will be complicated and require delivery across multiple sprints! e.g., you are unlikely to completely implement your database interface + authentication + serialization in a single sprint! Decompose these problems and discuss how to deliver over a longer period of time.

Step 2. Implementation

Everyone works on their issues! You should do this in whatever way you agreed in your initial meetings.

  • Each team needs to meet twice per week. This can be in-person or online.
  • Each person works on the work that they’ve been assigned.
    • Use feature branches in Git and merge back to main when done.
    • Add comments to issues and close them as work is completed.
    • Track your work in a developer journal.
It’s critical that you follow the steps in the Best Practices > Manage Your Work to stay organized. It’s also essential in team planning activities to have the project information up-to-date!

Step 3. Code Freeze

You should have the following completed before the demo time.

  • All issues in GitLab should be up-to-date i.e., comments added and issues closed if completed.
  • Code must be committed and changes merged back to the main branch. This includes implementation code and associated unit tests (which should all pass).
  • Choose one computer to use for the demo. Make sure that your application runs correctly on that system. You will use a single computer for the demo.

You should also add a link from your README file pointing to the Milestone for this demo in GitLab i.e. Plan > Milestones link.

Step 4. Demo

Demos are always conducted in-class, during a Friday lab.

  • You will only demo to your TA and (occasionally) the instructor.
  • Each team will have a scheduled time for the demo. You will only have 15 minutes, so you will need to be prepared and efficient!

See the individual demo pages for details on what you need to have completed. Each demo has specific requirements that we want to see (and will grade).

  • It’s critical that you implement the requirements for each demo, since they are worth marks. Your TA can provide feedback on other things, but the requirements represent the minimum that you need to have completed.

The demo should be run like this:

  • Bring up the list of issues completed (Plan > Issue Boards) and describe what was accomplished during the sprint.
  • Each person on the team should demonstrate what they personally did. We want to see working functionality and passing units tests (not source code!)
  • You are allowed to show GitLab documents, diagrams, unit tests results, or other work that helps to demonstrate what you accomplished.
For full marks, demos need to be done on a single computer, with code running from the main branch. You should be able to run your application from the IDE, or using ./gradlew run!

Step 5. Final steps

Meet after the demo. Make sure to write down any feedback you received from the TA! You should log issues GitLab, or add comments added to existing issues where necessary.

There is no formal submission required for your proposal, since we will grade what is in your GitLab repository. Please make sure that everything is committed and complete by 6:00 PM on the listed time and date.

You should NOT be making drastic changes between your demo and the submission time. Critical changes are acceptable e.g., fixing a configuration issue so your application will launch, but you should not be adding in new features or making drastic changes from what was shown during the demo.