Decision-Making Procedures

• Any UI choices or something that could be considered a functional requirement (or otherwise materially important to development) should be brought up during stand-up for team discussion.
  • Otherwise, for the sake of efficiency, it will be left to the discretion of individual team members to decide whether some decision warrants input from others.
• In case of conflict between two competing choices:
  1. Refer to documentation.
  2. Choose option that client will prefer - or is most intuitive for the end-user (i.e., students).
  3. If the client does not or should not care, choose option that takes the least time.
• Consult the team as a whole for larger decisions open to debate.
• The team may choose to bring up significant decisions for client input and clarification.
• All decisions should be documented within meeting notes to refer back to.

Documenting Standards

• Please read ‣ if you haven’t already.
• Title and headers should be in sentence-case.
• Union-find is always referred to by “union-find”. It should not be referred to as “Union Find” or “Union-Find”. In the case where “union-find” comes at the start of a sentence, call it “Union-find”.

‣ Standards

• Please move newly completed tasks to the TOP of the Done column — this helps us keep track of what’s been completed most recently.
  • Update: this should now be done automatically.
• In progress is fine to order by whatever feels most important - be it size or recentness.
• Backlogs are best ordered oldest to newest - this is done by default as a new item is placed at the bottom of the list.
• Ensure that cards are not vague - should be quantifiable, and have sufficient information that any team member does not need clarification.

‣ Standards

• A sprint planning meeting will be conducted at the start of each sprint to outline the goals for the sprint.
• A sprint retrospective will be conducted at the end of the sprint to identify success and failure points.