💦 나만 모르는 프로덕트 관리 이야기 [✏️ PM에게 유용한 인수 기준 작성법] (👀간단 요약) 📌 인수 기준? ✓ 테스트 케이스를 프로젝트 초반에 작성하여 유사한 역할을 담당 ✓ 우리가 마

💦 나만 모르는 프로덕트 관리 이야기 [✏️ PM에게 유용한 인수 기준 작성법] (👀간단 요약) 📌 인수 기준? ✓ 테스트 케이스를 프로젝트 초반에 작성하여 유사한 역할을 담당 ✓ 우리가 마치 장보기 할 때, 사야 할 물건을 정리한 리스트와 유사 ✓ 프로덕트의 기능을 성공적으로 개발하기 위한 체크리스트, 일종의 완료조건 ✓ 팀이 유저 스토리의 범위에 무엇이 포함되고, 무엇이 제외되는지 제품 개발 범위를 이해하는데 도움 ✓ 프로덕트·프로젝트가 반드시 달성해야 하는 사전에 설정된 기준과 요구사항을 의미 ✓ 주요 이해관계자가 요구사항에 대해 동일한 방향성으로 이해하는 것이 중요 ✓ 프로젝트 실패의 50%가 잘못된 요구사항 계획과 커뮤니케이션 이슈로 인해 발생 📌 Who, When and How? ✓ 인수 기준(Acceptance criteria)은 반드시 사용자의 입장에서 작성되어야 함 ✓ 보통 프로덕트 오너, 프로덕트 매니저가 작성 ✓ 해당 인수 기준에 대해 팀 멤버가 반드시 리뷰하고, 상호 동의하는 sync 필요 📌 Shared understanding and consensus ✓ 인수 기준(Acceptance criteria)은 고객/이해관계자(client/stakeholder) 및 개발팀의 비전을 sync ✓ 관련된 모든 사람들이 요구사항을 공통적으로 이해하도록 도움 ✓ 개발팀은 구현 대상이 되는 기능을 알게 되고, 고객과 이해관계자는 기능의 기대 결과를 이해할 수 있음 📌 Clarity comes first ✓ 인수 기준(Acceptance criteria)은 명확하게 작성되어야 함 ✓ 이해 관계자가 사용하는 용어로 명확하고 이해하기 쉽게 표현되어야 함 ✓ 기능의 범주와 기능 외 범주를 담고 있어야 하며, 불필요한 세부 정보는 내용 작성에 포함시키지 않아야 📌 Make it testable, measurable and achievable ✓ 개별 인수 기준(Acceptance criteria)은 독립적으로 테스트 가능하도록 pass / fail 시나리오가 있어야 ✓ QA 담당자는 인수 기준을 활용해 테스트 케이스를 작성할 수 있고, 테스트의 시작과 종료 시점을 예측 가능 📌 The format ✓ Rule-oriented (checklist) ✓ 체크리스트 기반으로 특정 유저 스토리가 인수 기준(Acceptance criteria)으로 잘 커버되는지 확인 가능 ✓ Scenario-oriented (Given/When/Then) ✓ Custom formats 📌 기타 ✓ 유저 스토리가 너무 길면 기능적( functional ) 범위와 비 기능적(non functional) 범위로 나눌 필요가 있음 ✓ 기능적인 범주의 유저 스토리를 먼저 개발, 가치 제안을 검증할 수 있는 최소 버전의 제품을 개발할 수 있음 ✓ 버튼, 키패드의 활성 및 비활성화 상태와 사용자가 댓글을 남기고 싶지 않을 때 게시물(post)로 돌아가기 위한 ‘뒤로 가기’ 버튼에 대한 의도(intention)가 포함 ✓ 유저 스토리와 연결되는 user flow의 복잡한 세부사항은 인수 기준을 작성하는 동안 고려 필요 ✓ negative criteria, edge cases를 포함하면 추후에 버그 예방에 도움이 됨