PM에게 유용한 '인수 기준' 작성법
How to Craft Strong Acceptance Criteria
How to Craft Strong Acceptance Criteria for a User Story 원문을 요약했습니다.
제가 일하는 팀은 인수 기준(Acceptance criteria)을 작성하지는 않고, 테스트 케이스를 프로젝트 초반에 작성하여 유사한 역할을 담당하는데요.
개인적으로 PM이 인수 기준(Acceptance criteria)의 범위와 pass/fail 기준을 신중하게 검토하는 것이 중요하다는 점에 공감이 되어서, 주요한 혹은 유저 스토리 대상으로 사례를 만들어볼까 생각해봤습니다.
----
인수 기준(Acceptance criteria)은 우리가 마치 장보기 할 때, 사야 할 물건을 정리한 리스트와 유사함. 프로덕트의 기능을 성공적으로 개발하기 위한 체크리스트, 일종의 완료조건.
에자일에서 유저 스토리(user story)는 ‘사용자’ 관점에서 기능이 무엇인지 정의하는 것을 의미함. 좋은 유저 스토리 정의는 필수적으로 좋은 인수 기준((Acceptance criteria)의 작성을 필요로 함. 인수 기준은 팀이 유저 스토리의 범위에 무엇이 포함되고, 무엇이 제외되는지 제품 개발 범위를 이해하는데 도움이 됨.
Why do we need acceptance criteria?
“인수 기준은 프로덕트·프로젝트가 반드시 달성해야 하는 사전에 설정된 기준과 요구사항을 의미합니다."
“Acceptance criteria are pre-established standards or requirements a product or project must meet.”- by Google
프로젝트 초반부터 주요 이해관계자가 요구사항에 대해 동일한 방향성으로 이해하는 것이 중요함
“프로젝트 실패의 50%가 잘못된 요구사항 계획과 커뮤니케이션 이슈로 인해 발생한다"
"50% of projects fail due to poor requirements planning and communication issues -ESI International survey, 2005”
유저 스토리(user story)가 잘 기획되지 않은 경우에 프로젝트가 목표로 한 결과를 제대로 배포하지 못하는 경우가 생길 수 있음. 관련해서 인수 기준((Acceptance criteria) 정의해서 몇 가지 장점을 가지고 있음.
"인수 기준은 ‘완료의 정의’( ‘Definition of Done’)의 개념을 촉진하는데 도움을 제공합니다 "
"Acceptance criteria are beneficial because it helps facilitate the concept of ‘Definition of Done’”
‘완료의 정의’(‘Definition of Done’)는 각 유저 스토리가 충족해야 할 기준을 정의하고 및 기대한 방식으로 동작하는지 여부를 이해하는데 도움이 됨.
'완료 정의'는 팀이 스토리가 완료되고 예상대로 작동하는지 여부를 이해하는 데 도움이 되는 기능에 대한 정확한 세부 정보를 제공합니다. 잘 정의된 인수 기준(Acceptance criteria)은 요구사항 수집과 효과적인 커뮤니케이션을 담고 있음.
Best practices for writing acceptance criteria
# 1. Who, When and How?
- 인수 기준(Acceptance criteria)은 반드시 사용자의 입장에서 작성되어야 함.
- 보통 프로덕트 오너, 프로덕트 매니저가 작성.
- 시점은 스프린트 플래닝 전에 유저 스토리 기반으로 작성.
- 해당 인수 기준에 대해 팀 멤버가 반드시 리뷰하고, 상호 동의하는 sync 필요
# 2. Shared understanding and consensus
- 인수 기준(Acceptance criteria)은 고객/이해관계자(client/stakeholder) 및 개발팀의 비전을 sync 함
- 관련된 모든 사람들이 요구사항을 공통적으로 이해하도록 도움을 줌.
- 개발팀은 구현 대상이 되는 기능을 알게 되고, 고객과 이해관계자는 기능의 기대 결과를 이해할 수 있음
# 3. Clarity comes first
- 인수 기준(Acceptance criteria)은 명확하게 작성되어야 함(clear and concise).
- 이해 관계자가 사용하는 용어로 명확하고 이해하기 쉽게 표현되어야 함
- 기능의 범주와 기능 외 범주를 담고 있어야 하며, 불필요한 세부 정보는 내용 작성에 포함시키지 않아야 함. - 기타 불필요한 접속사의 사용도 피해야 함
# 4. Make it testable, measurable and achievable
- 개별 인수 기준(Acceptance criteria)은 독립적으로 테스트 가능하도록 pass / fail 시나리오가 있어야 함
- QA 담당자는 인수 기준을 활용해 테스트 케이스를 작성할 수 있고, 테스트의 시작과 종료 시점을 예측 가능
# 5. The format
다양한 포맷이 존재함
Rule-oriented (checklist)
Scenario-oriented (Given/When/Then)
Custom formats
Rule-oriented (checklist) 포맷을 활용하면 체크리스트 기반으로 특정 유저 스토리가 인수 기준(Acceptance criteria)으로 잘 커버되는지 확인할 수 있음.
참고. 유저 스토리가 너무 길면 기능적( functional ) 범위와 비 기능적(non functional) 범위로 나눌 필요가 있음. 기능적인 범주의 유저 스토리를 먼저 개발하여, 제품을 단순하고 고객 대상으로 가치 제안을 검증할 수 있는 최소 버전의 제품을 개발할 수 있음
What should an acceptance criteria entail and how can we avoid bugs?
인수 기준(Acceptance criteria)은 단순히 솔루션과 구현을 정의하는 것이 아닌 유저 스토리의 의도(intention)에 대한 충분한 설명을 담을 수 있을 정도로 상세히 작성해야 함
예시) 아래 예시는 댓글 기능을 개발하는 유저 스토리와 인수 기준
https://productcoalition.com/how-to-craft-strong-acceptance-criteria-for-a-user-story-c12792a992b9- 예시는 버튼, 키패드의 활성 및 비활성화 상태… 사용자가 댓글을 남기고 싶지 않을 때 게시물(post)로 돌아가기 위한 ‘뒤로 가기’ 버튼에 대한 의도(intention)가 포함됨
- 유저 스토리와 연결되는 user flow의 복잡한 세부사항은 인수 기준을 작성하는 동안 고려 필요
- negative criteria, edge cases를 포함하면 추후에 버그 예방에 도움이 됨
- 용어의 일관성과 명확함이 필요함
Key Takeaways
유저 스토리 작성 후에 인수 기준(Acceptance criteria)을 정의하는 것은 향후 발생할 수 있는 여러 이슈를 초반에 확실히 해결하는데 도움을 제공. 요구사항 명확히 이해하고, 모호함을 방지하는데 도움이 됨. QA가 개발 목표가 잘 구현되었는지 검증하는데 도움이 됨.
가능하면 팀 멤버 전부가 초기부터 인수 기준(Acceptance criteria) 정의 및 리뷰에 참여하는 것이 필요함
릴리즈 막판에 예상치 못한 이슈를 피하고, 고객 만족도를 높이기 위해 인수 기준(Acceptance criteria)이 신중하게 고려돼야 함
Giphy제가 발행하는 뉴스레터입니다. 프로덕트 매니저 커리어에 관심 있으신 분들께서는 아래 뉴스레터 링크에서 구독 부탁드립니다 :)
