Columns settings

The columns settings include:

• Column constraint: which, as we discussed earlier, allows you to set minimum and maximum WIP limits for columns. The choices for Column Constraint is None, Issue Count, or Issue Count, excluding Sub-tasks.

• Days in Column: Shows dots representing the time an issue spent in a particular column on the board.

• Simplified Workflow: shows whether the board is using the Simplified Workflow or whether the Software Simplified Workflow is unavailable due to customization complexity.

• The rest of this configuration page is devoted to the mapping of columns and statuses. Let’s look closer at this mapping.

열 설정에는 다음이 포함됩니다:

• 열 제약 조건: 앞서 설명한 것처럼 열에 대한 최소 및 열에 대한 최대 WIP 제한을 설정할 수 있습니다. 열 제약 조건의 선택 항목은 없음, Issue 수, 또는 하위 작업을 제외한 이슈 수입니다.

• 열의 일수: 이슈가 보드의 특정 열에서 보낸 시간을 점으로 표시합니다. 시간을 나타내는 점을 표시합니다.

• 간소화된 워크플로: 보드가 간소화된 워크플로를 사용하고 있는지 또는 사용자 지정 복잡성으로 인해 소프트웨어 간소화된 워크플로를 사용할 수 없는지 여부를 표시합니다.

• 이 구성 페이지의 나머지 부분에서는 열 및 상태 매핑에 대해 설명합니다. 이 매핑을 자세히 살펴보겠습니다.

Boards and workflows are closely related. As we learned earlier, the board visualizes the workflow and the progress of work. In the simplest case, we have a board whose workflow only has 3 statuses: To Do, In Progress and Done. Each column only contains one status and both column and status have the same name. The columns of a board represent the steps of the process.

보드와 워크플로는 밀접한 관련이 있습니다. 앞서 배운 것처럼 보드는 워크플로와 작업 진행 상황을 시각화합니다. 가장 간단한 예로, 워크플로우에 3개의 상태만 있는 보드가 있습니다: 할 일, 진행 중, 완료. 각 열에는 하나의 상태만 포함되며 열과 상태의 이름은 모두 동일합니다. 보드의 열은 프로세스의 단계를 나타냅니다.

When a user drag-and-drops a card from one column to another, the issue is transitioned to the Status mapped to that column. In this case, issue changes status from To Do to In Progress.

사용자가 카드를 한 열에서 다른 열로 끌어서 놓으면 이슈가 해당 열에 매핑된 상태로 전환됩니다. 이 경우 이슈의 상태가 할 일에서 진행 중으로 변경됩니다.

And likewise, if you transition the issue from the issue view or perform a bulk operation, then – behind the scenes – the issue is moved to the corresponding column on all the boards where that issue appears.

마찬가지로 이슈 보기에서 이슈를 전환하거나 대량 작업을 수행하면 백그라운드에서 해당 이슈가 해당 이슈가 표시되는 모든 보드의 해당 열로 이동합니다.

So the issue status and issue location within a board column stay in sync.

따라서 보드 열 내의 이슈 상태와 이슈 위치가 동기화 상태로 유지됩니다.

This simple workflow and board configuration is, in fact, the default configuration of the Scrum board that is automatically created when Jira administrators create a new project using the Scrum software development template.
The project has multiple issue types and all of them use this same single Simplified Workflow.

이 간단한 워크플로 및 보드 구성은 실제로 Jira 관리자가 스크럼 소프트웨어 개발 템플릿을 사용하여 새 프로젝트를 만들 때 자동으로 생성되는 스크럼 보드의 기본 구성입니다.
프로젝트에는 여러 이슈 유형이 있으며 모두 동일한 단일 간소화된 워크플로를 사용합니다.

The Simplified Workflow is

• easy for team members to use and understand.

• It is managed automatically by Jira Software.

• It can only be used if a board represents a single project; and the workflow determines which statuses are available.

• All transitions are global so issues can be moved freely from any column to any other.

• There are no transition screens

• And no conditions or no validators

간소화된 워크플로우는

• 팀원들이 쉽게 사용하고 이해할 수 있습니다.

• Jira Software에서 자동으로 관리합니다.

• 보드가 단일 프로젝트를 나타내는 경우에만 사용할 수 있으며, 워크플로에 따라 사용 가능한 상태가 결정됩니다.

• 모든 전환은 전역이므로 이슈를 어느 열에서든 다른 열로 자유롭게 이동할 수 있습니다.

• 전환 화면이 없습니다.

• 조건이나 유효성 검사기도 없습니다.

• And it’s possible to add and remove statuses in a Simplified Workflow.

• To do so, you must be either a Jira Administrator

• or a project administrator who is also a board administrator. Because of course, you must be a board administrator to modify any of the board configurations.

• 또한 간소화된 워크플로에서 상태를 추가 및 제거할 수 있습니다.

• 이렇게 하려면 Jira 관리자이거나

• 또는 보드 관리자이기도 한 프로젝트 관리자여야 합니다. 물론 보드 구성을 수정하려면 보드 관리자여야 합니다.

Here, the Approval status and column was added to the Scrum board.

여기에서 스크럼 보드에 승인 상태 및 열이 추가되었습니다.

Meanwhile, here is the default configuration of a Kanban board. Its status and columns are Backlog, Selected for Development, In Progress, and Done.
It is automatically created this way when a Jira administrator creates a new project using the Kanban software development project template.

한편, 다음은 칸반 보드의 기본 구성입니다. 상태 및 열은 Backlog, Selected for Development, In Progress 및 Done입니다.
Jira 관리자가 칸반 소프트웨어 개발 프로젝트 템플릿을 사용하여 새 프로젝트를 만들 때 자동으로 이러한 방식으로 만들어집니다.

To enable the Kanban backlog, you drag the Backlog status to the leftmost area designated for this purpose. Then delete the Backlog column itself. When you return to the board, you will see the Backlog view as we learned earlier.

칸반 백로그를 활성화하려면 백로그 상태를 이 용도로 지정된 가장 왼쪽 영역으로 끌어다 놓습니다. 그런 다음 백로그 열 자체를 삭제합니다. 보드로 돌아오면 앞서 배운 대로 백로그 보기가 표시됩니다.

So far, this has been rather straightforward. But remember that a board displays the issues returned by the JQL query of its board filter. And that can get complex.

지금까지는 다소 간단했습니다. 하지만 보드는 보드 필터의 JQL 쿼리가 반환한 이슈를 표시한다는 점을 기억하세요. 그리고 그것은 복잡해질 수 있습니다.

We will start easy with one project, DEV, and one issue type, Story. Stories are indicated by a little green Story icon and a green bar on the left of each card. That’s because the board is configured to display colors by issue type. We will look at card colors later.

하나의 프로젝트인 DEV와 하나의 이슈 유형인 스토리로 쉽게 시작하겠습니다. 스토리는 각 카드의 왼쪽에 작은 녹색 스토리 아이콘과 녹색 막대로 표시됩니다. 보드가 이슈 유형별로 색상을 표시하도록 구성되어 있기 때문입니다. 나중에 카드 색상에 대해 살펴보겠습니다.

Now we add a second issue type, Bug, indicated by a red icon and red card color. Still from the same project.

이제 빨간색 아이콘과 빨간색 카드 색상으로 표시되는 두 번째 이슈 유형인 버그를 추가합니다. 여전히 같은 프로젝트에 있습니다.

Or – most commonly – let’s show all issue types from a project. We add 2 Tasks, as indicated by the blue icon and blue card color. We will skip Epics and Sub-tasks for now.

또는 가장 일반적으로 프로젝트의 모든 이슈 유형을 표시해 보겠습니다. 파란색 아이콘과 파란색 카드 색상으로 표시된 대로 2개의 작업을 추가합니다. 지금은 에픽과 하위 작업은 건너뛰겠습니다.

Now we add 3 issues (1 Bug and 2 Tasks) from a second project, TIS.

이제 두 번째 프로젝트인 TIS 에서 3개의 이슈(버그 1개, 작업 2개)를 추가합니다.

And 2 more issues from TIS with a new issue type, Request, indicated by an orange question mark icon and orange card color.

그리고 주황색 물음표 아이콘과 주황색 카드 색상으로 표시되는 새로운 이슈 유형인 요청이 있는 TIS의 이슈가 2개 더 있습니다.

The complexity comes with the possibility of multiple workflows.

• For example: Dev Workflow Scheme

• uses the Story workflow for Stories with the statuses Backlog, In Progress, Done.

• The Bug workflow for Bugs with the statuses New, In Progress, Awaiting QA, Resolved.

• And Task Workflow for Tasks with the statuses To Do, Working, Review, Closed.

복잡성에는 여러 워크플로의 가능성이 수반됩니다.

• 예를 들어 Dev Workflow Scheme

• 는 Backlog, In Progress, Done 상태가 있는 스토리에 Story 워크플로를 사용합니다.

• New, In Progress, Awaiting QA, Resolved 상태의 Bug에는 버그 워크플로를 사용합니다.

• 그리고 To Do, Working, Review, Closed 상태의 작업에 대한 Task 워크플로우를 사용합니다.

And because there are TIS issues in the board filter for the board, then

• the TIS workflow Scheme is also reflected on the board.

• The TIS project introduced the TIS Request workflow for Requests that has the statuses Open, In Progress, Done.

• And just because TIS also uses the Bug and Task issue types, it doesn’t mean that their workflows are the same as the ones in the DEV project. They could be different, as well.

그리고 보드에 대한 보드 필터에 TIS 이슈가 있기 때문에

• TIS workflow Scheme도 보드에 반영됩니다.

• TIS 프로젝트에서는 Open, In Progress, Done 상태가 있는 요청에 대한 TIS 요청 워크플로우를 도입했습니다.

• TIS에서도 버그 및 작업 이슈 유형을 사용한다고 해서 그 워크플로가 DEV 프로젝트의 워크플로우와 동일하다는 의미는 아닙니다. 서로 다를 수도 있습니다.

Such complex boards are difficult for users to understand and for administrators to maintain.

• That is why it is best practice to keep the workflows as simple as possible and to share workflow schemes among projects, especially those projects where the teams may work together in a single board. Jira has a process that can be performed by Jira administrators to help simplify workflows.

There are a lot more caveats when it comes to boards with multiple teams, projects, issue types, etc. – not just when it comes to workflows but also permissions and other configurations. We will return to those caveats in our final module. For now, let’s just return to our Kanban board configuration for three more concepts.

이렇게 복잡한 보드는 사용자가 이해하기 어렵고 관리자가 유지 관리하기도 어렵습니다.

• 그렇기 때문에 워크플로를 최대한 단순하게 유지하고 프로젝트, 특히 팀이 단일 보드에서 함께 작업할 수 있는 프로젝트 간에 워크플로 체계를 공유하는 것이 가장 좋습니다. Jira에는 워크플로를 간소화하는 데 도움이 되도록 Jira 관리자가 수행할 수 있는 프로세스가 있습니다.

여러 팀, 프로젝트, 이슈 유형 등이 있는 보드의 경우 워크플로뿐만 아니라 훨씬 더 많은 주의 사항이 있습니다. - 워크플로뿐만 아니라 권한 및 기타 구성과 관련하여 더 많은 주의 사항이 있습니다. 이러한 주의 사항은 마지막 모듈에서 다시 다루겠습니다. 지금은 칸반 보드 구성으로 돌아가 세 가지 개념을 더 살펴보겠습니다.

The first concept is Unmapped statuses. Statuses must be mapped to an appropriate column in order to be visible on the board. Here, Reviewing and Testing appear in the rightmost area of the board under the heading Unmapped Statuses. These statuses are part of one or more workflows on the board but have not been mapped to any columns. There may or may not be issues in those statuses. But if there are, then they will not be visible on the board.

As a best practice, all statuses should be mapped to a column. Of course, there may be situations where a board administrator chooses to leave some statuses off the board.

첫 번째 개념은 매핑되지 않은 상태입니다. 상태가 보드에 표시되려면 적절한 열에 매핑되어야 합니다. 여기서 Reviewing 및 Testing는 보드의 가장 오른쪽 영역에 매핑되지 않은 상태라는 제목 아래에 표시됩니다. 이러한 상태는 보드에 있는 하나 이상의 워크플로의 일부이지만 열에 매핑되지 않은 상태입니다. 이러한 상태에는 이슈가 있을 수도 있고 없을 수도 있습니다. 하지만 이슈가 있는 경우 보드에 표시되지 않습니다.

모범 사례로 모든 상태를 열에 매핑하는 것이 좋습니다. 물론, 보드 관리자가 일부 상태를 게시판에 표시하지 않기로 선택하는 상황이 있을 수 있습니다.

So the second concept is mapping multiple statuses to a column. A column can contain two or more statuses which can be ordered horizontally, so we can take those two unmapped statuses and…

두 번째 개념은 여러 상태를 열에 매핑하는 것입니다. 열에는 수평으로 정렬할 수 있는 두 개 이상의 상태가 포함될 수 있으므로 매핑되지 않은 상태 두 개를 가져와서...

Put them in the Working column, which now has 3 statuses mapped to it.

이제 3개의 상태가 매핑된 작업 열에 배치합니다.

And as a best practice, you should name columns appropriately, especially in these kinds of scenarios where there are multiple statuses.

• So in this case, we renamed the column to “In Process” since it now contains more than just the Working status.

특히 여러 상태가 있는 이런 종류의 시나리오에서는 열 이름을 적절하게 지정하는 것이 좋습니다.

• 이 경우에는 열에 작업 중 상태만 있는 것이 아니라 여러 상태가 포함되어 있으므로 열 이름을 "In Process"으로 변경했습니다.

The final concept is Definition of Done. Column configuration is important, particularly the leftmost and rightmost column.

마지막 개념은 완료의 정의입니다. 열 구성, 특히 가장 왼쪽과 가장 오른쪽 열이 중요합니다.

You can see that each column has a dark gray, blue or green color as shown here.

The single leftmost column will always be dark gray, representing items in a “To Do” state, so it can be statuses like Open, New, To Do, or Backlog as shown here.

The single rightmost column will always be green, representing items in a “Done” state (as per design guidelines) and it can be statuses like Done, Closed, Resolved.

The middle column (or columns if you add more) are always blue, representing items in progress. So here it includes the Selected for Development column and status, and the In Process column with its three statuses.

The definition of Done has an impact on reports. A number of reports and gadgets show data related to whether an issue is new, in progress or completed. And in simplified workflows, dragging an issue to the Done column (regardless of what statuses are in there) will set the Resolution to Done.

다음과 같이 각 열의 색상이 짙은 회색, 파란색 또는 녹색인 것을 확인할 수 있습니다.

가장 왼쪽 열은 항상 짙은 회색으로 '할 일' 상태의 항목을 나타내므로 여기에 표시된 것처럼 열기, 새로 만들기, 할 일 또는 백로그와 같은 상태가 될 수 있습니다.

가장 오른쪽에 있는 하나의 열은 항상 녹색으로 표시되며, 디자인 가이드라인에 따라 '완료' 상태의 항목을 나타내며 완료, 종료, 해결 등의 상태가 될 수 있습니다.

가운데 열(또는 열을 더 추가하는 경우 열)은 항상 파란색으로 표시되며 진행 중인 항목을 나타냅니다. 따라서 여기에는 개발용으로 선택됨 열과 상태, 그리고 세 가지 상태의 진행 중 열이 포함됩니다.

완료의 정의는 보고서에 영향을 미칩니다. 많은 보고서와 가젯은 이슈가 신규, 진행 중 또는 완료되었는지 여부와 관련된 데이터를 표시합니다. 그리고 간소화된 워크플로에서 이슈를 완료 열로 드래그하면(어떤 상태인지와 관계없이) Resolution이 완료로 설정됩니다.

This example demonstrates the various things we have just covered.

1. We can see that the Kanban backlog is enabled. Issues in Backlog status are visible in a separate backlog view.

2. Kanban backlog will show the Epics Panel because the setting is enabled, as well.

3. Work in progress limits are enabled because Column Constraint setting says “Issue Count”. In some columns, the minimum and/or maximum number of issues will define whether a yellow or red highlight will be displayed to bring attention to exceeded limits.

4. Issues dragged to Done column have their Resolution set and are considered Resolved in reports, gadgets, etc.

5. Issues in the Review status will not display on the board because the status is not mapped.

6. Also, we see two statuses mapped to one of the columns. So when dragging-and dropping an issue from the In Progress column, the user will be able to choose either status to transition to.

7. And which workflow is the board using? The Simplified Workflow which means there are no conditions or validators, and all transitions are global.

이 예는 방금 다룬 다양한 내용을 보여줍니다.

1. 칸반 백로그가 활성화된 것을 볼 수 있습니다. 백로그 상태의 이슈는 별도의 백로그 보기에서 볼 수 있습니다.

2. 설정이 활성화되어 있으므로 칸반 백로그에 에픽 패널도 표시됩니다.

3. 열 제약 조건 설정에 "이슈 수"라고 되어 있으므로 진행 중인 작업 제한이 활성화되어 있습니다. 일부 열에서는 최소 및/또는 최대 이슈 수에 따라 한도 초과 시 주의를 환기하기 위해 노란색 또는 빨간색 하이라이트를 표시할지 여부가 정의됩니다.

4. 완료 열로 드래그한 이슈는 해결이 설정되어 있으며 보고서, 가젯 등에서 해결된 것으로 간주됩니다.

5. 검토 상태의 이슈는 상태가 매핑되지 않았으므로 보드에 표시되지 않습니다.

6. 또한 열 중 하나에 두 개의 상태가 매핑되어 있습니다. 따라서 진행 중 열에서 이슈를 끌어서 놓을 때 사용자는 전환할 상태를 선택할 수 있습니다.

7. 보드에서는 어떤 워크플로를 사용하나요? 단순화된 워크플로로 조건이나 유효성 검사기가 없으며 모든 전환이 전역적으로 이루어집니다.