Jira의 Definition of Done: '완료'의 의미를 합의하세요

개발자가 변경을 끝내고 Jira 이슈를 다음 단계로 옮깁니다. 테스트 담당자는 새 화면은 작동하지만 기존 흐름이 깨졌음을 발견합니다. 지원팀은 혼란스러운 고객에게서 변경 소식을 듣습니다. 모두 '완료'라고 했지만 뜻은 달랐습니다.

Definition of Done은 공통 완료 기준을 제공합니다. 시작 전에 기대하는 품질 검사를 보이게 하므로 누가 적절한 질문을 기억하느냐에 덜 의존하게 됩니다.

가상의 고객 포털 사례에서 공통 품질 검사와 기능별 인수 기준을 구분하고, Power Pack의 Definition of Done & AC로 둘 다 Jira 이슈 옆에 배치하겠습니다.

Definition of Done이란 무엇인가요?

Scrum Guide는 이를 증분이 충족해야 하는 품질 기준으로 설명합니다. 완료된 작업에 대한 공통 이해를 제공하며 조직에 기준이 있으면 Scrum 팀의 최소 요건이 됩니다. 공식 Scrum Guide를 참고하세요.

실용적으로는 관련 변경마다 묻는 몇 가지 질문입니다. 구현을 검토했는가, 합의한 검증이 통과했는가, 변경을 지원할 정보가 준비되었는가를 확인합니다.

구체적인 질문은 제품과 위험에 달려 있습니다. 공개 포털, 내부 보고서, 안전이 중요한 시스템은 서로 다른 기준이 필요합니다. 다른 팀 목록을 논의 없이 복사하면 중요한 빈틈과 불필요한 일이 함께 생길 수 있습니다.

좋은 기준은 관찰 가능한 결과를 설명합니다. '높은 품질'은 목표지만 '합의한 회귀 검증이 통과했고 결과가 이슈에 연결됨'은 검토할 수 있는 조건입니다.

공통 품질과 기능 동작을 구분하세요

팀은 고객이 주간 요약 이메일을 켜고 끄는 알림 설정을 추가합니다. 중요한 계정 메시지는 이 설정의 대상이 아닙니다.

기능에는 자체 인수 기준이 필요합니다. 저장한 선택이 로그아웃 후 돌아와도 보여야 한다는 조건은 고객 경험을 설명하므로 이 기능에 속합니다.

Definition of Done은 더 넓은 완료 기준입니다. 구현 검토, 영향을 받는 기존 동작 확인, 지원 안내 갱신은 여러 변경에 공통으로 적용될 수 있습니다.

두 목록 모두 중요합니다. 요청대로 작동해도 필수 품질 작업이 빠질 수 있고, 코드 검토와 회귀 통과만으로 요청 기능의 올바른 동작이 증명되지는 않습니다.

팀이 실제로 보는 빈틈에서 시작하세요

개발, 검증, 지원 담당자를 모아 짧게 이야기하세요. 완료된 줄 알았지만 예상치 못한 후속 작업이 생긴 최근 사례를 사용합니다.

포털 팀은 반복되는 문제 세 가지를 찾습니다. 검토 의견이 미해결로 남고, 기존 계정 설정의 회귀 검증이 부족하며, 지원 안내가 기능 공개 후에 나옵니다.

문제는 유용한 점검 항목을 제시하고 목록을 짧게 유지할 이유도 줍니다. 각 항목은 알아볼 수 있는 실패를 막거나 필요한 품질 조건을 확인해야 합니다.

각 제안을 어떻게 검증할지 물으세요. 증거를 설명할 수 없다면 채택 전에 문구를 고칩니다. '문서 완료'는 릴리스 노트, 내부 설계, 고객 도움말 중 무엇인지 모호합니다. 필요한 정보와 위치를 합의하세요.

평소 계획 과정에서 누가 검사할지도 정하세요. 목록만으로 검토자가 지정되거나 시간이 확보되지는 않습니다.

실용적인 공통 목록을 작성하세요

다음은 팀의 첫 초안으로, 보편적인 표준이 아니라 예시 합의입니다.

• 구현 검토가 끝났고 필수 의견이 해결되었습니다.
• 이슈의 합의된 인수 기준이 검증되었습니다.
• 영향받는 계정 흐름의 합의된 회귀 검증이 통과했습니다.
• 변경 화면의 합의된 접근성 검증이 통과했습니다.
• 지원 안내가 달라진 고객 동작을 반영합니다.
• 검증 결과와 관련 검토 링크가 Jira 이슈에 기록되었습니다.

사용 전에 회귀 및 접근성 검사의 내용을 적어두세요. 그렇지 않으면 서로 다른 일을 하고 같은 문장을 체크할 수 있습니다.

포털 회귀 범위는 로그인, 계정 설정 열기, 기존 프로필 필드 수정입니다. 변경 컨트롤의 접근성 검토는 키보드 조작, 보이는 포커스, 이해되는 레이블을 포함합니다. 이 팀의 선택 예시이며 완전한 접근성 표준은 아닙니다.

지원 항목도 해석이 필요합니다. 고객에게 영향이 없는 변경은 미리 적절한 기준을 정하세요. 초록색 목록을 만들기 위해 검토자가 즉석에서 예외를 만들게 하지 마세요.

Jira 이슈에 기준을 추가하세요

관련 이슈의 Definition of Done & AC 카드를 여세요. Acceptance Criteria와 Definition of Done 탭이 분리되어 있습니다. 공통 점검을 넣기 전에 Definition of Done을 선택하세요.

짧은 목록은 제목을 입력하고 Add 또는 Enter를 선택합니다. 제목 하나는 검토 가능한 조건 하나에 집중해야 합니다. 무관한 검사 셋을 긴 문장에 넣으면 부분 완료를 표현하기 어렵습니다.

Bulk Import로 Markdown 목록을 붙일 수도 있습니다. 위 여섯 항목에 줄마다 하이픈과 공백을 붙이면 됩니다. 일반 Markdown 체크박스도 지원합니다.

가져오기는 선택한 탭에 추가됩니다. 확인 전 탭을, 가져온 후 목록을 점검하세요. 같은 내용을 다시 가져오면 중복될 수 있으므로 새로고침처럼 쓰지 마세요.

검증하지 않은 작업은 미체크로 넣으세요. 체크된 Markdown은 완료 상태로 들어오며 예전 이슈의 체크가 현재 검증을 대신하지 않습니다.

합의한 기준은 관련 이슈마다 수동으로 넣어야 합니다. 팀 문서에 기준본을 두고 적절한 항목을 새 이슈에 붙이세요. 중앙 기준과 모든 이슈를 자동 연결하는 기능이 아닌 팀의 관행입니다.

실제 검토를 진행하세요

알림 설정이 검토 준비되었다고 가정합니다. Maya는 고객 결과, Priya는 회귀 범위를 확인하고 Leo는 남은 구현 의견을 해결해 검토 기록을 연결합니다.

첫 검토에서 저장은 되지만 Save 선택 후 키보드 포커스가 사라집니다. 팀은 접근성 항목을 미완료로 두고 Jira에 문제를 기록한 뒤 수정하고 해당 검사를 반복합니다.

지원 안내도 아직 미완료입니다. 기능별 인수 기준이 다 끝났어도 이 작업은 보입니다. 분리된 목록은 남은 일이 있는 이유를 설명합니다.

실제로 통과하면 Done을 선택하세요. 새 정보로 다시 해야 한다면 한 번 더 선택합니다. 테스트 결과, 검토 링크, 중요한 결정은 평소 Jira나 문서 과정에 기록하세요.

완료 항목은 팀의 판단입니다. 검사를 실행하거나 증거를 모으거나 검증자를 확정하지 않습니다. 검토자 신원과 시간이 중요하면 평소 절차에 명시적으로 남기세요.

준비 상태 표시를 주의해서 읽으세요

각 탭의 완료 수와 전체 수가 표시됩니다. 두 목록에 최소 한 항목씩 있고 모두 완료되어야 Ready for Release가 됩니다. 아니면 In Verification입니다.

이 규칙은 열린 항목을 찾게 하고, Definition of Done이 끝나도 Acceptance Criteria가 비면 전체 완료가 되지 않는 이유를 설명합니다.

표시는 체크리스트 상태 요약일 뿐 검사 충분성, 증거 설득력, 안전한 출시를 증명하지 않습니다. 잘못 쓴 검사도 좋은 검사만큼 쉽게 완료 표시할 수 있습니다.

Jira 전환이나 pull request 병합도 차단하지 않습니다. 그런 결정은 기존 전달·출시 과정에서 계속 판단하세요.

작업이 바뀌어도 기준을 유용하게 유지하세요

반복 결함이 누락 검사를 드러내거나 제품이 크게 바뀌거나 기존 검사가 정보를 주지 못하면 기준을 검토하세요.

설정이 즉시 작동하지만 지연 동기화 후 실패할 수 있습니다. 이 발견은 지연 처리 기능의 더 넓은 검증 규칙으로 이어질 수 있습니다. 먼저 적용 대상과 성공 증거를 정하세요.

기준본을 수정하고 진행 중 작업에 적용할 방법을 논의합니다. 기존 이슈 목록은 자동 갱신되지 않으므로 영향을 살피고 필요한 새 검사를 수동으로 추가하세요.

단발성 실수마다 목록을 늘리지 마세요. 구체적인 인수 기준, 더 명확한 구현 작업, 검토 과정 개선이 나을 수도 있습니다. 공통 기준은 이해하고 실제 적용할 수 있어야 합니다.

현재 이슈 하나에 시도하세요

검토가 가까운 이슈를 고르세요. 짧은 공통 품질 기준은 Definition of Done에, 해당 고객 결과는 Acceptance Criteria에 넣습니다.

함께 검사를 진행하고 평소 위치에 증거를 연결하세요. 검증 후에만 완료하고 남은 작업은 일상적인 전달 과정에서 검토합니다.

이점은 명확한 대화입니다. 알림 설정이 끝났다고 할 때 어떤 결과가 작동하고 어떤 품질 검사가 통과했으며 무엇에 근거하는지 설명할 수 있습니다.

• Scrum Guide — Definition of Done