Project Activities

This section describes the project activities that you will perform.

1. Project Review

In the first few weeks, you and your team will choose a project, define requirements, and discuss design issues.

Around the end of week 4, you will have a project review meeting with a TA to discuss your project.

• You should have early project decisions made by that time, and requirements should be logged in GitLab.
• You do not need to submit anything! This is an informal presentation and discussion of your project to ensure that you have done the required preliminary work. You should be able to answer all of the points in the project review checklist.
• See the project review checklist (pdf, docx) for marking guidelines.

2. Sprints

Most of the term will be spent iterating on your project. You will be working in two-week iterations, called sprints, that have the structure outlined below. Over a two-week period, you will have a sprint-kickoff, do some work, and finally demo that work to the TA.

Your first sprint will start the week after your project review. The last sprint will complete in the last full week of the term. See the schedule for exact dates of each sprint.

Day 1: Kickoff

Although not formally part of the sprint kickoff, you can expect the first day of the sprint to open with a 1-hour lecture by the instructor. This lecture will cover core technical topics needed for that sprint, and aim to provide some guidance on how to structure your work.

The remainder of the first day is the official sprint kickoff, where your team collectively decides what you want to include in the sprint. Your primary task in the kickoff is to choose items from the Product Backlog and assign them.

Here’s some suggestions to help you determine what to do during the sprint.

• The sprint guidelines page has suggestions for each sprint. You are not required to follow this path, but use it as a guideline.
• Address feedback from the previous sprint’s demo. You may have received feedback from the previous sprint. Treat suggestions from course staff as important - they represent your customers!
• Address high-risk items early. This gives you time to pivot if needed, and also helps prevents you from investing too much time in a path that ultimately won’t work.
• Look for blocking issues: items that are critical for other systems. Examples of this might be the class structure for business objects (e.g. data classes) that are used by other features.
• Do NOT assign more work than you think you can do.

Outcomes from this meeting:

• You should have all issues logged and assigned to the team, representing the work for this sprint.
• Meeting minutes should be recorded using the meeting minutes template (pdf, docx) and stored in the /meeting-minutes directory in your repository.

Day 2/3: Standup

These are “working days” where your team gets together and does the actual work towards the sprint’s goals. You are expected to work in-class together; the instructor and TAs will be available to help you out.

Outcome from these meeting:

• Meeting minutes recorded using the daily standup template (pdf, docx). Store them in the /meeting-minutes directory in your repository.

Day 4: Demo

The last day of a sprint is demo to the course staff of what you’ve accomplished during the sprint. This is a checkpoint of sorts, where we can provide feedback and make suggestions.

This is what you should have completed before the demo:

• You should have recorded meeting minutes for every team meeting prior to the demo.
• The core requirements for the sprint should be completed - see sprint guidelines for details.
  • Completed issues should be closed in GitLab with details on what was done.
  • Completed work needs to be committed and merged back to the main branch.
  • You should have unit tests that cover the features that you have completed.
• You should have readied a software release - see project artifacts for details.
  • You should have release-notes for this release in your GitLab project, which documents the release.
  • You should have an installer for your application, which you use for the demo. You should NOT demo from IntelliJ.

What does the demo look like?

• Your demo will be informal and last about 15 minutes.
• Using an INSTALLED version of the application, demo each completed feature, and answer any questions. (Your issues list in GitLab is a great way to drive this disccussion).
• The person who developed the feature should demo it.
• All demos need to be run from the same machine, using the build from the software release.

After the demo, your team should discuss how things went, and what areas could be improved. Reflect on ways to improve your development process so that you can be even more effective in the next sprint.

Outcomes from this meeting:

• Open issues from this sprint should be moved to the product backlog (i.e. unassigned from the sprint). They can be discussed again in the next sprint kickoff.
• Reflections from the team should be recorded in your meeting minutes using the meeting minutes template (pdf, docx) and stored in the /meeting-minutes directory in your repository.
• The TA will assign a mark and your grade will be returned the week after the demo.
• See the sprint demo checklist (pdf, docx) for marking guidelines.

3. Final Submission

There is also a final submission due at the end-of-term. This will be an offline evaluation, where we consider all completed features, how well they work together, application design, source code structure and so on. Everyone on the team will receive the same grade for this component.

• We will grade this after the end of the term (and after the final sprint/demo has been presented).
• See project artifacts for more details on what you should have completed.
• See final checklist (pdf, docx) for marking guidelines.