Team Project Marking: Sprint 2

In the second sprint, you will finalize your project documentation. At this stage, your system design should be complete.

You will make your hands dirty with the code and make significant progress on your codebase and tests. At the end of this sprint, you will have the first working prototype.

Late release submission policy

Applies to all sprints.

If a sprint release is late for less than 24 hours: penalty of 5 marks.

If late for more than 24 hours: penalty at the instuctor's discretion, min. 10 marks.

Rubric

Deliverable Marks
Revisions 10
Detailed design 20
Codebase 25
Testing 10
Sprint planning 10
Teamwork 15
Addressing TA feedback 10
Total 100

Revisions

  • All required revisions from Sprint 1 have been sufficiently addressed.

Detailed design

  • System architecture is clearly defined
  • Data models are clearly defined (using UML Class diagram, or ER diagram)
  • Interfaces (APIs, modules, etc.) are well defined and documented, i.e., how will interfaces interact with each other
  • Design is complete, it fully represents the product, all planned functionalities can be explained/developed based on the design as documented

Codebase

  • Sufficient progress has been made (as planned in the previous sprint)
  • GitHub repo is well organized, using the best practices
    • One branch for each sprint with sub-branches for features (not for team members).
    • Feature branches must be based on GitHub issues related to the feature.
    • Never merging directly but rather creating pull requests with comments and having the commit's content reviewed by another team member. Branch protection rules must be set up on the sooner side.
    • Pull requests from sprint branches to main (or master) must be reviewed by the scrum master before being merged at the end of the sprint.
    • All releases must be based on the main branch.
    • Issues must be maintained well with tags and closed whenever they're complete.
    • Closed issues should be tagged in a Pull Request or commit.
  • Code is well structured and organized
  • Code is well written and efficient
  • Comments consistent is useful

Testing

  • Tests exist and run for (as many as possible of) the demonstrated functionalities
    • Tests should be Acceptance Tests for testing user stories from the user's point-of-view
    • Tests should be labelled with what user story they're for
    • Tests should be tracked in a "Requirements Traceability Matrix"
    • Tests should include success and failure scenarios (e.g. test good password and bad password)
    • Tests should ideally be user interface tests using UI test automation tools (e.g. selenium for web UIs)
    • API should be tested if applicable
    • Unit tests (tests per function, method, class in the code) are not required

Sprint planning

  • Storymap clearly represents the current state of the project
  • Project plan is updated to reflect the current state of the project
  • Velocity is re-estimated for Sprints 3, 4, and 5
  • Sprint 3 tasks are included in the project plan
  • Detailed Github Issues for Sprint 3 correspond with the storymap and project plan, have relevant states, milestones, labels and assignees

Teamwork

  • Meeting minutes exist for all meetings and include all required information
  • All team members attend meetings
  • All team members have contributed to the sprint; each team member worked across multiple types of tasks (management, coding, testing, documentation, etc.)
  • Team works well with the TA (asks questions/advice, reports progress meaningfully, addresses feedback, is kept in-the-loop about client)
  • Team as a whole has made real progress since the last sprint - accomplished what they had planned to
  • Scrum roles are defined for the sprint (in their own section, separate of the team canvas)

Addressing TA feedback

  • The team has made meaningful efforts to incorporate the TA's feedback from previous sprint.
  • Specific issues raised by the TA have been acknowledged and resolved or a clear plan has been documented to address any remaining concerns.
  • Changes based on feedback are evident in the project deliverables (e.g., revisions, codebase, design).
  • Teams should demonstrate an understanding of the feedback by providing clear justifications or explanations for any decisions that differ from the TA's suggestions.
  • Proactive communication with the TA regarding feedback implementation is encouraged.