# Product Releases

Your development iterations will be organized into sprints. Each sprint is a two-week period where you will plan, develop, and release a new version of your software. This section describes the process you will follow during each sprint.

# Planning

The first day of the sprint is a planning meeting, where your team collectively decides what you want to include in this release. Your primary task in this meeting is to choose items from the Product Backlog (unassigned issues) and assign them to the sprint and to individual team members.

Here are some suggestions on how to approach this:

• Address feedback from the previous sprint (i.e. comments from the TA or instructor).
• If you had anything outstanding from the previous sprint, discuss it and determine how you should proceed (do you need to change your approach, or do you just need more time?)
• 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 issues logged and assigned to the team, representing the work planned for this sprint.
• You should create meeting minutes documenting any major decisions made by the team during the meeting.

# Working Days

There are "open" days on the schedule. There are no scheduled activities on these days, but you are encouraged to come to class and work on the project with your team. Course staff will be there to assist and answer questions.

On days when you work on the project, you need to track your work.

1. If you are in-class, sign the attendance sheet. Remember that there are participation grades for attending!

2. You are expected to meet with your team at least twice each sprint. Team meetings must be documented, and stored in your project Wiki.

   • Meeting minutes need to include: date, who attended, what you worked on.
   • See https://git.uwaterloo.ca/cs346/public/1249/templates for a sample of a meeting minute format.
   • Store meeting minutes in your project Wiki as well.

3. Issues must be updated by the person working on the issue. You are expected to document your work indicating what was done.

   • The issue list in GitLab should always reflect the state of the project.
   • Issues always stay assigned to the person responsible for that work. If you help out a teammate on their issue, you should add a comment to the issue indicating what you did - do not reassign issues after the planning meeting.

# Software Release

At the end of the sprint, you need to follow the software release process. This will produce numerous artifacts, including releases notes and software installers.

Once complete, follow the process below to submit it in Learn.

# How to submit in Learn