%%{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 .-&gt;|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)"] --&gt; Issue["Job Story (Issue)"]
Issue --&gt; 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 레이블을 선택합니다.
레이블 섹션 외부의 아무 곳이나 선택합니다.



다가오는 이터레이션의 모든 이슈를 순환한 후 스프린트 계획이 완료됩니다!
팀의 속도를 스프린트 커밋에 포함하는 것을 기억합니다. 각 이터레이션 목록 상단에서 각 스프린트에 할당된 총 스토리 포인트(가중치) 수를 찾을 수 있습니다. 이전 스프린트에서 넘어올 가능성이 있는 스토리 포인트도 확인하는 것이 좋습니다.
비동기적 계획#
동기 회의를 개최하는 대신 이슈를 사용하여 스프린트 계획을 실행합니다.
비동기 스프린트 계획의 특성상 현재 스프린트 종료 며칠 전에 시작해야 합니다. 모든 팀원이 기여하고 협업할 적절한 시간을 제공합니다.


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를 선택하고 이터레이션 케이던스를 선택합니다.
이터레이션을 선택합니다.