Project

Scrum Teams

Scrum teams and members are listed here [Protected link in Coursys]

Roles

Product Owner. Represents the customer and understands their needs. The PO is the only person on a team who can contact the customer about the product (Dr. Lim, or the real customer via Dr. Lim) and ask questions related to features for that iteration. Anyone may ask about other aspects of the project (such as marking), or raise concerns about the project or the team. Basically, if it's a question the customer should answer, the product owner must ask it. The PO also creates initial issues in GitLab at the very start of each iteration, and maintains these as needed with new understandings. All team members are invited to add/edit as well.

Scrum Master. Organizes group meetings and helps keep meetings on topic. They organize how activities during the iteration are completed, such as team retrospective and project submission. Being the scrum master does not give anyone management powers over team members. This person should help team members resolve conflicts, work with members who are falling behind (though it’s not their job to do the work, nor teach the others what to do, but rather to help keep everyone on the same page and communicating).

Test Lead. Team members should designate one TM as Test Lead. This person will ensure code is tested before sprint end (not necessarily writing all tests, but checking, enforcing and maybe adding). They would also try to read up on Android test methods, bringing expertise.

Team Member. Like everyone else, teams members contribute to delivering working software implementing the required features. All members of the team contribute to discussions, communicate with each other, and share in making decisions.

Git Repo Manager. Helps everyone work with Git and GitLab. This person is responsible for accepting merge requests in GitLab. If code looks good, should be accepted promptly. If code needs improvement, they should give feedback to the team member and have them make additional commits to cleanup the branch before merging. Helps others do code reviews. Might ask someone to review a merge request. May step in to help encourage a positive discussion between two team members with respect to a code review. Need not be an expert in Git or GitLab, but willing to learn and help figure things out.

Project Description

The theme is "Sustainability and Climate Change" and the clients are Dr. Lim & Tilemachos C. along with stakeholders at the City of Vancouver. The project and details will be announced on October 11 during the project kick-off.

Sprint 1: Green Food Challenge Carbon Calculator

Sprint 2: Green Food Challenge Pledge

Sprint 3: Restaurant Guide and Polish

Final Report

Humanoid Robotics Project

The humanoid robotics project will have Dr. Lim as a stakeholder and the project details will also be announced on October 11.

Sprint 1: Robot Messenger

Sprint 2: Robot Media and Login

Sprint 3: Game and Polish

Final Report

Sprints

The sprints are 2 weeks long beginning on October 11, October 25, and November 8.

Each iteration Dr. Lim will post new and/or updated use cases which describe the new functionality that must be implemented. The use cases will be written from the user's point of view with plenty of room for interpretation by your team. This not only simulates how real users will give requirements, but also allows your team some flexibility in implementing features to add your own ideas. If you would like to implement a feature in a way which is contrary to how it is described in the use case, please talk to me (Dr. Lim) for clarification.

Reviews

  • Sprint reviews will be conducted on October 25, November 8 and November 22 for all teams.

  • Working demos (on a phone) should be shown during sprint reviews. Each user story will be validated as complete by the customer.

  • Reviews will take place during Thursday class time on the above dates. Time slots are posted on the home page of this website. The audience will be Dr. Lim or Tilemachos.

Winning Team

  • The top team will be selected to present their application at the City Studio Showcase event on November 30 (AM). Great opportunity to put on your resume.

User Testing Days

You will be provided the opportunity to test your application with SFU students on the following dates:

  • November 14: 11:00-11:50am

  • November 16: 2:00-2:50pm

Thanks to Angelica Kang in FAS Engagement for organizing these user feedback sessions.

Project Details

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 sprint, 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, their individual contribution may significantly affect their grade.

Scrum Team Tips

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, I suggest using 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 Dr. Lim 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 in the commit message (3rd or later line of the commit message). For example, if Able, Betty, and Cassandra work together on code that is checked in as Able, then add the following in the body of the commit message: [PP: betty@sfu.ca, cassandra@sfu.ca].

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 sprint evaluation (confidential section OK). If a student is found to not be contributing well to his/her team then Dr. Lim 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 will get a reduced grade on that sprint (~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 sprint where they did insufficient work). The student will be told how long probation is to last (perhaps the next sprint), 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 previously (notes will be taken to ensure required changes are document). Expectations for all students, especially those on probation, include:

  • 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. Lim for help as required.

  • Commit code changes to Git often (active at least 3 days per week, 1 or more commits on those days); make merge requests early and often (every couple days or less, not big bang!). Commit only high quality, clean code. Don't break the build.

  • Actively seek to complete an equal share of the work and push the project ahead.

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 will be less. The remaining team members must analyze the sprint'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 sprint's use case features and tell the instructor their plan for what they will implement that sprint. It is likely that a 25% penalty will be applied for the failure to function in the team.

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