 GitLab has been designed to be flexible enough to adapt to your methodology, whether Agile or Influenced by it. In this video, we'll show a simple mapping of Agile artifacts to GitLab features and explain how customers have successfully run high-performing Agile teams with GitLab. The roadmap is the schedule events that communicate planned solution deliverables over a planning horizon. GitLab roadmap shows epics, timeframes, and can be visualized as a timeline. Whether a portfolio initiative or investment, a capability or feature, or simply a large story, use an epic to capture its description, business case, or any data pertinent to describe the large body of work. 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 and indicate that hierarchy. Break down a large epic into discrete, logical pieces for individual, independent tracking with child epics and 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 with a project serves its purpose. Often, a user story is further separated into individual tasks. You could create a task list within an issue's description in GitLab to further identify those individual tasks. Product owners create issues to reflect the needs of the business and customers. They are prioritized in a product backlog to capture urgency and desired order of development and communicate with stakeholders to determine the priorities. 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 list by a single label or multiple labels. This allows for further flexibility. Parody labels can be even used to also order the issue in those lists. A sprint represents the 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. GitLab's milestone 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 a particular milestone. Development teams want to know if they are on track in real time and mitigate risk as they arise. GitLab provides burn down charts, allowing the team to visualize the work scoped in the current sprint, burning down as they are being completed. The level of technical effort is estimated for each end scope issue, and GitLab issues have a weight attribute, which you would use to indicate the estimated effort. During the sprint, development team members pick up issues 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. 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. In GitLab, issue boards allow you to find your stages and enable you to move the issues through them. The team can configure the board with respect to the milestone 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. Toward the end of a 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 can be demoed. Review apps and CICD features are integrated with the merge request itself. A team retrospective at the end of the sprint can be documented in a provided wiki so that lessons learned and action items are tracked over time. During the actual retrospective, the team can look at the milestones page, which displays the burn-out chart and other statistics on the completed sprint. Thanks for watching how GitLab supports agile.