State “To do”

The developer picks a User Story/task to work on (depending on their priority) either from the list of yet unassigned User Stories/Tasks or from the User Stories/Tasks that already have been assigned to himself/herself.

State “In Progress”

The developer implements the User Story/Task - see section "Development Workflow" for a detailed explanation of this step.

State “(Internal) Review”

Development work on the story was finished and a merge request was created. The merge request will be reviewed by (and discussed with) another developer and then merged into the development branch (see “Development Workflow”).

State “Testing”

After a merge request is confirmed and closed, the User Story is reflected in the development stage – To make it ready for testing by an external tester, it should additionally be pushed to the acceptance stage (using our release branches) like so:

1. Pull the branch develop
2. Checkout and pull the current release branch. It has the form release/0.<sprint number>.0.
3. Run git merge --no-ff develop to merge the current state of the develop branch into the release branch.
4. Confirm the commit message. Per default, the “Vim” editor will open. You can confirm the commit message there by typing:wq and hitting enter
5. Push the release branch.

All required documentation for successful testing (e.g. Postman collections, walkthrough descriptions, videos, etc.) should be added to the User Story as a comment.

We decided not to assign the User Stories to the tester anymore as this causes lots of confusion. The same goes for assigning it to the Product Owner when a User Story is done. Thus, the User Story always stays assigned to the developer who integrated it. Instead, the tester should be tagged along with the documentation for testing as a comment on the individual User Story. In addition to that, he should always check for new testable User Stories using the Sprint Board himself.

Scope of Testing

• In general, all User Stories should be officially tested.
• Design Stories are reviewed by the Product Owner either during the weekly Design meetings or in the Sprint Review.

User Stories should be made available for testing as soon as possible from the beginning of the Sprint (and not just towards the end of it)!

State “Done”

The story was successfully tested and can be closed by the Product Owner.

Development Workflow