General workflow

  1. Developers pick their next tasks themselves.

  2. Start by checking if there are tasks in KANBAN/REVIEW that you can review and move to KANBAN/Testing stage

  3. If there are no reviews you can finish, pick a task from KANBAN/open. If you need help to pick a task see the section “Unsure about what task to pick?” in this document.

  4. To check out a task, move it to KANBAN/ONGOING and assign it to yourself and move it to the right project if it’s not in the correct one.

  5. If you need feedback during development, create a MR with “Draft:” in the title and send the link to other team members. Linking between MR and Gitlab task is highly appreciated you can do that by mentioning the issue number after # in the MR e.g (#31) if it is in the same project if not you have include the task url.

  6. When you are happy with the code, create MR or remove [DRAFT] tag if you already have a MR

  7. Move task to KANBAN/REVIEW

  8. You can now repeat from step 1, but make sure to respond to any review comments in MR so the tasks can keep moving towards deploy.

Definition of done

Definition of done defined by user story description or other acceptance criterias in task.

The task considered completed when your code has passed all linters, tests and review comments afterwards it has been merged and deployed. After successful deploy task will be marked “closed” in Gitlab.

Sprints

Sprints start on Monday and last two weeks. We move leftover tickets to the next sprint.

Rituals (follow the links to our company wiki below for details):

Escalation of critical or major severity issues

  • Contact SCRUM-master and request escalation

  • If he is unavailable contact product owner instead.

Gitlab taxonomy

Tasks in Gitlab can contain some common tags, most often in the title

  • [FE] Front End
  • [BE] Back End
  • [QA] Quality Assurance/Testing
  • [MA] Mobile Application
  • [DB] Database
  • [$$$] or [€] Paid feature. Please keep track of spent working time

Be sure to provide a category GitLab tag for any ticket:

  • bug
  • feature
  • enhancement
  • debt
  • task

By default, the severity of a ticket is considered to be normal. However, if escalation is desired, then tag the ticket with:

  • critical - Stops more than one customer from working
  • major - Stops one customer from working

Unsure about what task to pick?

Contact our scrum master and ask for suggestions. If nothing fits inside the KANBAN/open column he can pull in new tasks from backlog. If the scrum master is not available, you can pull in a task yourself, but make sure to notify the scrum master about it.

New tasks should be moved to KANBAN board and also to issues/Sprint

The product owner makes sure issues/list contains prioritized and groomed tasks that could be suitable for everyones skills

Free Sprint

Unlike regular Sprints, Free Sprints do not get planned. Instead, developers get to decide themselves what to work on. That way, developers are given time to keep the codebase cleaner and clearer.

Like regular Sprints, Free Sprints last 2 weeks.

We aim to have a Free sprint every 3 months.