Jira 백로그 이월
“완료 열과 남은 일을 먼저 확인해요”
Jira에서 스프린트를 마치기 전에는 보드의 마지막 열과 남은 작업의 다음 위치를 먼저 확인하세요. 카드에 개발 완료라고 써 있어도 보드가 판단하는 완료와 팀이 합의한 품질 조건이 다를 수 있어요. 그대로 종료하면 시험을 기다리는 작업이 다음 계획에 섞이고, 회의에서는 끝났다고 들은 기능이 다시 나타나는 상황이 생깁니다. 백로그 정리를 맡았다면 카드를 옮기는 조작보다 남은 이유와 책임자를 함께 확인하는 과정이 필요하죠. 아래의 계정 설정과 보고서 해석은 Jira Cloud 공식 안내 범위로 제한하며, 가상 예약 서비스의 미완료 작업을 어떻게 기록할지 편집 예시로 제안합니다. 실제 고객 프로젝트의 성공 사례나 특정 팀의 처리 속도를 확인한 글은 아니에요. 사용하는 공간 유형과 권한을 먼저 대조한 뒤 적용해 보세요.
| 상황 | 확인할 자료 | 다음 결정 |
|---|---|---|
| 시험 대기 | 시험 결과와 완료 기준 | 완료 여부 확인 |
| 외부 응답 대기 | 문의 내용과 담당자 | 이동 위치 합의 |
| 시작일 불일치 | 실제 활동과 시작 기록 | 보고서 해석 보완 |
어떤 공간의 안내를 따라야 하나요?
팀 관리형과 회사 관리형을 먼저 구분하세요. 같은 Jira Cloud라도 설정과 사용 가능한 조작이 달라질 수 있어요.
메뉴 이름이 검색한 안내와 다르다면 권한부터 바꾸기 전에 공간 유형을 확인해 보세요. 공식 문서는 두 유형을 나누어 설명하므로, 다른 유형의 화면을 기준으로 종료 버튼이 사라졌다고 판단하면 원인을 잘못 찾을 수 있습니다.
가상 예약 서비스에서 팀 관리형 개발 보드와 회사 관리형 운영 보드를 함께 쓴다고 가정해 볼게요. 회의록에는 보드 이름과 공간 유형을 함께 기록하고, 실제 카드를 이동할 담당자에게 어느 목록을 기준으로 말하는지 확인하세요.
스크럼의 행사 목적과 도구의 설정은 구분해야 합니다. 도구에서 기능을 켰다고 팀이 같은 완료 기준에 합의한 것은 아니에요.
화면을 공유할 때에는 개인정보와 내부 고객 정보를 가리고, 예시 티켓은 가상임을 표시하세요.
완료로 보이는 카드가 왜 남아 있나요?
팀 관리형 공식 안내에서 스프린트 완료 여부는 보드의 마지막 열을 기준으로 판단합니다. 업무 제목에 붙인 완료 문구만으로는 같아지지 않아요.
가상 사례에서 개발자가 예약 오류 수정을 끝냈지만 카드가 시험 대기 열에 있다고 생각해 보세요. 기능 작업의 일부를 끝냈다는 설명과 전체 작업이 끝났다는 설명은 다릅니다.
종료 직전에는 마지막 열에 무엇이 들어가 있는지와 그 열로 이동하기 위한 팀의 확인 절차를 함께 살펴보세요. 상태 이름을 보고 추정한 뒤 카드를 일괄 이동하면 아직 확인하지 않은 작업까지 완료처럼 표시할 수 있어요.
품질 조건에 맞지 않는 작업은 이유를 보존하고 남은 일을 적어 두세요. 품질보증과 연결한 시험 자료가 있다면 결과 위치도 함께 남겨 보세요.
마지막 열은 도구의 판단 기준이며 실제 출시 승인이나 계약상 인수까지 대신하지 않습니다.
남은 카드는 다음 스프린트로 보내나요?
종료 화면의 이동 선택과 다음 계획의 수용 결정은 구분하세요. 자동으로 이월됐다는 이유만으로 새 목표에 필요한 작업이라고 단정할 수 없어요.
가상 예약 오류가 외부 연계 응답을 기다리다가 멈췄다면 같은 카드를 다음 기간으로 옮겨도 기다리는 이유는 그대로예요. 남은 작업에는 미완료 이유, 필요한 응답, 연락할 담당자와 다시 판단할 조건을 적어 보세요.
팀 관리형 종료 화면에서는 미완료 작업을 백로그나 다른 스프린트로 옮길 수 있어요. 어느 쪽을 선택할지는 팀의 다음 계획과 함께 정해야 하죠.
Risk(위험) 목록과 연관된 의존성이라면 같은 사실을 새 문장으로 중복 관리하기보다 확인할 기록을 연결하세요. 이월한 개수를 줄이려고 작업을 급히 쪼개거나 점수를 바꾸면 이전 계획과 비교하기 어려워집니다.
먼저 실제로 끝난 범위와 남은 범위를 이해할 수 있게 설명하세요.
예정 시작일과 실제 시작일은 왜 구분하나요?
Jira의 예정일과 시작 시점은 보고서 해석에 반영돼요. 일정표를 예쁘게 맞추려고 실제 진행 이력을 바꾸지 마세요.
시작 동작 때 제안되는 시각은 계획해 둔 시작일과 다를 수 있어요. 팀은 업무가 언제 시작됐는지와 도구의 시작 동작을 언제 수행했는지 함께 확인해 두는 것이 좋아요.
가상 프로젝트에서 월요일 회의가 미뤄져 수요일에 도구상 스프린트를 시작했다면, 이전 활동이 보고서에 어떻게 반영되는지 묻는 질문이 필요합니다. 차이를 모른 채 과거 그래프를 비교하면 업무량 변화와 기록 시점의 차이를 혼동할 수 있죠.
기준선의 기준 일정과 실제 날짜가 다르듯 각각의 의미를 보존하세요. 날짜 조정이 필요하면 변경 이유와 확인자를 남기고, 과거에 없던 합의나 완료 이력을 새로 만든 것처럼 설명하지 않습니다.
종료 회의에는 어떤 기록을 가져가나요?
남은 작업 목록과 다음 판단에 필요한 자료를 가져가세요. 스프린트 종료 조작은 리뷰나 회고에서 필요한 대화를 대신하지 않아요.
가상 회의에서는 예약 오류의 시험 결과, 외부 연계 답변, 다음 기간에 이용할 수 있는 담당자의 시간을 함께 보도록 제안할 수 있어요. 이 자료들은 실제 측정 결과가 아니라 기록 방법을 보여 주는 편집 예시입니다.
제품 결과를 어떻게 바꿀지와 일하는 방식을 어떻게 개선할지는 서로 다른 결정이므로 별도 문장으로 적어 보세요. 종료 버튼을 누른 사람이 모든 후속 업무의 책임자가 되는 것도 아닙니다.
결정된 사항에는 담당자와 다시 확인할 사건을 연결하고, 답이 나오지 않은 질문은 미확인으로 남겨 두세요. 다음 회의에서는 이전 미완료 이유가 해소됐는지를 먼저 확인할 수 있습니다.
메뉴 조작을 마쳤다는 보고와 실제 남은 일을 해결했다는 보고를 구분하면 목록을 읽는 사람도 현재 상태를 파악하기 쉬워요.
합의 전에 확인했나요?
- 공간 유형과 보드를 확인했나요?
- 미완료 이유와 이동 위치를 합의했나요?
- 실제 날짜와 보고서의 기준을 구분했나요?
자주 묻는 것
- 완료라고 이름 붙이면 종료에 포함되나요?
- 보드가 사용하는 완료 판단과 팀 품질 조건을 확인해야 합니다. 이름만 바꾸어 미완료 작업을 완료로 만들지 마세요.
- 이월 카드는 다음 계획에서 다시 보나요?
- 다음 목표와 남은 이유를 함께 검토하는 편집 절차를 권합니다. 자동 이월과 착수 합의는 다릅니다.
- 회사 관리형에도 같은 화면이 있나요?
- 이 글의 종료 예시는 팀 관리형 안내 범위입니다. 회사 관리형은 해당 공식 문서를 별도로 대조하세요.
관련 용어
출처
다른 가이드