<aside> 👉 여기서 제시하는 것은 하나의 스타일입니다. 참고만 해주세요.

• 개인적으로는 2번을 추천합니다. </aside>

1. Product Backlog 모든 팀이 공유

• : 제품의 Usecase 및 구성요소 할 일 목록.
  • 기획, 아트, 개발 중 하나에만 속하지 않는, 제품 자체에 집중한 기능 목록. 작업 분배 시 공유.
  • 제품적 서술을 통해, 모든 팀이 하나의 백로그를 공유. 제품과 제작의 영역을 구분 및, 분업을 용이하게 함.

1. 스프린트 시작 시 를 각 팀에 배분.

   • 스프린트 시작 : 매주 목요일 정기 미팅.
   • 배분 백로그는 다음 문서에 기록 (주마다 할 일 기록) : 현재 스프린트
   • 각 Product Backlog 가 가진 상태 (시작 전, 기획 중 ... )을 이용. 기획 완료 이전은 기획, 기획 완료는 개발 및 아트.
   • 만약 하나의 Backlog 가 지칭하는 범위가 클 경우, 금주 목표 좀 더 작게, 분화해서 설정 가능.

2. 배정 받은 Product Backlog 의 Backlog 기반, 각 팀 알아서 진행. 일반적으로 진행하는 과정은 다음과 같음.

   1. 선정 Product Backlog 가 있을 것. 없으면 선정.
   2. 팀의 전문성에 따라 해당 목표 달성을 위한 세부적 할 일 - Sprint Backlogs 제작. (세분화, 구체화, 실행가능한 행동 고려.)
   3. 분배, 기한 설정, 할 일 수행하기 :
      1. Notion 내 사용 권장.
      2. 세부적 할 일 분배와 기한 설정의 존재 유무 중요.

2. Product Backlog → 상세 기획 → 기획 팀이 개발, 아트 요구사항을 전달 → 제작

1. 기획팀이 상품의 처음부터 끝까지 필요한 요소를 열거.

2. 이후, 를 작성 및 제작. 제품 구성요소인가? / 달성, 추적 가능한 목표 제시 했는가? 를 신경 쓸 것.

3. 모두 작성 후, 개발, 아트 팀 상호 모두 읽고 넘어가기. 궁금한 점 피드백 및 코멘트. 순서정하기(우선 순위 설정)가 모든 팀의 요건에 맞게 넘어가야 함.

   • 특히 개발팀의 경우, 기획적 고려와 다르게, 뭘 먼저 해야 이것 제작 가능, 뭘 먼저 하면 뭐 제작하기 쉬움 등의 고려사항이 있을 수 있으므로, 이를 주의하여 파악해야 함.

4. 이후, 결정된 의 우선순위에 따라 기획을 진행.

5. 기획 완료된 내용에서 제작이 필요한 부분을 / 에 작성하여 제작 요청. 단, 기획자는 아트와 개발에 대해 상세한 이해가 없을 수 있으므로, 제품 단에서 가능한 만큼만 서술 및 요청하면 됨.