Jira 인수 기준 작성법: 실용적인 예시

'고객이 알림 설정을 바꿀 수 있다'는 개발을 시작하기 전에는 명확해 보입니다. 즉시 저장될까요? 저장 실패 시에는요? 내일도 남아 있을까요? 어떤 이메일에 영향을 줄까요?

인수 기준은 열린 질문을 합의된 관찰 가능 결과로 바꿉니다. 변경을 요청하고 만들고 검토하는 사람들이 같은 기대를 갖게 합니다.

가상 포털 기능의 기준을 만들고 모호한 요구를 개선한 뒤 Definition of Done & AC에 목록을 추가하겠습니다. 특별한 형식은 필요하지 않습니다. 명확한 조건과 결과면 충분합니다.

인수 기준이란 무엇인가요?

특정 작업이 수용되려면 충족해야 하는 조건이며 그 항목의 결과에 집중합니다. Atlassian은 이를 완료 작업의 더 넓은 품질 기준인 Definition of Done과 구분합니다. Atlassian 인수 기준 안내를 참고하세요.

'저장한 알림 선택이 다시 로그인해도 유지된다'는 인수 기준입니다. '구현이 검토되었다'는 공통 Definition of Done에 속합니다.

구분 덕분에 두 목록이 유용합니다. 인수 기준은 기능이 합의를 지켰는지, Definition of Done은 더 넓은 팀 완료 기준을 지켰는지 설명합니다.

모든 구현 단계를 담을 필요는 없습니다. '데이터베이스 필드 생성'은 필요해도 고객이나 검토자에게 설정의 올바른 동작을 설명하지 않습니다.

고객 결과 하나에서 시작하세요

예시 이슈는 '고객이 주간 요약 이메일을 제어하게 하기'입니다. 로그인한 고객이 필수 계정 메시지에 영향 없이 주간 요약 수신을 선택하는 것이 목표입니다.

팀은 먼저 범위를 정합니다. 명시적인 Save 버튼이 있고 고객은 자기 설정만 바꿉니다. 아직 발송 대기열에 들어가지 않은 요약에만 적용되며 이미 대기 중인 메시지는 이 이슈의 규칙 밖입니다.

이 세부사항은 예시를 위해 만든 것입니다. 제품 요구사항으로 복사하지 말고 실제 동작은 팀이 정하세요.

짧은 범위 설명을 두면 긴 목록이 모든 맥락을 짊어지지 않습니다. Jira 설명에는 계정 설정 페이지의 한 선호 항목만 포함한다고 적습니다. 발송일 선택, 이메일 주소 변경, 다른 고객 설정 관리는 별도 작업입니다.

이제 이 변경이 작동하는지 입증하는 결과에 집중할 수 있습니다.

정상 경로부터 쓰세요

대부분 고객이 따를 경험으로 시작합니다. 시작 조건, 행동, 관찰 가능한 결과를 일상 언어로 적으세요.

예를 들어 '로그인한 고객이 주간 요약을 끄고 저장에 성공하면 계정 설정을 다시 열었을 때 꺼져 있다'입니다. 검토자는 시작 상태를 만들고 행동한 후 결과를 볼 수 있습니다.

'설정이 제대로 저장된다'보다 어떤 설정이 언제 반영되고 어떻게 확인하는지 분명합니다.

반대 방향도 필요합니다. 끌 수 있지만 켤 수 없는 컨트롤은 미완성입니다. 역방향 동작을 별도로 검증할 가치가 있으면 따로 적으세요.

무관한 결과를 한 항목에 억지로 넣지 마세요. 저장, 키보드, 이메일, 오류 처리가 모두 중요해도 거대한 기준은 어디가 남았는지 표현하기 어렵습니다.

실패와 경계 사례를 추가하세요

정상 경로는 저장 성공을 가정합니다. 실패하면 고객에게 무엇이 보여야 할까요?

팀은 실패 요청 시 오류를 보이고 성공 확인은 표시하지 않으며, 다시 열면 기존 저장값을 유지하기로 합니다. 테스트 환경에서 실행할 구체적 실패 사례가 생깁니다.

다음으로 경계를 보세요. 주간 요약 설정은 비밀번호 재설정 이메일을 막으면 안 되고 새 로그인 세션에서도 유지되어야 합니다. 서로 다른 관심사이므로 별도 기준으로 둡니다.

'모든 예외 처리'라고 쓰지 말고 중요한 사례를 명시하세요. 무엇이 실패할 수 있는지, 무엇이 영향받으면 안 되는지, 나중에 무엇이 일어나는지가 좋은 출발 질문입니다.

기대 결과를 합의하지 못했다면 구현이 너무 진행되기 전에 미결 결정을 적으세요. 답 없는 질문은 목록에 넣는다고 쓸 만한 기준이 되지 않습니다.

완성된 인수 기준 예시

다음은 가상 이슈의 첫 전체 초안이며 각 결과를 따로 검증할 수 있습니다.

• 계정 설정을 열면 현재 저장된 주간 요약 선택이 표시됩니다.
• 요약을 끄고 저장에 성공한 뒤 다시 열면 꺼진 상태입니다.
• 요약을 켜고 저장에 성공한 뒤 다시 열면 켜진 상태입니다.
• 저장 성공 후 로그아웃하고 다시 로그인해도 선택이 유지됩니다.
• 저장 실패 시 오류가 보이고 성공 확인은 없으며 다시 열면 이전 저장값이 보입니다.
• 꺼진 고객에게는 성공적 저장 이후 새로 대기열에 들어간 주간 요약이 발송되지 않습니다.
• 켜진 고객은 기존 일정 규칙에 따라 다음 주간 요약을 받을 대상입니다.
• 주간 요약을 꺼도 고객이 요청한 비밀번호 재설정 이메일은 수신할 수 있습니다.

발송 기준은 대기 메시지에 대한 범위 결정에 달려 있습니다. 이미 보내는 이메일까지 회수한다고 오해하지 않도록 그 맥락을 이슈에 기록하세요.

실행 가능한 검증 방법도 필요합니다. 테스트 환경에서 요약을 어떻게 발생시키거나 관찰할지 정합니다. 문장이 명확해도 계정이나 발송 증거에 접근할 수 없다면 검증은 어려울 수 있습니다.

추가 전에 모호한 기준을 개선하세요

짧은 문구 검토가 긴 후속 논쟁을 막습니다. 두 사람이 성공을 다르게 해석할 수 있는지 각 항목을 읽어보세요.

마지막 예시만으로 사용성이 증명되지는 않습니다. 모호한 문장을 유용하지만 제한적인 검사로 바꾼 것입니다. 넓은 사용성 목표에는 연구나 여러 합의된 관찰이 필요할 수 있습니다.

만들어낸 정밀성도 조심하세요. 2초 응답 조건은 측정 가능해 보이지만 실제 약속입니다. 성능 한계를 넣기 전에 조건과 이유를 합의하세요.

Power Pack에 기준을 넣으세요

이슈의 Definition of Done & AC 카드에서 Acceptance Criteria를 선택하세요. Definition of Done과 별도 목록이므로 입력 전에 탭을 확인합니다.

단일 기준은 제목을 입력하고 Add 또는 Enter를 누릅니다. 짧게 쓰되 기대 결과는 남기세요. 긴 맥락은 Jira 설명이나 연결 문서에 둡니다.

여러 항목은 Bulk Import에서 Markdown 글머리 목록으로 붙입니다. 예시 앞에 하이픈과 공백을 넣어도 되고 Markdown 체크박스 목록도 지원합니다.

가져온 결과를 확인하세요. 현재 목록에 덧붙이므로 반복하면 중복될 수 있습니다. 체크된 Markdown은 완료로 들어오므로 현재 결과를 실제 확인하지 않았다면 미체크로 시작하세요.

항목이 틀리면 팀과 문구를 검토하고 수정 항목을 추가한 다음 확인 메시지를 거쳐 오래된 항목을 삭제하세요. 합의 범위가 달라지면 관련 논의도 명확히 유지하세요.

완료 표시 전에 결과를 검토하세요

구현 전에 검증 참여자에게 기준을 살펴보게 하세요. 시작 조건 누락이나 현재 테스트 환경에서 관찰 못 하는 결과를 찾을 수 있습니다.

구현 후 각 결과를 확인하고 증거를 평소 Jira·문서 과정에 남깁니다. 통과하면 Done을 선택하고, 후속 발견으로 재검증이 필요하면 다시 선택해 할 일로 돌립니다.

예를 들어 페이지 새로고침에는 유지되지만 새 로그인에서 초기화될 수 있습니다. 페이지 재열기 기준은 통과하고 세션 유지 기준은 남습니다. 분리된 항목은 이 차이를 보존합니다.

Power Pack은 목록 완료를 추적하며 테스트를 실행하거나 검토자를 자동 확정하지 않습니다. 이름이나 날짜가 필요한 검증은 정상 절차에 명시적으로 기록하세요.

두 개수를 활용하되 증명으로 보지는 마세요

Acceptance Criteria와 Definition of Done은 각각 완료와 전체 개수를 보여줍니다. 두 목록이 비어 있지 않고 전부 완료해야 Ready for Release이며, 아니면 In Verification입니다.

입력된 상태의 요약일 뿐 모든 중요 동작의 포괄성이나 증거의 타당성을 확인하지 않습니다. Jira 전환을 강제하거나 병합을 막지도 않습니다.

알림 이슈의 여덟 기준이 끝나도 Definition of Done의 지원 안내는 미완료일 수 있습니다. 기능 결과는 통과했지만 팀의 더 넓은 완료 합의에는 열린 항목이 있는 것입니다.

다가오는 이슈 하나부터 시작하세요. 고객 결과, 중요한 조건과 결과를 합의하고 공통 Definition of Done 옆에 기준을 추가합니다. 만들고 검증할 사람들과 목록을 검토하세요. 처음엔 명확해 보이던 문장 뒤의 숨은 가정이 줄어듭니다.

• Atlassian — 인수 기준이란 무엇인가요?