8장: PRD와 User Story
프로젝트에 팀이 구현하는 데 집중할 수 있도록 하는 유저 스토리
서론:
7장에서 프로덕트 팀의 방향을 잡아주는 기획 산출물인 PRD에 대해서 살펴보았다. 이번에는 User Story를 통해 구체적으로 구현할 수 있는 방법을 살펴보고자 한다.
본론:
- User Story에 대한 위키백과의 설명을 참고해 보았다.
A user story is a small, self-contained unit of development work designed to accomplish a specific goal within a product. A user story is usually written from the user’s perspective and follows the format: “As [a user persona], I want [to perform this action] so that [I can accomplish this goal].”
위키백과에 따르면 유저 스토리는 구체적인 목적을 달성하기 위한 작고 독립적인 개발 단위이고, 유저의 관점에서 쓰인 형태로 되어있다. 그 형태는 흔히 "사용자는 00 액션을 통해 00 목적을 달성할 수 있다."정도로 쓸 수 있다.
유저 스토리는 누구나 이해할 수 있어야 하며, 구체적으로 작성하여 실제 스프린트에 활용할 수 있도록 되어야 한다. 유저 스토리는 아래 같은 구조로 구성되어 있다.
1. Initiative: 프로덕트 이니셔티브를 정의할 정도로 큰 단위
2. Epic: 유저 스토리 중 넓은 범위이자 사용자에게 의미 있는 프로덕트 기능 단위 (여러 개의 Epic으로 유저 스토리를 구성한다. )
3. Story: 에픽의 하위에 담을 수 있는 스토리. 에픽보다 작게 쪼개져 사용자에게 가치를 줄 수 있는 행위 단위
4. Task: 스토리를 완성할 수 있도록 작게 쪼개진 개발 단위
5. Sub task: 테스트에서 더 작게 쪼개진 개발 단위
프로덕트는 여러 개의 유저 스토리로 구성되어 있으며, 이를 한데 모아 User Story Map을 만들 수 있다. 유저 스토리 맵을 만들 때, 사용자와 각 단계에 따라 나누며, 각 단위에 필요한 만큼의 스토리를 뽑아서 MVP를 구성할 수도 있다.
이때 스토리의 중요도와 에픽 간의 우선순위를 확인할 수 있도록 점수를 매길 수 있다. 비즈니스 임팩트, 사용자 유용성, 개발 난이도 등을 고려할 수 있으며 MosCow, Assumption test 등을 이용할 수 있다.
해당 내용을 바탕으로 로그인과 회원가입에 관한 유저 스토리의 예시를 작성해보았다.
Epic #1 회원 가입과 로그인
Story 1 사용자는 회원가입을 통해 ID와 PW를 만들 수 있다.
task 회원 가입 시, 기본적인 개인 정보를 입력하게 하고 서버에 저장한다.
sub task 기본적인 개인정보는 아이디, 비밀번호, 이름, 생일, 성별, 휴대전화, 이메일로 한다.
Story 2 사용자는 ID와 PW를 통해 로그인하여 서비스를 이용할 수 있다.
task 로그인 유저만 서비스를 이용할 수 있게 한다.
task 카카오, 네이버의 간편 로그인 기능을 제공한다.
Story 3 사용자는 회원을 탈퇴할 수 있다.
task 사용자가 회원을 탈퇴할 때 서비스를 이용할 수 없다는 경고 메시지를 보낸다.
task 회원을 탈퇴한 사용자의 개인정보를 즉시 서버에서 삭제한다.
결론:
PRD와 User Story를 살펴보며, 기획자가 만들어야 하는 산출물을 살펴볼 수 있었다. 사실 기획자는 조직에 따라 더 다양한 기획 산출물을 통해 프로젝트를 관리하고 여러 담당자들과 소통할 수 있다. 최근에는 '애자일'한 업무 환경을 구축하기 위해 여러 가지 툴을 활용해서 이를 사용하고 있다. 이 툴은 대체로 실시간 소통이 가능할 수 있도록 되어 있고, 수정과 버전 관리에 용이한 점이 있다.
PRD와 User Story를 작성할 때의 가장 중요한 점은 구체적으로 작성하고 모두가 이해 가능할 수 있도록 적어야 한다는 점이다. 프로덕트/서비스를 구현할 때 참고해야 하는 지침서이자 가이드라인이기에 자세하게 적을수록 좋다. 하지만 PRD는 처음부터 완벽하게 작성하는 문서가 아니다. 프로젝트가 끝날 때까지 끊임없이 수정해야 하는 특성상, 구현 과정에서 나오는 여러 이슈와 이벤트를 포함해야 하고, 처음에 놓쳤던 부분이 끊임없이 등장하기 때문이다.
그러니 처음부터 완벽한 PRD를 만들고자 시간을 낭비하는 것이 아니다. 여러 담당자와 소통을 통해 최대한 구체적으로 작성한 PRD와 User Story를 지속적으로 업데이트해야 하는 것을 잊지 않았으면 한다.
* 해당 게시물은 NHN 아카데이 서비스 기획 부트캠프의 학습내용을 토대로 임의로 작성한 게시물입니다. 각 내용에는 정확하지 않은 내용이 있을 수 있으니, 혹 수정이 필요한 내용은 댓글로 알려주시면 감사하겠습니다.
**노션을 이용해 부트캠프 과정을 더 간단하게 아카이 빙하고 있습니다. 방문해 주실 분은 하단 링크를 누르시면 연결됩니다. NHN 서비스 기획아카데미 (notion.so)
