# RFC: Sprint/GitLab Workflow

## Motivation

Our current GitLab workflow is optimized for the pre-sprint era of ATMINA. One hard requirement is that when an issue gets started the one responsible person is easily identifiable.
This required us having to split and continuously synchronize our workflow with GitLab Labels throughout the issue **and** the merge request, as the assignee on the issue must be the above mentioned responsible person.

I have yet to see a sprint team where this synchronization is correctly updated.
Status quo is a complicated workflow and it takes longer to onboard newer team members and is unsure whether the workflow is correctly applied to the issue and merge request.

After the team shuffling I noticed that we developed slightly different habits of keeping the GitLab Label synchronized.

## Requirement

Start with a minimalistic workflow and change based on feedback.

The following workflow requires working in a sprint team, meaning the team has a shared commitment and responsibility to fulfill the sprint goals for the customer.

Whereas before in the pre-sprint era only one person was responsible for an issue.

This allows us to drop the previous hard requirement, where one responsible person has to be visible at all times once work got started on the issue.

A merged Merge Request no longer automatically closes the issue.

## Proposition

The whole workflow is on the issue itself. The merge request is an afterthought and does not get any labels assigned at all. Even the assignee is not part of the workflow.

If you want to see who has worked on this issue or merge request and is likely the most knowledgable (note: rather than responsibility),
take a look at the commit history of issue activity. Given that we are working on a two-week sprint and have dailies each day I would argue that the lifetime of an issue, the shared sprint team responsibility, and the daily sprint meetings do no longer require us to have an explicit field of a single responsible person.

The git commit history on the merge request and the activity on the issue itself is more than enough of documentation to trace it back and answer the question: "Who is the most knowledgeable about this issue or merge request and who worked on it?".

I propose two different GitLab Boards
1. **Sprint Planning**
2. **Current Sprint**

*On both board the default columns `Open` and `Closed` are collapsed and not part of the workflow.*

The first board `Sprint Planning` has two labels/columns.

1. **Refined Backlog**
This the place all confirmed issues from the product owner (PO) are. If you want to add a user story/task/design/bug (*explained below*) to it ask the PO in the corresponding Mattermost project channel.
2. **Sprint Backlog**
Current or rather the next sprint. In a sprint planning, you take the issues of `Refined Backlog`, estimate it, and move it to the next column `Sprint Backlog`.

The refinement appointment and sprint planning are largely done with the Google Spreadsheet.

At the end of the refinement appointment, the Google Spreadsheet rows are translated into "Issues" and correctly placed in the "Refined Backlog".

The following points describe why we don't have a "Product Backlog" in GitLab.
- It is easier for the PO to fill the "Unrefined Backlog" in a Spreadsheet. For example, transcribing from an E-Mail or while on a phone call.
- It is easier to summarize our estimates of specific rows.
- We will migrate the Google Spreadsheet to our Requirements Engineering Tool in the future, where the product backlog is largely derived from a) the contract, b) ongoing agile documents, and talks which track the changes. From this new tool, we will be able to fill our GitLab board and remove the Spreadsheet.

At the end of the sprint planning a new milestone, which represents the sprint has been created, and "Refined Backlog" issues are placed in there.

This allows us to keep track of previous sprints. It has no other purpose.

All issues of the above-mentioned milestone are added to the "Current Sprint" board.

The second board `Current Sprint` is where work is done for the next two weeks.

It has the following labels:
1. **Sprint Backlog**
The backlog of the current sprint. It is the same label as used by the `Sprint Planning`-Board. Must not have an assignee.
2. **In Progress**
Someone is working on it. Must have an assignee.
3. **Ready for Review**
The issue can be refined by someone. Must not have an assignee.
4. **In Review**
Must have an assignee.
5. **Done**

The workflow labels are exclusive. It is recommended to use the provided board via drag and drop instead of updating them manually.

This workflow incorporates different kind of workflow tasks for example:
- Programming
- Design
- QA

Instead of having separate labels for it, they can fit into the same board. However, compared to some other solutions which explicitly model this, a bit more communication is needed.

The board is small enough to fit on a single monitor screen.

The `Sprint Backlog` board gets locked and cleaned up on the last day of the sprint before lunchtime when two persons make sure that staging is working and all intended stories are properly implemented.

We do have **four different kinds of issues** each with their own GitLab issue template:
1. **User Story** ~User Story (#8E44AD)
2. **Task** (i.e. technical or small changes like text adjustments) ~Task (#428BCA)
3. **Bug** ~Bug (#FF0000)
4. **Design** ~Design (#A8D695)

The labels are also exclusive. Do not assign them yourself, use the provided template.

TODO: The actual issue template content is TBD.