Tutorial: GitLab으로 스크럼 진행하기
GitLab v19.5요약
이 튜토리얼에서는 GitLab의 애자일 계획 및 추적 기능을 사용해 핵심 스크럼 세리머니와 워크플로를 진행하는 방법을 단계별로 안내합니다. Martin Fowler의 애자일 유창성 모델(Agile Fluency Model)에 따르면, 스크럼(Scrum)을 실천하는 팀은 다음과 같습니다.
이 튜토리얼에서는 GitLab의 애자일 계획 및 추적 기능을 사용해 핵심 스크럼 세리머니와 워크플로를 진행하는 방법을 단계별로 안내합니다. 그룹, 프로젝트, 보드 등의 기능을 의도적으로 구성하면 팀은 투명성, 협업, 전달 주기를 향상시킬 수 있습니다.
Martin Fowler의 애자일 유창성 모델(Agile Fluency Model)에 따르면, 스크럼(Scrum)을 실천하는 팀은 다음과 같습니다.
...스폰서, 고객, 사용자가 자신들의 소프트웨어에서 얻을 이점을 기준으로 사고하고 계획합니다.
이러한 팀은 매월 진행 상황을 시연하고, 더 많은 비즈니스 및 고객 가치를 제공하기 위해 프로세스와 작업 습관을 개선하는 방법을 정기적으로 성찰함으로써 이를 달성합니다.
이 튜토리얼에서는 다음 주제를 다룹니다.
그룹과 프로젝트 설정하기#
GitLab에서 스크럼 실천을 진행하려면 먼저 그룹과 프로젝트의 기본 구조를 설정해야 합니다. 그룹은 해당 그룹 하위에 중첩된 프로젝트가 상속할 수 있는 보드와 레이블을 만드는 데 사용합니다. 프로젝트에는 각 스프린트를 구성하는 실제 작업 항목인 이슈와 태스크가 포함됩니다.
GitLab의 상속 모델 이해하기#
GitLab은 그룹이 프로젝트를 포함하는 계층 구조로 되어 있습니다. 그룹에 적용한 설정과 구성은 하위 프로젝트로 전파되므로, 여러 프로젝트에 걸쳐 레이블, 보드, 이터레이션을 표준화할 수 있습니다.
소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart TD
accTitle: GitLab inheritance model diagram
accDescr: Shows how groups, projects, issues, labels, milestones, iterations, tasks, and epics relate to one another in GitLab
Group -->|Contains| Project
Group -->|Contains| Epics
Group -->|Contains| Labels
Group -->|Contains| Boards
Group -->|Contains| Iterations
Group -->|Contains| Milestones
Group -->|Contains| Roadmaps
Project -->|Contains| Issues
Project -->|Contains| Templates
Project -->|Contains| Tasks
Project -->|Contains| Milestones
Project -->|Contains| Labels
Labels .->|Cascades To| Project
Issues .->|Rolls up to| Group
Iterations .->|Cascades to| Project
Milestones .->|Cascades to| Project
Templates .->|Cascades to| Project
Templates .->|Configured in| Group
Issues .->|Child of| Epics
Issues .->|Visible in| Boards
Issues .->|Visible in| Lists
Issues .->|Assigned to| Iterations
Issues .->|Assigned to| Milestones
Tasks .->|Child of| Issues
Tasks .->|Assigned to| Iterations
Tasks .->|Assigned to| Milestones
Epics .->|Visible in| Boards
Epics .->|Visible in| Roadmaps
Epics .->|Visible in| Lists</code></pre></details></div>
- 그룹에는 하나 이상의 프로젝트, 에픽, 보드, 레이블, 이터레이션이 포함됩니다.
그룹의 사용자 멤버십은 그룹의 프로젝트로 전파됩니다.
- 보드와 레이블은 그룹이나 프로젝트에서 만들 수 있습니다.
이 튜토리얼에서는 하나의 그룹에 속한 여러 프로젝트에 걸쳐 표준화된 계획 워크플로와 보고를 진행할 수 있도록
그룹에서 만듭니다.
- 프로젝트로 전파되는 객체는 해당 프로젝트의 이슈와 연결할 수 있습니다.
예를 들어 그룹의 레이블을 이슈에 적용할 수 있습니다.
그룹 만들기#
스크럼 활동을 위한 전용 그룹을 만듭니다. 이 그룹은 프로젝트 전반에 걸쳐 표준화하려는 보드, 레이블 등의 구성과
프로젝트의 상위 컨테이너 역할을 합니다.
이 그룹은 일반적인 스크럼 주기 동안 다양한 활동이 이루어지는 주요 위치가 됩니다.
여기에는 보드, 기능(에픽), 스토리(이슈) 롤업, 레이블이 포함됩니다.
그룹을 만들려면 다음과 같이 진행합니다.
- 오른쪽 상단에서 Create new(+)를 선택하고 New group을 선택합니다.
- Create group을 선택합니다.
- Group name 텍스트 박스에 그룹 이름을 입력합니다. 그룹 이름으로 사용할 수 없는 단어 목록은
예약된 이름을 참고합니다.
- Group URL 텍스트 박스에 네임스페이스로 사용할 그룹 경로를 입력합니다.
- 그룹의 Visibility level을 선택합니다.
- 선택 사항. GitLab 사용 경험을 개인화하려면 다음을 진행합니다.
- Role 드롭다운 목록에서 본인의 역할을 선택합니다.
- **Who will be using this group?**에서 옵션을 선택합니다.
- What will you use this group for? 드롭다운 목록에서 옵션을 선택합니다.
- 선택 사항. 그룹에 멤버를 초대하려면 Email 1 텍스트 박스에 초대할 사용자의 이메일 주소를 입력합니다.
더 많은 사용자를 초대하려면 Invite another member를 선택하고 사용자의 이메일 주소를 입력합니다.
- Create group을 선택합니다.
프로젝트 만들기#
만든 그룹 안에 하나 이상의 프로젝트를 만듭니다. 프로젝트에는 상위 그룹으로 롤업되는 스토리가 포함됩니다.
빈 프로젝트를 만들려면 다음과 같이 진행합니다.
- 오른쪽 상단에서 Create new(+)를 선택하고 New project/repository를 선택합니다.
- Create blank project를 선택합니다.
- 프로젝트 세부 정보를 입력합니다.
- Project name 텍스트 박스에 프로젝트 이름을 입력합니다.
프로젝트 이름 제한 사항을 참고합니다.
- Project slug 텍스트 박스에 프로젝트 경로를 입력합니다. GitLab 인스턴스는 이 슬러그를 프로젝트의
URL 경로로 사용합니다. 슬러그를 변경하려면 먼저 프로젝트 이름을 입력한 다음 슬러그를 변경합니다.
- 사용자에 대한 프로젝트의 보기 및 액세스 권한을 수정하려면
Visibility Level을 변경합니다.
- Git 리포지터리가 초기화되고 기본 브랜치를 가지며 클론할 수 있도록 README 파일을 만들려면
Initialize repository with a README를 선택합니다.
- Create project를 선택합니다.
스크럼 라이프사이클의 여러 단계를 지원하는 스코프 레이블 만들기#
다음으로, 만든 그룹에서 이슈를 분류하기 위해 이슈에 추가할 레이블을 만듭니다.
이때 가장 적합한 도구는 상호 배타적인 속성을 설정하는 데 사용할 수 있는
스코프 레이블입니다.
스코프 레이블 이름에 있는 콜론 두 개(::)는 같은 스코프의 레이블 두 개가 함께 사용되는 것을 방지합니다.
예를 들어 이미 status::ready 레이블이 있는 이슈에 status::in progress 레이블을 추가하면 기존 레이블은
제거됩니다.
각 레이블을 만들려면 다음과 같이 진행합니다.
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
- 왼쪽 사이드바에서 Manage > Labels를 선택합니다.
- New label을 선택합니다.
- Title 텍스트 박스에 레이블 이름을 입력합니다.
priority::now부터 시작합니다.
- 선택 사항. 사용 가능한 색상 중에서 선택하거나, Background color 텍스트 박스에 특정 색상의
16진수 색상 값을 입력해 색상을 선택합니다.
- Create label을 선택합니다.
이 단계를 반복해 필요한 모든 레이블을 만듭니다.
- Priority: 기능 수준의 릴리스 우선순위 지정을 진행하기 위해 에픽 보드에서 사용합니다.
priority::now
priority::next
priority::later
- Status: 전체 개발 라이프사이클에서 스토리의 현재 단계를 파악하기 위해 이슈 보드에서 사용합니다.
status::triage
status::refine
status::ready
status::in progress
status::in review
status::acceptance
status::done
- Type: 일반적으로 하나의 이터레이션에 포함되는 여러 유형의 작업을 나타내는 데 사용합니다.
type::story
type::bug
type::maintenance
이터레이션 주기 만들기#
GitLab에서는 스프린트를 이터레이션이라고 합니다. 이터레이션 주기에는 이슈를 계획하고 보고하기 위한
개별적이고 순차적인 이터레이션 타임박스가 포함됩니다. 레이블과 마찬가지로 이터레이션도 그룹, 하위 그룹,
프로젝트 계층 구조로 전파됩니다. 그래서 이터레이션 주기는 만든 그룹에서 만듭니다.
사전 요구 사항:
- 그룹에 대해 Reporter, Developer, Maintainer, Owner 권한이 있어야 합니다.
이터레이션 주기를 만들려면 다음과 같이 진행합니다.
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
- 왼쪽 사이드바에서 Plan > Iterations를 선택합니다.
- New iteration cadence를 선택합니다.
- 이터레이션 주기의 제목과 설명을 입력합니다.
- Enable automatic scheduling 체크박스가 선택되어 있는지 확인합니다.
- 자동 스케줄링을 사용하는 데 필요한 필드를 입력합니다.
- 이터레이션 주기의 자동화 시작일을 선택합니다. 이터레이션은 시작일과 같은 요일에 시작하도록
예약됩니다.
- Duration 드롭다운 목록에서 2를 선택합니다.
- Upcoming iterations 드롭다운 목록에서 4를 선택합니다.
- Enable roll over 체크박스를 선택합니다.
- Create cadence를 선택합니다. 주기 목록 페이지가 열립니다.
이터레이션 주기를 이렇게 구성하면 다음과 같습니다.
- 각 스프린트의 기간은 2주입니다.
- GitLab이 향후 스프린트 4개를 자동으로 만듭니다.
- 현재 스프린트가 종료되면 완료되지 않은 이슈가 다음 스프린트로 자동으로 재할당됩니다.
Automatic scheduling을 끄고 주기에서
이터레이션을 수동으로 만들고 관리할
수도 있습니다.
기능 백로그 관리하기#
기능 백로그는 아이디어와 원하는 기능을 에픽 형태로 담습니다. 이 백로그를 정제해 나가면서 에픽은
우선순위가 지정되어 향후 스프린트로 흘러 들어갑니다. 이 섹션에서는 백로그 관리를 진행하기 위한 에픽
보드를 만들고 첫 기능 에픽을 작성하는 방법을 다룹니다.
작업 구조화 방식 결정하기#
GitLab은 다양한 방식의 백로그 관리를 지원하도록 확장할 수 있습니다. 이 튜토리얼에서는 다음과 같은 방식으로
산출물을 구조화합니다.
Mermaid 다이어그램 (7줄)소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart TD
accTitle: Deliverables structure
accDescr: Flowchart of features (epics) to job stories (issues) to implementation steps (tasks)
Epic["Feature (Epic)"] --> Issue["Job Story (Issue)"]
Issue --> Task["Implementation Step (Task)"]</code></pre></details></div>
-
에픽은 팀이 하나의 이터레이션에서 전달할 수 있는 기능을 나타냅니다.
-
각 에픽에는 여러 개의
잡 스토리가
포함됩니다.
- 스토리는 실질적인 고객 가치를 제공하고, 명시적인 승인 기준을 포함하며, 개인이 하루나 이틀 안에
완료할 수 있을 만큼 작아야 합니다.
- 팀 단위로는 스프린트당 스토리 4~10개를 완료해야 합니다.
-
기능을 분할하는 전략은 여러 가지가 있지만, 사용자가 목표를 달성하기 위해 거쳐야 하는 독립적인 개별
스토리로 수직 분할하는 것이
좋은 전략입니다.
고객에게 스토리 하나만 단독으로 출시하지 않더라도, 팀은 프로덕션이나 스테이징 환경에서 기능 플래그를
사용해 각 스토리를 테스트하고 다룰 수 있습니다. 이는 이해관계자가 스토리의 진행 상황을 파악할 수
있도록 돕는 동시에, 더 복잡한 기능을 다루기 쉬운 개발 목표로 나누는 메커니즘이기도 합니다.
-
스토리의 복잡도에 따라 태스크를 사용해 스토리를 개발자가 완료해야 하는 개별 구현 단계로 나눌 수
있습니다.
시간 범위 측면에서, 작업 항목의 크기와 범위를 정할 때는 다음 가이드라인을 목표로 합니다.
- 기능은 하나의 이터레이션 안에서 완료할 수 있습니다.
- 스토리는 며칠 안에 완료할 수 있습니다.
- 태스크는 몇 시간에서 하루 안에 완료할 수 있습니다.
예시: 기능을 수직으로 분할하기#
다음은 최종 사용자의 여정을 기준으로 기능을 수직으로 분할된 잡 스토리로 나누는 예시입니다.
Mermaid 다이어그램 (8줄)소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart TD
accTitle: Slicing a feature
accDescr: Use the end user's journey to identify slices of work to be completed in iterations
Epic["Epic: When using the application,<br>I need to create an account,<br> so I can use the application features"] --> Issue1["Issue: When creating my account,<br> I need to specify my email address,<br> so I can receive future updates from the application"]
Epic --> Issue2["Issue: When creating my account,<br> I need to specify a password,<br> so my account remains secure"]
Epic --> Issue3["Issue: When creating my account<br> and entering the required info,<br> I need to finalize creating my account,<br> so I can sign in"]
애플리케이션의 수정되지 않은 계정 생성 기능을 가져와 다음 세 가지 개별 스토리로 나누었습니다.
- 이메일 주소를 입력합니다.
- 비밀번호를 입력합니다.
- 버튼을 선택해 계정 생성을 실행합니다.
기능을 스토리로 나눈 후에는 스토리를 다시 개별 구현 단계로 세분화할 수 있습니다.
Mermaid 다이어그램 (10줄)소스 코드 보기
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart TD
accTitle: Break the story down further
accDescr: Split apart a story into smaller steps
Issue1["Issue: When creating my account,<br> I need to specify my email address,<br> so I can receive future updates from the application"]
Issue1 --> Task2["Task: Backend<br> Validate email formatting"]
Issue1 --> Task3["Task: Backend<br> API endpoint to accept<br> POST request from client"]
Issue1 --> Task4["Task: Frontend<br> Display email input"]
Issue1 --> Task5["Task: Frontend<br> Display error message when validation fails"]
릴리스 계획 보드 설정하기#
산출물 구조를 정의했습니다. 다음 단계는 기능 백로그를 만들고 유지 관리하는 데 사용할 에픽 보드를
만드는 것입니다.
새 에픽 보드를 만들려면 다음과 같이 진행합니다.
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
- 왼쪽 사이드바에서 Plan > Epic boards를 선택합니다.
- 왼쪽 상단에서 현재 보드 이름이 표시된 드롭다운 목록을 선택합니다.
- Create new board를 선택합니다.
- 새 보드의 제목으로
Release Planning을 입력합니다.
- Create board를 선택합니다.
다음으로 priority::later, priority::next, priority::now 레이블에 대한
리스트를 만듭니다.
새 리스트를 만들려면 다음과 같이 진행합니다.
- 보드의 오른쪽 상단에서 Create list를 선택합니다.
- New list 열에서 Select a label 드롭다운 목록을 펼치고 리스트 스코프로 사용할 레이블을
선택합니다.
- Add to board를 선택합니다.
이 리스트를 사용해 기능이 보드에서 왼쪽에서 오른쪽으로 이동하도록 진행합니다.
릴리스 계획 보드의 각 리스트를 사용해 다음과 같은 시간 범위를 나타냅니다.
- Open: 아직 우선순위를 지정할 준비가 되지 않은 기능입니다.
- Later: 이후 릴리스에 우선순위가 지정될 기능입니다.
- Next: 다음 릴리스로 잠정 계획된 기능입니다.
- Now: 현재 릴리스에 우선순위가 지정된 기능입니다.
- Closed: 완료되었거나 취소된 기능입니다.
첫 에픽 만들기#
다음으로 priority::now 리스트에 새 에픽을 만듭니다.
-
priority::now 리스트의 상단에서 New epic(+) 아이콘을 선택합니다.
-
새 에픽의 제목을 입력합니다.
When using the application, I need to create an account, so that I can use the application features.
-
Create epic을 선택합니다.
이 단계를 완료하면 보드는 다음과 같습니다.

이제 Release Planning 보드를 사용해 백로그를 빠르게 구축할 수 있습니다.
여러 기능을 만들어 Now, Next, Later 리스트에 우선순위를 지정합니다. 다음으로 시간을 들여
각 스토리를 스토리와 태스크로 더 세분화합니다.
리스트 안이나 여러 리스트에 걸쳐 기능 에픽의 순서를 바꾸려면 에픽 카드를 드래그합니다. 리스트의
맨 위나 맨 아래로 카드를 이동할
수도 있습니다.
스토리 백로그 관리하기#
기능을 에픽으로 정의했다면, 다음 단계는 그 기능을 이슈 단위의 세분화된 수직 슬라이스로 나누는 것입니다.
그런 다음 전용 백로그 보드에서 이터레이션에 걸쳐 이슈를 정제하고 순서를 정합니다.
기능을 스토리로 나누기#
효율적인 스프린트 계획 회의를 진행하려면 기능을 미리 수직으로 분할된 스토리로 나눕니다. 이전 단계에서
첫 기능을 만들었습니다. 이제 이를 스토리로 나눕니다.
첫 스토리를 만들려면 다음과 같이 진행합니다.
-
상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
-
왼쪽 사이드바에서 Plan > Epic boards를 선택합니다.
-
왼쪽 상단에서 현재 보드 이름이 표시된 드롭다운 목록에 Release Planning이 표시되는지 확인합니다.
표시되지 않으면 드롭다운 목록에서 해당 보드를 선택합니다.
-
에픽 카드의 제목을 클릭해 에픽을 엽니다.
-
Child issues and epics 섹션에서 Add > Add a new issue를 선택합니다.
-
이슈에 다음 제목을 입력합니다.
When creating my account, I need to specify my email address so that I can receive future updates from the application
-
Project 드롭다운 목록에서 이슈를 만들 프로젝트를 선택합니다.
-
Create issue를 선택합니다.
-
나머지 두 개의 수직 슬라이스에 대해서도 이 과정을 반복합니다.
When creating my account, I need to specify a password so that my account remains secure
When creating my account and entering the required information, I need to finalize creating my account so that I can sign in
스토리 백로그 정제하기#
이전 단계에서는 기능을 완료하는 데 필요한 사용자 스토리로 나누었습니다. 다음으로 스토리 백로그를
관리하고 정제하기 위한 정본 위치 역할을 할 이슈 보드를 설정합니다.
그룹에서 Backlog라는 제목의 새 이슈 보드를 만듭니다. 이 보드를 사용해 스토리를 향후 스프린트
(이터레이션)에 순서대로 배치하고 일정을 잡습니다.
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
- 왼쪽 사이드바에서 Plan > Issue boards를 선택합니다.
- 왼쪽 상단에서 현재 보드 이름이 표시된 드롭다운 목록을 선택합니다.
- Create new board를 선택합니다.
- 새 보드의 제목으로
Backlog를 입력합니다.
- Create board를 선택합니다.
보드를 만든 후 향후 각 이터레이션에 대한 새 리스트를 만듭니다.
- 이슈 보드 페이지의 오른쪽 상단에서 Create list를 선택합니다.
- 나타나는 열에서 Scope 아래의 Iteration을 선택합니다.
- Value 드롭다운 목록에서 이터레이션 중 하나를 선택합니다.
- Add to board를 선택합니다.
- 나머지 향후 이터레이션에 대해서도 이전 단계를 반복합니다.
그런 다음 이터레이션이 끝나면
완료된 이터레이션 리스트를 제거하고, 주기 설정에
따라 자동으로 만들어진 새로운 향후 이터레이션에 대한 리스트를 추가합니다.
이 시점에서는 스토리에 대한 추정이나 태스크로의 정제가 이루어지지 않은 상태입니다. 정제 대상으로
표시합니다.
- 보드에서 각 이슈의 카드를 선택하고
status::refine 레이블을 적용합니다.
- 사이드바의 Labels 섹션에서 Edit을 선택합니다.
- Select labels 목록에서
status::refine 레이블을 선택합니다.
- 레이블 섹션 바깥의 아무 곳이나 선택합니다.
- 세 스토리를 원하는 향후 스프린트로 드래그해 해당 스프린트 타임박스에 스토리를 할당합니다.
튜토리얼의 이 시점에서 Backlog 보드는 다음과 같습니다.

실제로는 이 보드를 사용해 많은 스토리를 향후 이터레이션에 순서대로 배치합니다. 백로그가 커지고 여러
기능에 걸친 수십 개의 스토리가 생기면,
Group by epic을 켜서 해당 기능
에픽과 관련된 스토리를 확인하면 도움이 됩니다. 스토리를 그룹화하면 향후 스프린트에 순서대로 배치하기가
더 쉬워집니다.
스프린트 계획 세리머니#
백로그가 준비되었다면 이제 향후 스프린트를 계획할 차례입니다. GitLab에서는 동기 방식과 비동기 방식
모두로 스프린트 계획 회의를 진행할 수 있습니다.
동기 계획#
스프린트 계획 세리머니 시간이 되면 팀과 함께 Backlog 보드를 열어 각 스토리를 검토합니다. 다음
스프린트에 대한 계획은 현재 스프린트의 마지막 날에 시작해야 합니다. 각 이슈를 논의하는 동안 다음을
진행합니다.
-
승인 기준을 검토하고 함께 작업합니다. 이는 체크리스트나 목록 항목을 사용해 이슈 설명에 기록할 수
있습니다.
-
각 구현 단계에 대해 스토리를 태스크로 더 세분화합니다.
-
이슈의 스토리 포인트 노력이나 복잡도를 추정하고 이 값을 이슈의 Weight 텍스트 박스에 설정합니다.
-
팀이 이슈의 범위에 만족하고 스토리 포인트 값에 합의했다면, 이슈에 status::ready 레이블을 적용합니다.
- 사이드바의 Labels 섹션에서 Edit을 선택합니다.
- Select labels 목록에서
status::ready 레이블을 선택합니다.
- 레이블 섹션 바깥의 아무 곳이나 선택합니다.
향후 이터레이션의 모든 이슈를 순회했다면 스프린트 계획이 완료된 것입니다.
팀의 속도(velocity)를 스프린트 커밋먼트에 반영하는 것을 잊지 않아야 합니다. 각 이터레이션 리스트의
상단에서 각 스프린트에 할당된 스토리 포인트(가중치)의 총합을 확인할 수 있습니다. 이전 스프린트에서
이월될 가능성이 있는 스토리 포인트도 함께 고려할 가치가 있습니다.
비동기 계획#
동기 회의를 여는 대신 이슈를 사용해 스프린트 계획을 진행할 수 있습니다.
비동기 스프린트 계획의 특성상, 현재 스프린트가 끝나기 며칠 전에 시작해야 합니다. 모든 팀원에게
기여하고 협업할 수 있는 적절한 시간을 제공합니다.
-
Backlog 이슈 보드를 엽니다.
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
- Plan > Issue boards를 선택합니다.
- 왼쪽 상단에서 현재 보드 이름이 표시된 드롭다운 목록을 선택합니다.
- Backlog를 선택합니다.
-
향후 스프린트에 대한 리스트에서 Create new issue(+)를 선택합니다.
-
이슈의 제목으로 Release Planning을 입력합니다.
-
Create issue를 선택합니다.
-
이슈를 열고 향후 스프린트에 할당된 각 스토리에 대한 토론 스레드를 만듭니다.
이슈 URL 끝에 +를 붙이면 제목이 자동으로 펼쳐집니다.
이슈 URL 끝에 +s를 붙이면 제목, 마일스톤, 담당자가 자동으로 펼쳐집니다.
이러한 스레드에는 다음 템플릿을 사용해 체크박스를 만들 수 있습니다.
## https://gitlab.example.com/my-group/application-b/-/issues/5+
- [ ] Acceptance criteria defined
- [ ] Weight set
- [ ] Implementation steps (tasks) created
예를 들면 다음과 같습니다.

-
모든 스토리에 스레드가 생겼다면 이슈 설명을 수정해
각 팀원을 멘션합니다. 팀원을 멘션하면 해당 팀원의
할 일 목록에 할 일 항목이 자동으로 만들어집니다.
-
그런 다음 향후 스프린트가 시작되기 전에 비동기적으로 팀원은 다음을 진행해야 합니다.
- 각 이슈를 논의하고 질문하며, 계획된 각 이슈의 승인 기준에 대해 협업해 합의를 이룹니다.
:one:, :two:, :three:와 같은 반응 이모지를 사용해 스토리 포인트(가중치)가 얼마여야 하는지
투표합니다. 팀원이 서로 다른 스토리 포인트 값을 설정했다면, 이는 합의에 이를 때까지 더 논의할
좋은 기회입니다. 다양한 반응을 평균해 스토리 포인트를 정할 수도 있습니다.
- 수직 슬라이스(이슈)를 구현 단계(태스크)로 나눕니다.
-
각 스토리에 대한 논의가 마무리되면 승인 기준의 변경 사항을 반영해 이슈를 업데이트하고 Weight
텍스트 박스에 스토리 포인트 값을 설정합니다.
-
스토리가 업데이트된 후 각 이슈에 status::ready 레이블을 추가합니다.
-
그런 다음 해당 수직 슬라이스에 대한 계획이 완료되었음을 알리기 위해 계획 이슈에서
각 토론 스레드를 해결합니다.
스프린트 진행 상황 추적하기#
스프린트 동안의 작업을 시각화하고 관리하기 위해 팀은 현재 스프린트의 범위를 나타내는 전용 이슈 보드를
만들 수 있습니다. 이 보드는 팀의 진행 상황과 잠재적인 블로커에 대한 투명성을 제공합니다. 팀은 번다운
차트를 통해 추가적인 가시성을 확보하기 위해 이터레이션 분석을 사용할 수도 있습니다.
현재 스프린트에 대한 보드 만들기#
그룹에서 Current Sprint라는 제목의 새 이슈 보드를 만듭니다.
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
- 왼쪽 사이드바에서 Plan > Issue boards를 선택합니다.
- 왼쪽 상단에서 현재 보드 이름이 표시된 드롭다운 목록을 선택합니다.
- Create new board를 선택합니다.
- 새 보드의 제목으로
Current Sprint를 입력합니다.
- Scope 옆에서 Expand를 선택합니다.
- Iteration 옆에서 Edit을 선택합니다.
- 이터레이션 주기 아래에서 Current를 선택합니다.
- Create board를 선택합니다.
이제 보드는 현재 이터레이션에 할당된 이슈만 표시하도록 필터링됩니다. 이를 사용해 진행 중인 스프린트에서
팀의 진행 상황을 시각화합니다.
다음으로 모든 상태에 대한 레이블 리스트를 만듭니다.
-
이슈 보드 페이지의 오른쪽 상단에서 Create list를 선택합니다.
-
나타나는 열에서 Scope 아래의 Label을 선택합니다.
-
Value 드롭다운 목록에서 레이블 중 하나를 선택합니다.
status::refine: 이슈가 개발되기 전에 추가 정제가 필요합니다.
status::ready: 이슈가 개발 준비 완료 상태입니다.
status::in progress: 이슈가 개발 중입니다.
status::review: 이슈에 해당하는 MR이 코드 리뷰를 진행 중입니다.
status::acceptance: 이슈가 이해관계자 승인 및 QA 테스트 준비 완료 상태입니다.
status::done: 이슈의 승인 기준이 충족되었습니다.
-
Add to board를 선택합니다.
-
나머지 레이블에 대해서도 이전 단계를 반복합니다.
그런 다음 스프린트가 진행되면서 이슈를 다른 리스트로 드래그해 status:: 레이블을 변경합니다.
스프린트의 번다운 차트와 번업 차트 확인하기#
스프린트 동안 이터레이션 리포트를 검토하면 도움이 됩니다. 이터레이션 리포트는 진행 상황 지표와 번다운
차트, 번업 차트를 제공합니다.
이터레이션 리포트를 확인하려면 다음과 같이 진행합니다.
- 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
- 왼쪽 사이드바에서 Plan > Iterations를 선택하고 이터레이션 주기를 선택합니다.
- 이터레이션을 선택합니다.