Definition of Ready(DoR, 준비 완료 정의)란 무엇인가요?

Definition of Ready(DoR, 준비 완료 정의) 는 백로그 항목이 스프린트에 선택되기 전에 충족해야 하는 조건의 집합입니다. 팀과 Product Owner가 합의한 기준으로, 항목이 개발을 시작하기에 충분히 준비되었는지를 판단합니다.

쉽게 말해, "이 항목을 개발하기 시작해도 되는가?" 에 대한 체크리스트입니다.

DoR은 Definition of Done(DoD)의 "입구 조건" 역할을 합니다. DoR이 스프린트의 시작 품질을 보장한다면, DoD는 완료 품질을 보장합니다.

스프린트 플래닝 효율화

DoR을 충족하지 않는 항목이 스프린트 플래닝에 올라오면:

• 플래닝 시간이 길어짐
• 요구사항 논의로 시간 소비
• 모호한 항목으로 인한 개발 중 블로커 발생

DoR을 활용하면 플래닝에서는 "무엇을 할 것인가"와 "어떻게 할 것인가"에 집중할 수 있습니다.

품질 향상

• 불명확한 요구사항으로 인한 재작업 방지
• 개발 중 이해관계자 확인 대기 시간 감소
• 사이클 타임 단축

팀 효율성 향상

• 개발자가 작업을 시작하자마자 바로 코딩에 집중 가능
• 스프린트 중 범위 변경 감소
• 예측 가능성 향상

기본 체크리스트

[ ] 사용자 스토리가 명확하게 작성되어 있다 (역할, 행동, 가치가 정의됨) [ ] 인수 기준(Acceptance Criteria)이 정의되어 있다 [ ] 팀이 요구사항을 이해하고 동의한다 [ ] 스토리 포인트로 추정이 완료되었다 [ ] 외부 의존성이 식별되고 해결되었다 [ ] UI/UX 디자인이 준비되어 있다 (해당하는 경우) [ ] 기술적 제약사항이 파악되었다

네이버/카카오 수준의 상세 체크리스트

[ ] 사용자 스토리가 INVEST 원칙을 충족한다 [ ] 인수 기준이 Given-When-Then 형식으로 작성되었다 [ ] Figma 디자인이 개발자에게 공유되었다 [ ] API 명세서가 작성되었다 [ ] 데이터 모델 변경이 식별되었다 [ ] 보안 요구사항이 검토되었다 [ ] 성능 기준이 정의되었다 (응답 시간 등) [ ] 접근성 요구사항이 확인되었다 [ ] QA 테스트 시나리오가 준비되었다 [ ] 모니터링/로깅 요구사항이 정의되었다 [ ] 기술 부채 영향이 평가되었다 [ ] 스토리 크기가 스프린트 내 완료 가능하다 

분야별 추가 기준

프론트엔드 팀:

• Figma 디자인 확정
• 반응형 디자인 가이드 제공
• 컴포넌트 라이브러리 호환성 확인

백엔드 팀:

• API 스펙 정의 완료
• 데이터베이스 스키마 변경 계획 수립
• 외부 API 연동 문서 준비

모바일 팀:

• 지원 OS/디바이스 범위 확인
• 오프라인 동작 요구사항 정의
• 앱 스토어 정책 준수 확인

리파인먼트 세션에서의 DoR 활용

백로그 리파인먼트에서 DoR은 항목의 준비 상태를 점검하는 도구입니다:

1. 백로그 항목 검토: Product Owner가 다음 스프린트 후보 항목 제시
2. DoR 점검: 팀이 각 항목을 DoR 체크리스트로 평가
3. 갭 식별: 충족하지 못한 조건 파악
4. 액션 설정: 부족한 부분을 채우기 위한 구체적 행동 정의
5. 추정: DoR을 충족한 항목에 대해 플래닝 포커로 추정

리파인먼트 타임라인

스프린트 N 스프린트 N+1 ├─── 리파인먼트 ──┤ ├─── 플래닝 ──── 개발 ────┤ │ │ │ │ │ DoR 점검 및 │ │ DoR 충족 항목만 │ │ 준비 작업 │ │ 스프린트에 투입 │

리파인먼트에서 DoR을 점검하고, 다음 스프린트 플래닝까지 부족한 부분을 보완합니다.

공식 스크럼의 입장

DoR은 스크럼 가이드에 포함되지 않습니다. 스크럼 가이드에는 DoD(Definition of Done)만 명시되어 있습니다.

찬성 의견

• 스프린트 중 재작업과 블로커를 크게 줄임
• 팀과 Product Owner 간의 기대치 정렬
• 예측 가능성 향상
• 신규 팀에게 좋은 가이드라인 제공

반대 의견 (안티패턴 관점)

일부 애자일 전문가들은 DoR을 안티패턴으로 봅니다:

• 경험주의 방해: 불확실성을 받아들이는 스크럼의 원칙에 반함
• 관문(Gate) 형성: 팀의 자율성과 유연성을 제한
• 과도한 사전 분석: 워터폴 방식의 "빅 업프론트 디자인"으로 회귀
• Product Owner 부담: 모든 항목을 완벽히 준비해야 한다는 압박

균형 잡힌 접근

DoR을 가이드라인으로 사용하되, 절대적 규칙으로 만들지 마세요:

• DoR의 80% 이상 충족하면 스프린트에 투입 가능
• 미충족 항목은 스프린트 중 해결 가능한지 팀이 판단
• 팀의 성숙도에 따라 DoR을 유연하게 조정
• 정기적으로 DoR 항목을 회고에서 검토

삼성 SDS

대규모 엔터프라이즈 프로젝트에서 DoR을 활용하여 요구사항 품질을 관리합니다. 특히 고객사와의 요구사항 합의 과정에서 DoR 체크리스트가 의사소통 도구로 활용됩니다.

카카오

카카오의 일부 팀에서는 "3-Amigos 세션"(Three Amigos)을 DoR 충족의 핵심 활동으로 운영합니다. PO, 개발자, QA가 함께 모여 사용자 스토리를 검토하고, BDD 시나리오를 작성하면 DoR을 충족한 것으로 간주합니다.

네이버

네이버의 개발 팀은 "Ready 보드"를 별도로 운영하여, 백로그에서 DoR을 충족한 항목만 Ready 보드로 이동시키는 시각적 관리 방법을 사용합니다.

DoR이 없으면 어떤 문제가 생기나요?

요구사항이 모호한 항목이 스프린트에 들어가면: 개발 중 잦은 확인 필요, 방향 변경, 재작업 증가, 스프린트 목표 미달성 등의 문제가 발생합니다.

DoR 체크리스트는 누가 만드나요?

팀 전체가 합의하여 만듭니다. Product Owner, 개발자, 테스터가 각자의 관점에서 필요한 조건을 제시하고, 팀이 최종 합의합니다.

DoR이 충족되지 않은 항목을 꼭 거부해야 하나요?

반드시 그런 것은 아닙니다. 중요한 것은 위험을 인식하고 관리하는 것입니다. DoR 미충족 항목을 스프린트에 넣되, 미충족 조건으로 인한 리스크를 팀이 이해하고 수용한다면 진행할 수 있습니다.

어느 정도의 DoR이 적절한가요?

5-10개 항목이 적절합니다. 너무 적으면 의미가 없고, 너무 많으면 관문이 되어 속도를 떨어뜨립니다. 팀의 경험과 프로젝트 특성에 맞게 조정하세요.

• DoD - 완료 정의
• 백로그 - 작업 목록
• 스프린트 플래닝 - 스프린트 계획
• Product Owner - 제품 소유자
• BDD - 행동 주도 개발
• 사이클 타임 - 사이클 타임