Ever wondered if GitLab supports Agile methodology? If you're considering using GitLab it might not be obvious how the DevSecOps platform's 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 development teams efficiently creating customer-centric products through Agile software development and delivery processes.
GitLab is designed to be flexible enough to adapt to your software development 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 –> Tasks
- Epic –> Epics
- Points and estimation –> Issue weight
- Product backlog –> Issue boards
- Sprint/iteration –> Iterations
- Agile board –> Issue boards
- Team workload –> Issue boards
- Burndown chart –> Burndown charts
An Agile iteration with GitLab
User stories → GitLab Issues
In Agile software development methodology, you often start with a user story that captures a single feature to deliver business value for users. In GitLab, an issue serves this purpose with ease. GitLab Issues are essential for Agile teams, providing an effective method to manage tasks and projects. Software developers can create, assign, and track issues, ensuring clear accountability and progress visibility. Issues come with robust metadata such as assignee, iteration, weight, and labels, which enhances task prioritization and workflow management throughout the software development process. Additionally, team collaboration on issues is streamlined with discussion threads, attachments, and real-time updates, enabling effective communication and teamwork.
The GitLab Issue 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 parent that the issue belongs to, the iteration in which the issue is to be worked on, and the weight of the issue, reflecting the estimated effort.
Task → Tasks
Often, a user story is further separated into individual tasks. GitLab Tasks streamline project management by allowing Agile teams to break down user stories into discrete pieces of work. This feature supports the Agile framework by enabling software developers to create, assign, and track tasks within their projects. By integrating task management directly into GitLab, teams can maintain a cohesive workflow, ensuring all software development project activities are easily tracked and managed.
Enhance user value by enabling precise task management and project tracking using GitLab. Tasks are equipped with the same metadata as issues, including assignee, iteration, weight, labels, time tracking, and collaboration features. This comprehensive feature set allows Agile teams and project managers to manage workloads effectively, prioritize tasks, and ensure seamless collaboration among software developers.
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.
GitLab Epics allows Agile teams to organize and manage large projects efficiently by nesting epics up to nine layers deep. This hierarchical structure provides a clear view of the project's roadmap, helping software developers and project managers break down complex initiatives into manageable components. By utilizing child and linked epics, teams can better track progress, dependencies, and project milestones, enhancing collaboration and ensuring cohesive agile delivery.
Product backlog → GitLab Issue Boards
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, an issue board organized with iterations as lists offers a drag-and-drop workflow experience that allows you to effortlessly prioritize your backlog and assign stories to an upcoming sprint.
Sprints → GitLab iterations
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 the work that is in scope for the upcoming sprint. GitLab's iterations feature supports this: Assign iterations a start date and a due date to capture the time period of the iteration. The team then puts issues into the sprint by assigning them to that particular iteration.
By using iterations, you leverage GitLab’s enhanced capabilities for Agile project management, providing better visibility and control over your Agile planning and delivery.
Points and estimation → GitLab issue weight
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 iteration), software 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 iteration and other relevant attributes. During daily stand-ups, the team looks at the board together, to see the status of the sprint from a workflow perspective.
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.
Team workload → GitLab Issue Boards
Agile teams can optimize their workflows by creating issue boards with lists scoped to assignees in GitLab. This feature allows you to visualize the distribution of tasks among team members, enhancing Agile delivery. To set it up, navigate to your project or group, create a new board in the "Boards" section, and add lists for each assignee. Assign issues to team members, and they will automatically appear in the corresponding lists. This dynamic view empowers balanced workloads and effective task management.
Organize an issue board by assignee or by squad using [scoped labels]. GitLab’s Issue Board is incredibly diverse and supports workflows across the software development lifecycle.
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.
Team retrospectives at the end of the sprint can be documented in GitLab’s wiki, so that lessons learned and action items are tracked over time. During the actual retrospective, the team can look at the iteration report, which displays the burndown chart and other statistics of the completed sprint.
Start your Agile journey with GitLab
Ready to elevate your Agile project management? GitLab offers a comprehensive suite of features tailored to Agile teams, software developers, and project managers, ensuring seamless collaboration and efficient workflows. Explore our pricing options, start a free trial and discover how GitLab can transform your Agile delivery processes.
Learn more about GitLab Agile planning and get started on your journey today!
