Practice Scrum Framework with GitLab Application

This article illustrates how to practice Scrum Framework with GitLab application. In that way, software developers will not need to use too many additional tools, which can make more trouble and take time to work with. GitLab is completely free and if you pay a little extra, you get many great features like Point Estimate, Epic, Burn-down Chart and Product Roadmap.

What is Scrum? It’s a framework preferred by software developers for its clear practice while ensuring the pillars of verification, transparency, and adaptability. The Sprint Backlog is a vital backbone of a Scrum cycle, where the entire Development Team sticks to work to create quality products at the end of the Sprint.

You can learn more about the concepts of Scrum here:

• What is Scrum?
• Who is the Product Owner?
• What is the Development Team?
• What is a User Story?

GitLab is a complete DevOps platform for project planning and source code management and CI/CD. Tools like GitLab have become indispensable in the software development’s world.

Define a Sprint using GitLab's Milestone

Defining a Sprint using GitLab's Milestone

Although there is no Sprint definition in GitLab, it is possible to apply Milestone in the Sprint definition.

A Milestone is defined as a Sprint if the following principles are followed:

• The start date and end date of a Milestone is also the start date and end date of a Sprint. These must be fixed days of the week. Regardless of how many days-off during the Sprint. For example, if you set a 1-week Sprint with a start date of Monday and a finish on a Friday, then you would create a serial Milestone series with start and end dates on Mondays and Fridays. Even Fridays fall on the 1st of May and this is still the end of the Sprint. Sticking to this helps you create rhythm. Keeping a regular sprint like a Marathon runner will keep his strength going for great distances.
• Milestone’s name is also the Sprint’s name, choose a memorable name and reflect the goals of each Sprint.
• Milestone’s description will explain in more detail what goals you plan to aim during the Sprint.

Organize the Board to monitor work during the Sprint

Organizing the Boards to monitor work during the Sprint

In GitLab, there is a Board section available so you can monitor work during the Sprint. The managed objects on the Board are the Issue, the equivalent of User Stories in Scrum.

Go to Issue > Board, there are 2 columns Open and Closed. New Issue will be put into Open. Completed and accepted issues by Product Owner will be Closed.

You can add an intermediate stage between Open and Closed to reflect the team's development. Personally, I prefer the following intermediate columns:

• To do: when the issue is clear for development, the team will pull from the Open column to the To do column, the undefined Issue will be kept at Open for clarification. gradually.
• Doing: when the Developer does to any issue, it will be pulled from To do to Doing
• Delivery Ready: When the Developer finishes the issue, it will pull the from Doing to Delivery Ready.
• Delivery Done: After the Developer deploys the issue on the Live/Production environment, the issues will be moved to Delivery Done.

Prioritize Sprint using GitLab Label

To evaluate the priority of Issue, Label in GitLab can be used. You can manually name your Labels such as Must Have, Should Have, and Could Have.

The Cycle of Scrum on GitLab

Sprint Planning

Sprint Planning

To prepare for the planning, the Product Owner should prepare beforehand all the open issues in the column Open, label priorities and organize ranked by priority.

During the sprint planning session, the Development Team will move clear and feasible Issues to the To Do column. If you are unsure, you need to discuss more with the Product Owner to make it clearer before deciding to move issues to To Do.

The Development Team decided to include in Sprint by assigning a corresponding Milestone to the Issue.

The Development Team conducts Estimate each Issue in To Do column by commenting on each Issue by command / estimate.

During the Sprint

Sprint on GitLab

During the Sprint, the team interacts on their Board by filtering the To-Do Issue using the Milestone Filter.

Whoever does something must assign themselves to that Issue, and pulls itself into corresponding columns like Doing.

Note: Monitor and observe the performance of the team. If until the end of the Sprint, the column To Do still has a lot of issues, the possibility of delaying appointment is very high.

Sprint Review

Sprint Review

During the Sprint Review, the Product Owner will make Acceptance of the Issue on the Delivery Done column. If it really meets the requirement, it will be dragged to the Closed column. Any unfinished Issue should be discarded or transferred to another Milestone or another Sprint to do.