Project

Project Description

In your assigned group of ~4 students, complete three iterations of development on an assigned project. Your group will have a GitLab repository created for you which you must use for development.

Your grade for the project will largely be based on the quality of your app and code, marked as a group. However, portions of your mark will come from your individual contribution as rated by your group members and possibly evaluated by the instructor/TA. At the end of each iteration, you will provide constructive feedback to your group members on their strengths and areas for improvement. Students with poor participation with their team will earn a poor grade or be removed from the group. In cases where students contribute very little, this may significantly affect their grade.

Project Details

Kickoff & Structure

Details... (click to expand!)

  • Team Accountability & Ice Breakers: SM fills in this and submits to CourSys; started during project kickoff.
    • Due Wednesday, Oct 26th by 11:59pm; submitted by team's SM.
  • Project kickoff slides; or in colour
  • Initial project description and initial project meeting done during class.
  • Know which team you are in! Check your email for an message from GitLab about the team name.
  • Suggested steps once you meet your group:
    • Assign the following roles to team members for Iteration 1. Will rotate in later iterations.
      • Scrum Master: In charge of making sure meetings are organized and happen. Make sure team works together, solves problems, and communicates. Ensure there is space during meetings for each person to contribute.
      • Product Owner: In charge of asking the customer (TA/Instructor) for project clarifications. Takes lead in ensuring all required features for the iteration are being developed. Updates GitLab Issues to accurately capture required features/bug-fixes. See this student made video explaining how they saw themselves as a PO.
      • Repo Manager: In charge of helping everyone work with Git/GitLab. Responsible for accepting merge requests when ready, and helping do code reviews. Need not be a Git/GitLab expert, but willing to help figure it out.
      • Team Member: Like everyone else, shares responsibility for delivering required features. No additional duties.
    • Setup how/when you'll meet as a team. See suggestions at bottom of page.
    • Create a group in CourSys named the same as in GitLab. For example, if you are "276-20227 Hydrogen", name your CourSys group just "Hydrogen". Instructor and TA already have access to GitLab projects for marking and technical assistance.
  • Dysfunctional team exercise.


Iteration 1

Details... (click to expand!)

  • User stories for Iteration 1: Lists required features and marks per feature.
    • SM must also submit team accountability and icebreaker exercises; see section above.
    • User stories must be interpreted by the team and there is some flexibility. To change a feature, ask the customer (Dr. Brian).
  • Tutorials and Resources
  • Monday, Nov 7th (11:59pm) Iteration due on CourSys. 5% per day late; max 3 days.
    • You may add a docs/readme1.txt file with any points you'd like to mention to the marker.
    • Create a document docs/roles.txt listing the Scrum roles for this iteration.
  • Wednesday, Nov 9th (11:59pm) Retrospective due on CourSys; worth marks.
  • Wednesday, Nov 9th (11:59pm) Individual Peer-Feedback due on CourSys.


Iteration 2

  • User stories for Iteration 2 for required features and marks per feature.
  • Notes
    • Scrum roles move to a new person. Anyone who previously did not have a role should now take one. May not repeat a specific role.
  • Monday, Nov 21st (11:59pm) Iteration due on CourSys. 5% per day late; max 3 days.
    • You may add a docs/readme2.txt file with any points you'd like to mention to the marker.
    • Update your document docs/roles.txt listing the Scrum roles for this iteration.
  • Wednesday, Nov 23rd (11:59pm) Retrospective due on CourSys; worth marks.
  • Wednesday, Nov 23rd (11:59pm) Individual Peer-Feedback due on CourSys.


Iteration 3

  • User stories for Iteration 3 for required features (marks per feature will be posted about half-way through the iteration).
  • Notes
    • Scrum roles move to a new person. Anyone who previously did not have a role should now take one. May not repeat a specific role.
  • Monday, Dec 5th (11:59pm) Iteration due on CourSys. 5% per day late; max 3 days.
    • You may add a docs/readme3.txt file with any points you'd like to mention to the marker.
    • Update your document docs/roles.txt listing the Scrum roles for this iteration.
  • Tuesday, Dec 6th (11:59pm) Retrospective due on CourSys; worth marks.
  • Tuesday, Dec 6th (11:59pm) Individual Peer-Feedback due on CourSys.
  • [Recommended] You should complete this personal reflection on the project to think about what part of it you like the most. This may help you with job interviews and planning your career. It's not for marks (regardless of what it says!).




Team & Project Support

Expectations for all students

  • Commit code changes to Git often (active at least 3 days per week, 1 or more commits on each of those days); make merge requests early and often (every couple days or less; at least each week; not big bang!). Commit only high quality code. Don't break the build. If in doubt about high-quality code, see Dr. Brian. Clean code conforms to a style guide such as the suggestion one for this course.
  • Attend all group meetings, or explain why that's not possible (Ex: conflicting commitments) and make a reasonable effort to catch-up with group afterwards.
  • Contribute to group discussions clearly, effectively, and respectfully.
  • Respond to all relevant group communications within 1 day at the most. Let team mates know quickly if work will be late or incomplete. Expectations for communication may be set by the teams, such as replying to text messages within 2 waking hours.
  • Agree to reasonable amounts of work, and reasonable deadlines. Make best effort to meet these commitments. Keep team informed about challenges and ask team members and TA/Dr. Brian for help as required.
  • Actively seek to complete an equal share of the work and push the project ahead.

Suggestions for all groups

  • Find a good mode/place to meet: in person, or online chat. For in person, find somewhere that works for everyone (like a team room). For online team chat (video/text), I suggest using Discord or Slack.
  • For meetings, find a time that works for everyone: diverse schedules, 3 campuses, jobs, ... Be on time for these meetings!
  • Respect everyone's mode of communication. Some people don't like to speak up during meetings, but share more thoughts via online chat later. Try to work with each person's strengths. Scrum master to help ensure everyone has their say.
  • Respect team member's task preferences: give everyone a fair shot at working on the part they want to (UI, application logic, ...); but everyone needs to be willing to work on what needs to be done.

Extra group-related support is available for any student or team to draw on. Example support includes:

  • Help discussing challenges with your team to work out a solution.
  • Discuss the situation with me (Brian) to develop a strategy to solve the problem.
  • TA or I can sit in on a group meeting to help the group settle into working together.
  • If some members are not contributing equally, TA or I can highlight to them the need for more high-quality contributions, and the consequences of not participating.
  • TA and I can watch GitLab repositories to ensure a reasonable amount of activity by all group members. I may email teams if I see a lack of commits from some team members.
  • If pair-programming, please put other programmer's SFU ID at the start of the commit message. For example, if Able, Betty (id bty1@sfu.ca), and Cassandra (id csndr@sfu.ca) work together on code that is checked in on Able's computer, then the first line of the commit message should be like: "[bty1, csndr] Connect UI to game model"

Handling Group Problems

If you feel a group member is not pulling their weight and should be considered for probation (see below), include the text "DROPPED THE BALL" in your iteration evaluation (confidential section OK). If a student is found to not be contributing well to his/her team then Dr. Brian will do the following:

  • Email the whole team highlighting the situation. All team members are invited to reply and clarify the situation (such as if the person was working on something not visible in Git).
  • Meet with team as a whole or with individual members. The group problem will be explained, and the required changes in the student's performance will be outlined. Team members can contribute to this discussions by highlighting their needs and views.
  • An under-performing student may get a reduced grade on that iteration (~50%); other team members may have their grades scaled up if their mark suffered as a result of other's poor performance.
  • An under-performing student may be placed on probation; see below.

Probation

A student who is not meeting expectations for contributions to the project may be told they are on probation within their group (often at the end of an iteration where they did insufficient work). The student will be told how long probation is to last (often one iteration), during which time the student must demonstrate that they have changed their behaviour and become a contributing team member. Discussion likely focuses on the details of what went wrong, and what must change (notes will be taken to ensure required changes are document).

At the end of probation, the student's contribution will be evaluated against what they were asked to do. If they have been a productive member of the team, their probation ends with no extra consequences (may still have reduced grade for earlier work). Otherwise, the student on probation will be removed from the group.

If a student is removed from a group then the remaining members of the team will either complete less of the requirements, or their product polish can be less. The remaining team members must analyze the iteration's use case features and tell the instructor their plan for what the team will implement.

Students removed from groups will either get 0 on remaining work, or be required to complete some/all of the work individually. The student must analyze the iteration's use case features and tell the instructor their plan for what they will implement that iteration. It is likely that a 25% penalty will be applied for the failure to function in the team.

Dr. Brian may make adjustments to these guidelines to better address individual situations.

Scaling from Peer Feedback

In general, students will have their overall project mark scaled by between 0.75 (25% penalty) and 1.25 (25% bonus) in accordance with the following graph. This usually has a limited impact on most students' project grades, but does recognize some differences between individual contributions. Exceptional cases will be handled manually by the instructor in order to better ensure student contribution to the project is strongly reflected in individual student grades.
(Attempts to game the system with unfair evaluations will be handled manually, and unfavourably! Pacts with teammates to give each other 20 are likewise disallowed.)

  • Let A be the average of all group member evaluations of you (excluding your evaluation of yourself).
  • A is clamped to be between 10 ("half effort") and 40 ("double effort").
  • A student's score on the entire project will be multiplied by the following weighting factor:
    weight(A) = 0.41667 + 0.0375A - 0.00041667A2
  • This formula gives the desired properties of A=10 gives a weight of 0.75; A=20 gives weight 1.0; A=40 gives weight 1.25.
  • Guide to writing peer-feedback.
  • If you feel that extenuating circumstances apply to you, please submit that in the private notes section of your peer-feedback (above).
  • This approach is based on the work of Bill Gardner.

Peer feedback weight curve