Sprints & Demos
Most of the term will be spent iterating on your project. Sprints start after the project proposal. You will be working in two-week iterations, called
sprints. Over a two-week period, you will have a kickoff meeting, do some work, and finally demo that work to the TA.
|Week 1||Day 1: Kickoff||Day 2: Daily standup|
|Week 2||Day 3: Daily standup||Day 4: Demo|
You need to write down meeting minutes every time that you meet. These are very short. You can use either the meeting minutes or daily standup template if you wish. You can also use any other format that you wish as long as you store them in your GitLab project and include all of the information on the templates.
Day 1: Kickoff
The first day is the official
kickoff, where your team collectively decides what you want to include in the sprint. Your primary task in this meeting 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.
- 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 issues logged and assigned to the team, representing the work for this sprint.
- You should have meeting minutes documenting who was present, and any major decisions made by the team during the meeting.
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.
You should have meeting minutes documenting who was present each time you meet, and any issues that you encounter.
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.
Sprint attendance is required, and everyone on the team must attend the in-person demos. See course policies for more information.
Failing to attend a demo will result in a grade of zero for that component IN ADDITION to any penalty to your participation grade. Under exceptional circumstances where you MUST be absent e.g. coop interview, documented illness, you MUST discuss this with your team and the instructor ahead of time for any consideration.
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 issues for the sprint should be updated
- Completed issues should be closed in GitLab with details on what was done.
- Code changes need 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 also have readied a software release which details what you accomplished and has a link to an installer.
What does the demo look like?
- Your demo will be informal and last about 10 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 discussion).
- The person who developed the feature should demo it.
- All demos need to be run from the same machine.
Outcomes from this meeting:
- The TA will assign a mark and your grade will be returned the week after the demo.
- See assessment for marking guidelines.