# M4-M6: 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.

# Sprint Structure

# 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.

# Development

There are "open" days on the schedule (usually half of Wed, and all day Fri) where 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.

The instructor will always be present in class. TAs will normally be in class on Fridays.

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 gitlab/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.

# Demo to your TA

On the days where you have a software release due, you need to meet your TA in class for a demo.

• You will have a 15 minute timeslot, dedicated to your team and TA.
• Your demo should be roughly 10 mins in length. You are ONLY showing this to your TA (and possibly the instructor).
• You are expected to explain to your TA what you accomplished and show the features working. Each person should demonstrate what they completed (do NOT demonstrate code, we want to see working functionality). The TA will likey have questions and possibly advice on your next steps.

# Software Release

You also need to follow the software release process to produce an installable version of your application and other required documents.

# How to submit