Skip to content
BoKSA

Collaboration Contract

Collaboration Contract

This is the template for your team's collaboration contract. Copy the block below into a markdown file in your team's repository, fill in every table, and have each team member sign it.

Where this document lives

The filled-in contract is stored in the GitLab repository, and every team member also delivers it in Portflow as evidence for the Manage & Collaboration learning outcome — it records your agreements. See Delivering your work. When the contract changes, add a new version to the existing evidence item rather than creating a second one.

Copy this template

# Collaboration Contract — Team X

## 1. Team members

| Name | HvA email address | Mobile |
| --- | --- | --- |
|  |  |  |
|  |  |  |
|  |  |  |
|  |  |  |
|  |  |  |
|  |  |  |

## 2. Agreements

Every team member follows the method of the studio Responsible AI, including the
following rules.

### 2.1 Time management

- Physically present with the team every working day, from 9 to 5.
- Finish all work before deadlines.

### 2.2 Organisational management

- Actively present at the stand-up and stand-down every day.
- In meetings with the client, actively present in the agreed role as stated in
  this document.
- Taking care of the described way of communicating with the client.
- Making use of the Issue Board as stated.

### 2.3 Information management

- Archiving work in the repository, keeping it up to date at the end of every day.
- Keeping the team informed about your work, and keeping yourself informed about
  the work of the team.
- Email input for a meeting minimally 2 days in advance.

### 2.4 Additional team agreements

-
-
-

## 3. Assigned roles

### 3.1 Assigned team roles

| Sprint | Team Role | Name |
| --- | --- | --- |
|  |  |  |
|  |  |  |
|  |  |  |
|  |  |  |
|  |  |  |

### 3.2 Assigned meeting roles

| Sprint | Week | Meeting Role | Name |
| --- | --- | --- | --- |
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |

## 4. Exit procedure in case of a non-functioning team member

-
-
-

## Agreed

| | Team member 1 | Team member 2 | Team member 3 |
| --- | --- | --- | --- |
| **Name** |  |  |  |
| **Signature** |  |  |  |
| **Date** |  |  |  |

| | Team member 4 | Team member 5 | Team member 6 |
| --- | --- | --- | --- |
| **Name** |  |  |  |
| **Signature** |  |  |  |
| **Date** |  |  |  |

How to fill it in

1. Team members — every team member, with the HvA email address and the mobile number the team can reach them on.

2.1 Time management — these rules are fixed; they come from the studio method.

2.2 Organisational management — the rules refer to the daily stand-up and stand-down, the meeting with the client, and the Issue Board.

2.3 Information management — "the repository" is the team's GitLab repository, committed each day before the stand-down.

2.4 Additional team agreements — anything further your team agrees on: working together on campus, extra meetings outside the stand-up and stand-down, and what team members without a formal role contribute to improving the collaboration.

3.1 Assigned team roles — one of each role per sprint: Daily Master, Issue Master, Communication Master, Backlog Master, Delivery Master. See Sprint and Team Roles.

3.2 Assigned meeting roles — chairperson, note-taker and participant for the client meeting; these rotate weekly. See Meeting with the Client.

4. Exit procedure — what the team does when a team member does not function: which steps are taken, in what order, who is involved, and at what point the project coach is informed.

Agreed — every team member signs. In a repository file, type your name and the date; a scan or image of the signed document works too.