Retrospectives

Retrospective 1 — Sprint 1

What should we continue to do?

• Keep dividing the work by functional area so each team member has clear ownership.
• Continue using GitHub issues and descriptive commits to preserve traceability.
• Keep reviewing the requirements together before implementing them.

What should we start doing?

• Start recording weekly meetings with the required individual questions from the beginning of each sprint.
• Start adding explicit validation criteria to requirements before development begins.
• Start checking the deliverable template earlier instead of waiting until the sprint closes.

What should we stop doing?

• Stop leaving documentation until the final days of the sprint.
• Stop using requirement wording that is difficult to verify objectively.
• Stop relying only on screenshots as meeting evidence without dates, attendees, and written conclusions.

---

Retrospective 2 — Sprint 2

What should we continue to do?

• Continue integrating features through small pull requests and testing the main user flows locally.
• Keep the responsibilities by module while reviewing integration points as a team.
• Continue using the project board to make sprint progress visible.

What should we start doing?

• Start testing interactions between modules earlier, especially flows that depend on authentication and tutoring state changes.
• Start updating the Wiki at the same time a requirement is completed.
• Start reviewing architecture and data-model diagrams whenever the implementation changes.

What should we stop doing?

• Stop writing weekly reports only in collective form when the template requires individual answers.
• Stop leaving architecture sections describing features as planned after those features are already implemented.
• Stop closing a sprint without checking the rubric item by item.

---

Retrospective 3 — Sprint 3

What should we continue to do?

• Continue adding automated tests for each new requirement and running the complete test suite before merging.
• Keep using pull-request review before integrating changes into main.
• Continue coordinating dependencies between materials, tutoring, and notifications instead of treating each feature in isolation.

What should we start doing?

• Start resolving merge conflicts as soon as the base branch changes to avoid accumulating integration work.
• Start closing or updating GitHub issues immediately when their implementation reaches main.
• Start maintaining the component diagram and requirement status table as living documentation throughout the sprint.

What should we stop doing?

• Stop allowing Wiki status tables to remain outdated after a requirement has already been merged.
• Stop postponing shared documentation tasks until the end of the sprint.
• Stop assuming that a feature works only because its isolated tests pass; continue validating the full project test suite before merge.