Userstory 제대로 쓰는 팁
단순하게 이해하면 아무도 가르쳐 주지 않는 이야기
PRD에 대해서 처음 접하게 될 때, 대부분 어떤 방식으로 접하게 될까?
아마도 처음에는 양식문서를 하나 덜렁 받은 뒤, 다른 사람이 쓴 좋은 샘플을 보면서 그걸 채우기 급급하지 않았을까? 왜 PRD를 쓰는지 그 PRD가 지향하는 장점은 무엇인지에 대해서 그렇게까지 친절하게 알려주는 회사를 나는 아직 겪어본 적도 들어본 적도 없다.
그래서 나처럼 오해해서 실수하고, 또 질문하고 공부하고 적용하고 그래서 익숙해지면 여기저기 떠드는 사람이 필요한 걸지도 모른다.
PRD는 'Why'를 정의해서 해결하고자 하는 문제를 정의하고 이에 대한 솔루션을 제안하고, 그 제안을 통해서 문제가 해결됐을 때를 구분할 수 있는 목표 지표를 설정하는 역할을 한다. 여기까지가 상위 기획이라고 한다면, 하위 기획인 실제 구체적인 프로젝트를 위한 내용도 정리하게 되어 있는데 이때 여러 개의 솔루션이 리스트업 될 수도 있고, 단 하나의 해야 할 범위를 아주 구체적으로 제안할 수도 있다.
그런데 PRD자체보다 더 어렵고 안 가르쳐주는 게, 그 안에 포함된 유저스토리 작성법 같다.
유저스토리는 '해야 할 범위를 구체적으로 제안할 때', 사용자의 행위를 중심으로 기록한 문장형태의 요구사항에 해당한다. 그리고 완료조건은 유저스토리가 달성되었을 때 어떤 조건들이 달성되었는지 체크하기 위한 조건들에 해당한다.
여기서 더 나가면 유저스토리를 "As (user), I want ___, so that ____"라는 형태로 쓰고 완료조건은 "given ___, then _____"와 같은 조건문으로 작성한다.
여기가 보편적인 지식으로 어디서든 찾아낼 수 있는 지식이다.
문제는 실전인데, 이렇게 들어서는 알 것 같았지만,, 실제로 쓰기 유용한 유저스토리와 완료조건을 작성하기가 어렵다. 막상 작성하고 나니 화면설계서의 노션 버전이 나오기 십상이다.
그래서 내가 깨달은 몇 가지 팁을 정리해 봤다.
첫째, 유저스토리가 육하원칙만 쓰면서 "왜"도 쓰였나 꼭 확인해 보자.
사람은 양식에 매몰되기 쉽다. 그리고 직역은 문제를 일으킨다.
"As (user), I want ___, so that ____"를 직역하면 "사용자로서, ~를 위해서 나는 ___ 하고 싶다"라고 되는데 이 문장으로 뭔가 사용자의 동작을 작성하려고 하면 뭔가 묘하게 애매하게 느껴진다. 왜냐하면 기존의 디스크립션의 경우는 '의도'가 아닌 '행위의 완료된 형태'를 기준으로 썼었고, 머릿속에 서비스의 형태를 그림으로 잡아둔 경우 정말 쓰기 어렵다.
다 집어치우고 한국어로 생각할 때는 원래 문장에서 딱 2가지를 중요시한다는 것만 생각하자. 바로 '사용자의 의도'와 '사용자의 행위'에만 초점을 맞추자. 그리고 '하고 싶다'라는 것을 '할 수 있다'로 바꾸면 행위 자체를 좀 더 잘 표현할 수 있다.
그것조차 힘들다면 그냥 육하원칙에 맞춰서 써봐도 좋은 것 같다. '누가, 언제, 어디서, 무엇을, 왜, 어떻게"에 맞춰서 유저스토리를 쓴 뒤에 '왜'와 '어떻게'의 연관관계를 잘 보자. 이 두 가지가 서로 순환논리에 빠지지 않았어야 한다. '저장하기 위해서 저장버튼을 누른다'라는 말은 굉장히 말이 되는 것처럼 보이지만 사실은 근본적인 사용자의 의도를 전혀 쓰고 있지 않다. 사용자는 저장을 하는 이유가 따로 있다. '게시판에 글을 올리기 위해서라든가' 아니면 '잘못된 정보를 수정하기 위해서'와 같은 것들이 있어야 한다.
'왜'가 유저스토리를 통해서 메이커들에게 비즈니스와 사용자에 대한 이해도를 높여주는 키포인트다.
둘째. 유저스토리의 행위 형태에서 UI 형태는 가급적 자제한다.
유저스토리를 쓰는 이유 중 하나는 메이커인 디자이너와 개발자의 자유도를 높여서 그들의 전문성을 서비스를 만드는 과정에 더 많이 들어갈 수 있도록 하기 위한 것이다. 그게 바로 애자일 사상이니까..
근데 내 유저스토리의 '어떻게'에 대한 부분에 '버튼, 셀렉트 박스, 스와이프, 라디오버튼' 등 UI의 형태에 대한 내용이 너무나도 구체적으로 계속 명시되고 있다면 이건 자유도를 제한하고 있는 것이다. 글로 쓴 화면설계서 디스크립션이 되어 버린다.
셋째, 시작부터 TASK를 위해서 유저스토리가 여러 줄이 나오고 있다면, 유저스토리와 완료조건을 헷갈리고 있는 것이다.
유저스토리와 완료조건에 대한 관계는 1:N이다. 우리가 예전에 화면설계서로 디스크립션으로 들어가던 케이스별 정책 정의나, 분기처리/예외처리는 유저스토리 방식에서는 유저스토리가 분리되는 것이 아니라 완료조건으로 분리되어야 한다. 최초에 PRD를 쓸 때 유저스토리는 가급적 문장 1개로 정리하고, 완료조건에서 플로우를 쪼개든 스펙을 상세화하든 해야 한다.
만약 '사용자는 방금 결제까지 마친 주문에 대해서 구매의사가 없어져 환불받기 위해서 마이페이지에서 주문의 취소 요청을 할 수 있다."라는 유저스토리가 있다면, 완료 조건은 아래처럼 세분화해서 작성할 수 있다.
고객변심에 의한 부분취소일 경우, 잔여 상품의 배송비에 대해서 재계산을 하여 부과할 수 있다.
셀러가 아직 주문을 체크하지 않은 경우, 즉시 취소완료 처리 된다.
셀러가 주문을 체크해서 배송을 준비하고 있는 경우, 셀러의 승인을 받아야 취소완료 처리 된다.
셀러가 주문의 취소를 거부한 경우, 주문은 자동으로 다시 취소요청 이전 상태로 돌아간다.
이 모든 문장은 처리의 결과에 대한 스펙이기 때문에 유저스토리가 아니라 완료조건이다.
넷째, 만약 유저스토리 하나가 차지하고 있는 개발 범위가 너무너무 클 경우, 유저스토리를 여러 개의 EPIC으로 쪼개서 스프린트를 분리하여 릴리즈 할 수 있다.
유저스토리를 하나의 문장으로 적다 보면, 그 완료조건의 양이 무수히 커지는 경우도 존재한다.
"사용자는 인근의 배달가능한 식당의 정보를 찾고 음식을 먹기 위해서 쿠팡이츠를 사용할 수 있다" 이런 어마어마한 유저스토리가 존재한다고 치면, 이건 거의 하나님의 창세기를 모티브로 한 문장에 가깝다. 태초에 쿠팡이츠가 있어라 한다고 개발이 돼서 뿅 하고 나오진 않는다.
그렇다면 그때 해야 하는 것은 무엇일까..? 바로 에픽쪼개기다.
에픽을 쪼갤 때는 마치 케이크를 자르듯이 사용자의 목적과 테스트를 기준으로 잘라야 한다. 이 기준은 여러 가지가 있지만 적어도 동작이 되는 기준으로 잘라야 한다. 이 역시 스프린트 하나에는 말도 안 되게 큰 범위지만 위의 유저스토리를 이렇게 에픽으로 쪼개볼 수도 있다.
- (전시) 사용자는 자신의 지역에 있는 음식점만 배달을 받을 수 있기 때문에, 해당 지역을 세팅하여 식당 리스트를 볼 수 있다.
- (주문) 사용자는 음식을 주문할 때 편하게 받기 위해서 비용을 내고 배달받을 수 있다.
- (주문) 사용자는 음식을 주문할 때 인근에는 배송비를 절약하고 직접 찾으러 갈 수 있다.
아주 일부만 적어봤는데. 핵심은 이거다. 독립적으로 구현 가능한 단위로 나누고, 프로세스를 횡적으로 쪼개야 한다.
전시와 주문 중 전시만 있어도 일단 앱 자체의 컨셉은 보여줄 수 있다. 초창기 배달의 민족처럼 리스트만 보여줘도 이 앱의 정보전달의 기능은 제공할 수 있다.
우리가 주문서를 기획한다고 생각하면, UI생각해서 미리 배송 옵션을 배달과 픽업을 선택한다고 생각하고 기획을 하면 전체 스토리라인을 종적으로 쪼개버릴 수 있다.
- 잘못된 쪼개기의 예 : 사용자는 음식을 주문할 때, 배달과 픽업 중 하나를 선택할 수 있다.
위의 문장처럼 쓸 경우, 픽업의 이후 프로세스와 배달의 이후 프로세스를 모두 포함하는 말이 되어버리기 때문에 유저스토리가 포함하고 있는 에픽의 사이즈가 여전히 크다. 이 문장은 전혀 에픽 쪼개기가 되지 않는다.
