Ever wondered if GitLab supports Agile methodology? If you're considering using GitLab it might not be obvious how its features correspond with Agile artifacts, so we've broken it down for you...
Agile is one of the most important and transformative methodologies introduced to the software engineering discipline in recent decades. While not everyone can agree on the detailed terminology of Agile concepts, it has nonetheless made a significant positive impact on software teams efficiently creating customer-centric products through Agile software development and delivery processes.
GitLab has been designed to be flexible enough to adapt to your methodology, whether Agile or influenced by it. In this post, we'll show a simple mapping of Agile artifacts to GitLab features, and explain how customers have successfully run high-performing Agile software delivery teams with GitLab.
Mapping Agile artifacts to GitLab features
| Agile artifact | GitLab feature | | User story | Issues | | Task | Task lists | | Epic | Epics | | Points and estimation | Weights | | Product backlog | Issue lists and prioritized labels | | Sprint/iteration | Milestones | | Burndown chart | Burndown charts | | Agile board | Issue boards |
An Agile iteration with GitLab
User stories → GitLab issues
In Agile, you often start with a user story that captures a single feature that delivers business value for users. In GitLab, a single issue within a project serves this purpose.
Task → GitLab task lists
Often, a user story is further separated into individual tasks. You can create a task list within an issue's description in GitLab, to further identify those individual tasks.
Epics → GitLab epics
In the other direction, some Agile practitioners specify an abstraction above user stories, often called an epic, that indicates a larger user flow consisting of multiple features. In GitLab, an epic also contains a title and description, much like an issue, but it allows you to attach multiple child issues to it to indicate that hierarchy.
The GitLab issue page has a title and a description area in the middle, providing a space to document any details, such as the business value and relevant personas in a user story. The sidebar at the right provides integration with other Agile-compatible features like the epic that the issue belongs to, the milestone in which the issue is to be worked on, and the weight of the issue, reflecting the estimated effort.
Product backlog → GitLab issue lists and prioritized labels
The product or business owners typically create these user stories to reflect the needs of the business and customers. They are prioritized in a product backlog to capture urgency and desired order of development. The product owner communicates with stakeholders to determine the priorities and constantly refines the backlog. In GitLab, there are dynamically generated issue lists which users can view to track their backlog. Labels can be created and assigned to individual issues, which then allows you to filter the issue lists by a single label or multiple labels. This allows for further flexibility. Priority labels can even be used to also order the issues in those lists.
Sprints → GitLab milestones
A sprint represents a finite time period in which the work is to be completed, which may be a week, a few weeks, or perhaps a month or more. The product owner and the development team meet to decide work that is in scope for the upcoming sprint. GitLab's milestones feature supports this: assign milestones a start date and a due date to capture the time period of the sprint. The team then puts issues into that sprint by assigning them to that particular milestone.
Points and estimation → GitLab issue weights
Also in this meeting, user stories are communicated, and the level of technical effort is estimated for each in-scope user story. In GitLab, issues have a weight attribute, which you would use to indicate the estimated effort.
In this meeting (or in subsequent ones), user stories are further broken down to technical deliverables, sometimes documenting technical plans and architecture. In GitLab, this information can be documented in the issue, or in the merge request description, as the merge request is often the place where technical collaboration happens.
During the sprint (GitLab milestone), development team members pick up user stories to work on, one by one. In GitLab, issues have assignees. So you would assign yourself to an issue to reflect that you are now working on it. We'd recommend that you create an empty and linked-to-issue merge request right away to start the technical collaboration process, even before creating a single line of code.
Agile board → GitLab Issue Boards
Throughout the sprint, issues move through various stages, such as Ready for dev, In dev, In QA, In review, Done, depending on the workflow in your particular organization. Typically these are columns in an Agile board. In GitLab, issue boards allow you to define your stages and enable you to move issues through them. The team can configure the board with respect to the milestone and other relevant attributes. During daily standups, the team looks at the board together, to see the status of the sprint from a workflow perspective.
The GitLab issue list pulls in issues relevant to the particular group or project scope. There are powerful filtering and ordering capabilities that allow you to quickly narrow down that list. For example, you can see a product backlog of prioritized user stories by filtering by prioritized labels. You can see user stories planned to be worked on in a particular sprint by filtering by milestone.
The GitLab Issue Board also pulls in issues dynamically, similar to the GitLab issue list. But it allows for more flexible workflows. You can set up individual lists in the board, to reflect Agile board stages. Your team can then control and track user stories as they move from for example, Ready for dev, all the way to Released to production.
Burndown charts → GitLab Burndown Charts
The development team wants to know if they are on track in real time, and mitigate risks as they arise. GitLab provides burndown charts, allowing the team to visualize the work scoped in the current sprint "burning down" as they are being completed.
Toward the end of the sprint, the development team demos completed features to various stakeholders. With GitLab, this process is made simple using Review Apps so that even code not yet released to production, but in various testing, staging or UAT environments can be demoed. Review Apps and CI/CD features are integrated with the merge request itself. These same tools are useful for Developers and QA roles to maintain software quality, whether through automated testing with CI/CD, or manual testing in a Review App environment.
The GitLab Burndown Chart allows a team to track scoped work "burning down," as they are being completed in a sprint. This allows you to react to risks sooner and adapt accordingly, for example, informing your business stakeholders that certain features are anticipated to be delayed to a future sprint.
A team retrospective at the end of the sprint can be documented in the provided wiki, so that lessons learned and action items are tracked over time. During the actual retrospective, the team can look at the milestone page, which displays the burndown chart and other statistics of the completed sprint.
Hopefully this answers your questions about how GitLab supports Agile! Please leave a comment or tweet us @gitlab @victorwuky if there's anything else you want to know.
