Collaboration Agreement

Collaboration Agreement (Version 1.5)

Members: Cathrine Kristiansen, Adrian Paul Limpiado Balunan, Roar Andre Fagerkind, Meenakshi Jayachandra, Robin Strand Prestmo.

Revision History

Date	Version	Description	Author
08/01/26	1.0	First draft	Team 6
12/01/26	1.1	Second draft	Team 6
13/01/26	1.2	Third draft	Team 6
15/01/26	1.3	Final draft	Team 6
21/01/26	1.4	Small changes	Cathrine Kristiansen
29/01/26	1.5	Role changes	Cathrine Kristiansen

---

Introduction

This contract has been drawn up between the group members of Team 6, in the subject of system development. The purpose of this contract is to set guidelines for how the group will distribute tasks, cooperate, and individually take responsibility for the project. The purpose of the contract is to create a good environment in the group, distribute tasks between members, and contribute to active participation and effective progress in the group tasks.

Impact Goals

The group’s project is to develop a software application for people who wish to donate to different organisations that provides aid during wars, conflicts and disasters. The goal is to provide a visual navigation among various organisations and give the relevant information needed.

1. User-Experience: Provide a simple and accessible user experience
2. Data presentation: Present quantitative and qualitative data on registered charities in a readable format
3. Safety: Ensure safe transactions between user and charities
4. Handling of personal data: Robust and privacy-oriented handling of PII
5. Positive team environment: Develop an open and including environment for teamwork to flourish
6. Communication: Improve communication skills and project-based workflow
7. Documentation: Become familiar with documentation of results and workflow
8. Global Relief: Help facilitate the flow of funds to non-profit organizations worldwide

Result Goals

Our Result goals strive for a well-planned execution and a certain quality of the final product, while being beneficial towards the members signing this contract. Our goals rule as follows:

1. Trustworthy and Legitimate: Data presented should come from reliable sources to secure trustworthiness and legitimacy. For ex-ample, data and stats presented can be acquired from IK (Innsamlingskontrollen).
2. Unique User-experience: Product of the project should be offering a unique experience while using the product. For example, a user will be able to make a private profile, containing a historic view of backed charities and favourite charities.
3. Friendly UI: User Interface should follow guidelines from Don Norman’s principles.
4. Fact-based: Statistics on available charities should mirror “Innsamlingskontrollens” database and be accurate
5. On-time: Team will ensure meeting all deadlines given by parties responsible for the assignment and the team itself
6. Beneficial: Agreeing members should have acquired new skills and more experience after closing this contract.

Roles and Responsbilities

The main roles and responsibilities include the Product Owner, Scrum Master, Archive Document Responsible and Software Quality Responsible. During meetings, the roles of Reporter and Meeting leader are assigned and rotated after each meeting. The allocation of these responsibilities and further details is outlined below.

• Product Owner
  External user
  The Product Owner has the responsibility for the products features.
• Scrum Master
  Member: Adrian Paul Limpiado Balunan
  This groups facilitator who guides through the Scrum framework and ensures swift collaboration and ensures a delivering and friendly working environment.
• Archive/ Document Responsible
  Member: Cathrine Kristiansen
  The Archive and Document Responsible has the overall responsibility of all documents connected to the current project. Not necessarily the writing of all documents, but the responsible must have an overarching control and vision over all documents in the project.
• Software Quality Responsible Member: Roar Andre Fagerkind, Robin Prestmo and Meenakshi Jayachandra
  Software Quality Responsible has main responsibility for ensuring the projects meets technical standards throughout the project.
• Reporter and Meeting leader Each meeting will consist of a reporter and a meeting leader. Reporter writes a formal report that documents the main points of meeting, and the Meeting leader ensure that we go through the agen-da.

Below a dedicated calendar for roles dedicated to the upcoming (not official) meetings is shown:

Week-Period	Meeting:	Adrian	Cathrine	Roar	Meenakhi	Robin
2 - 3	Internal Meeting (15.01) + Thursdays Meeting with LA	Leader	Reporter
4 - 5	Internal Meeting (29.01) + Thursdays Meeting with LA		Leader	Reporter
6 - 7	Internal Meeting (12.02) + Thursdays Meeting with LA			Leader	Reporter
8 - 9	Team-meeting with AS (17.02.2026, 10:50, Room: 119C) + Thursdays Meeting with LA + Internal Meeting (26.02.2026)				Leader	Reporter
10 - 11	Internal Meeting (12.03.2026) + Thursdays Meeting with LA	Reporter				Leader
12 - 13	Team-meeting with AS (17.03.2026, 10:50, 119C) + Internal Meeting (26.03.2026) + Thursday Meeting with LA		Leader	Reporter
15 – 16	Internal Meeting (9.04.2026) + Thursday Meeting			Leader	Reporter
17 – 18	Project-presentation (22.04.2026)				Leader	Reporter

Procedures for Teamwork

• Meetings
  Meetings with student assistant will be called by e-mail/outlook calendar weekly, informing all rel-evant parties. The party responsible for calling the meetings will change weekly, letting every team-member participate. During meetings there will be a team leader directing the course of the meeting and a reporter writing a summary of the meeting.
  Standup meetings between team-members will be conducted every time they meet to update on progress. A more formal meeting between team-members will be conducted bi-weekly to update on progress, motivation, and other pressing matters. Meetings &will be agreed upon by team-members and notified by e-mail.

• Notification in case of absence or other incidents
  Notification of absence or lateness will be informed using the teams Facebook group on Messenger.

• Documents
  Microsoft Teams and GitHub will be used to share, edit, and organize documentation. Time track-ing will be done in a shared Microsoft Excel document in Teams.

• Policy for monitoring tasks
  Oral notification through standup meetings and GitHub issue-boards will be used to monitor pro-gress and delegate tasks.

• Submission of teamwork
  Any work in the project must be reviewed and agreed upon reaching consensus, before being sub-mitted.

  Intermediate updates on progress will be shared during standup meetings.

Interactions

• Attendance and preparation
  Meetings with student assistant will occur weekly on Thursdays around 09:30 AM. Stand up meetings discussing work from previous session, and other relevant updates, will start when all participants are present.

• Presence and commitment
  It is expected that the team members focus on the project work when present. Any other distractions will have to wait until after.

• How to support each other
  Help each other with tasks and theory by explaining and demonstrating procedures and avoid providing ready-made solutions. Provide help if a member is feeling stuck on a task.
  Let the team know if something is unclear or difficult to solve. In this way the rest of the team can step in and help before it escalates to a bigger problem.
  Encourage each other when team members are experiencing stress or a slow progression.
  Provide positive feedback on efforts and contributions.
  Everyone should be able to work on their own pace and strengths but provide help when a member needs support.
  The group communicates through messenger. Members are obliged to be available and respond quickly to messages during weekdays, even if you are not physically with the group.
  If a task is too demanding for one person, the task can be divided or temporarily taken over by another.
  Solutions should be brainstormed together, rather than one person sitting alone with the challenge.
  Create a friendly environment by chatting, having a sense of humor, and building relationships that make collaboration easier.
  If a task turns out to be in danger of not being completed by deadline, the entire team steps up to contribute.

• Disagreement, breach of agreement:
  Handling disagreements and conflicts
  Disagreements are discussed openly and respectfully in the group during team meetings. If the group cannot reach a solution, the issue is escalated to the subject teacher.
  Conflicts are first addressed in a one-on-one conversation between those involved, with the team leader present. If the conflict is not resolved, it is brought to the group. If it remains unresolved, the matter is escalated to the subject teacher.
  Follow-up on attendance and effort
  In cases of frequent absence or low effort, the team leader will first raise the issue directly with the person concerned. If there is no improvement, the matter is brought up to the group. If the situation still does not improve, it is forwarded to the subject teacher (Surya Kathayat).
  Handling missed deadlines
  If a task is not delivered by the agreed deadline without prior notice, the team leader will temporarily take over the task and redistribute it to ensure progress. The person originally responsible must compensate by contributing extra work to the next assignment.
  Communication and documentation
  Clarifications are made immediately in Messenger or at the next meeting. Important decisions are always documented in Teams or GitHub to avoid misunderstandings.
  Workload and prioritization
  When the workload is high, the group arranges additional work sessions and prioritizes the most critical tasks. Less important tasks are postponed or removed.
  Quality assurance
  Errors and deficiencies are addressed directly, and the responsible person is given the opportunity to correct them. If the quality repeatedly fails to meet the required standard, two people are assigned to the same task to ensure satisfactory results.

• Eviction
  If a group member is absent from several important group activities and remains unresponsive for several weeks, despite repeated attempts to make contact by both the group and the subject teacher, the member will be removed from the group.
  If the member returns within a reasonable time and is able to reintegrate into the project, and the rest of the group agrees, the member may remain in the group.
  However, if the group determines that there is not enough time for the member to meaningfully rejoin and contribute to the project, the member will be permanently removed from both the group and the project