1. Declared Interest

Team Member	CI/CD + Infrastructure	Data model/DB	BE Software design/-architecture & API	BE Implementation + Testing	UI/UX Design	FE Software design/-architecture	FE Implementation + Testing
Till Cadow	✅	✅	✅	✅
Dario Brunner	✅		✅			✅
Noah Baumgartner				✅	✅	✅	✅
Jason Weber					✅		✅
Noe Zimmermann	✅				✅	✅	✅
Timo Sigrist	✅				✅	✅	✅
Cyrill Berger	✅	✅	✅	✅
Karim Elhayawan	✅	✅	✅	✅

2. Branching Model

We use a combination of a trunk-based and feature-branching workflow as our branching-model with a protected main branch. Any changes intended for the main branch require an approved pull request. To discourage branch reuse and maintain a manageable number of branches, branches have to be deleted after they were merged.

• Branch names follow this convention: "{feat|fix}/{short-description}" (E.g "feat/time-tracking")

Successful pull requests are merged into the main branch and pushed to the staging environment. Pushes labeled with release tags are deployed to the production environment.

3. General Coding Style Guide

• No abbreviations
• DRY - principal
• Code and JavaDoc are held in English
• Git commit messages are appended with an issue key and are imperative (E.g. "Add unit test #2")
• Unit tests follow the naming convention: "when{StateUnderTest}_expect{result}" (E.g. "whenParagraphIsEmpty_expectNoIndices")

4. Sprint Reviews and Sprint Retrospectives

All team members commit to hold a combination of sprint review/ retrospective on the recuring Tuesday online meeting. Protocols are completed by a team member using the specified templates and stored in the protocols directory on the team's Teams channel.

5. Sprint Retrospective Protocol Template

## 1. Was ist im Sprint optimal gelaufen?

| Team Member  | Input |
|-------|-------|
| Till Cadow  |     |
| Dario Brunner |      |
| Noah Baumgartner |      |
| Jason Weber  |     |
| Noe Zimmermann  |      |
| Timo Sigrist  |      |
| Cyrill Berger  |     |
| Karim Elhayawan  |      |

## 2. Was ist im Sprint suboptimal gelaufen?

| Team Member  | Input |
|-------|-------|
| Till Cadow  |     |
| Dario Brunner |      |
| Noah Baumgartner |      |
| Jason Weber  |     |
| Noe Zimmermann  |      |
| Timo Sigrist  |      |
| Cyrill Berger  |     |
| Karim Elhayawan  |      |

## 3. Was werden wir bindend im nächsten Sprint anderes/besser machen?

- 
-
- 

6. Definition of Ready

A Userstory is defined as ready when it fulfils the following criteria:

a. The userstory and its parts/tasks are defined and documented

Every userstory is recorded as a Github issue. The userstory contains a summary title and if necessary an explanatory paragraph followed by a checklist of its constituent tasks in the Github Markdown style. This content is defined by its assignees and added to the issue description and not as a comment.

The list ensures that the responsibilities are clear and that the responsible assignees have thought about/communicated/documented the steps they will take to implement the userstory and that the rest of the team can gauge the progress of the userstory.

b. The userstory acceptance criteria are defined and documented

After the userstory checklist, the issue description also includes a list of defined acceptance criteria that are unique to the userstory.
It is also possible to include points from the "Definition of Done".

c. Dependencies to other userstories are identified and documented

If the userstory is dependant on or is a dependant of another userstory, the Github issue in question is tagged with a short explanation.

d. The userstory has been estimated by the team

An estimate in storypoints was set by the team and documented in the issue.

e. If necessary non-functional requirements are defined

If needed, non-functional requirements are documented in the userstory after the task checklist and before the acceptance criteria.

f. The userstory has been assigned

Functionality userstories are assigned to a duo of a backend specialist and a frontend specialist.

g. The target of the userstory is clear to the entire team

The team has a clear understanding of the goals and targets of the userstory.

A Github issues template has been defined that covers and includes all the necessary fields for a ready userstory.

7. Definition of Done

a. Review of code changes

All code changes have been reviewed and checked into Github. At least one person reviewed the code (except for peer-coding).

b. Successful test

All tests in the corresponding test-pipeline have been successfully executed and passed.

c. Code is formatted and commented

The code is formatted (e.g. Ctrl+Alt+L in Intellij). There are no unnecessary line breaks and no code that is commented out. Where required the code is commented

d. Test of UI

All user interface elements have been tested on various screen sizes and resolutions and are user-friendly.

e. Test of functionality

The underlying git-issue is fully implemented. This also includes UAT tests where present. The functionality has also been tested on different browsers and platforms and there is no bug in the code.

f. Documentation

Existing/ required documentations have been updated (e.g. API-documentation)