Coffee GitLab

Purpose

Coffee uses GitLab to manage all tasks during a sprint.

Definitions

Project

Coffee currently has 3 active projects:

• Magestore.com: all activities related to the website, as well as team's internal activities such as training
• Retail assistant: all activities related to marketing Assisty
• Partnership: all activities related to building and running partnership with other companies

Issue

For Coffee, Gitlab issues are units of work with a deliverable such as images, landing page, 30-min sharing session, or Handbook guide.

Try to narrow the scope of the issue down to something that can be done within 6 hours.

All information related to the issue should be updated into the description or the comment.

During the sprint, the person in charge of an issue will drag the issue across the board based on their status. At the end of the sprint, after the Weekly review and retro, the facilitator or task owner will close the issue.

Board

Coffee team use the Group Development Board to manage all activities across different projects.

All issues are visualized in a Kanban board with Stage column. The stage columns describe the progress of each issue.

Group milestone

The equivalent of weekly sprint.

Group milestone always starts on Monday and ends on Friday.

Current format: WNo. (dd/mm–dd/mm). Example: W42 (12/10–16/10).

Remember to assign milestone for all issues the team work on during the sprint.

Label

GitLab uses label to organize, tag, and filter issues.

Coffee team currently use Group labels that can be applied across all projects.

• Topic: Marketing functions the issue fall under. Should be assigned when creating the issue
• Type: Only use for technical issues such as bug or function. Should be assigned when creating the issue
• Partner: Stage/phase of the partnership
• Value: How important it is to deliver the task during the sprint. Assigned during Sprint planning meeting
• Priority: How urgent is the task. Assigned during Sprint planning
• State: Progress of the issues. Updated during the sprint

Process on Coffee group board

• Team member creates new issue under Open column.
• Team member refines the tasks and put issues for next week into Sprint Backlog column.
• Before Spring planning, development team move relevant issues into To Do column.
• During the sprint, the issue assignee updates the status and information related to the issue.
• At the end of the sprint, the team review and demo the completed work. The assignee closes the Done issues.
• During the review and retro session, facilitator creates new issues based on the discussion.

Create new issue

• Any team member can create new issue. It could be a new idea, activity the team agrees to work on, or request from other team.
• Check other items in the board in advance to make sure you don't create duplicate issues.
• Use the Open column to add new issue. Assign the correct Project to the issue.

• Add as much information to the issue as you can. Use the non_technical_task template to help you fill in information about the task. You can also refer to Markdown Guide to format your issues.

• Assign the relevant Topic labels to the issue. Also include the Type label if it's a technical function or bug.

• All new issues should be under the Open column. In case there's a new urgent task the team needs to do during the sprint, add the task to To Do column. Try to avoid this situation.

Move task to Sprint Backlog

• This action is done by the team member who's responsible for the task.
• Items under Sprint Backlog are refined tasks that the team can work on.
• Items under this column should at least include: User Story, Acceptance Criteria, and DoD.

Move task to To Do

• This action is done by the assignee before sprint planning.
• The facilitator confirm all issues that the team agree to work on for that sprint under To Do column.
• To Do issues should include:
  • Milestone
  • Assignee (person in charge)
  • Labels: Value, Priority
  • Deadline or estimate

Update task

• The person in charge of an issue should update the status of the issue regularly throughout the sprint.
• When the task is complete, move the issue to Done column.
• Each person should log the spent time for each issue using /spend.

Close issue

• An issue should only be closed after the Sprint review, by the task owner or facilitator.