CS 346 (W23)
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Project Activities

This section describes the project activities that you will perform.

1. Requirements

In the first couple of weeks, you will spend time determining the project requirements. These are a combination of:

  • Features from the requirements specification.
  • Suggestions from user interviews that you wish to include.
  • Other features that you brainstorm with your team.

At the end of the requirements phase, you should have each requirement logged in GitLab as an issue (where an issue is a record of the work to implement that feature). See artifacts for more details on how you will use GitLab.

2. Analysis & Design

In the second phase, you spend time examining the technical requirments and refining your description with implementation details. We will discuss how to do this in-class.

At the end of the analysis & design phase, you should have added issues describing your non-functional requirements.

3. Development

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.

Sprint Wed Fri
Week 1 Day 1: Kickoff Day 2: Daily standup
Week 2 Day 3: Daily standup Day 4: Demo

Each of these represents activities that you and your team will do together in-class. We will have four sprints through the term, and you will repeat this cycle for each sprint.

By the end of sprint 4, you will have a completed application and all of its supporting artifacts!

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 that you should follow. You will lose marks for deviating too far from this plan.

  • 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:

  • Detailed issues logged and assigned to the team, representing the work for this sprint.
  • Meeting minutes recorded using the meeting minutes template (pdf, docx) and stored them in the /meeting-minutes directory in your repository.
This meeting is the ONLY time when you are allowed to add items into the sprint. Anything “new” that you discover mid-sprint should be assigned the Product Backlog and deferred.

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. Remember to record meeting minutes!

Outcome from this 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. See the Sprint Demo Checklist on the Assessment page for grading details.

This is what you should have done 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 release-notes for this release in your GitLab project, which documents the release.

  • You MUST have an installer for your application, and demo using the installed application. You should NOT demo from IntelliJ.

What does the demo look like?

  • Your demo will be informal and last about 15 minutes. Typically you just demo to one TA or the instructor.
  • They will ask to review your features for this sprint. Using an INSTALLED version of the application, demo features one at a time, and answer any questions. (Your issues list in GitLab is a great way to drive this disccussion).
  • Note that the person who developed the feature should demo it.
  • All demos need to be run from the same machine and the same installation.

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.
Keep in mind that you may not complete everything that you planned during the kickoff! Estimating time and effort is difficult, so you might miss a goal, especially in early sprints. See this as a learning opportunity, and a way to improve your time estimation skills in the next sprint!