사용자 스토리 쓰기

How to prep stories

진정한 구체성은 여러개의 레퍼런스를 활용하는 데 있다. 수전 손택 <수전 손택의 말>

제품 팀은 어떤 솔루션을 어떻게, 왜 구현하는지를 반복적으로 고민하고 실행하는 과정을 반복한다. 사용자 스토리는 스프린트를 계획할 구성의 단위이면서, 솔루션의 출발점이 된다. 스토리 포인트 산출이라는 애자일 프랙티스를 효과적으로 운영하려면 스토리를 잘 준비해야 한다.

스토리는 설명, 인수조건, 그리고 요구사항으로 구성된다.

구분	내용	상세
설명	누가, 원하는 것, 기대효과	사용자 페르소나와 관련됨
인수조건	상황, 조건, 결과	사용자 플로우의 초기 버전이자 요구사항의 기준선
요구사항	솔루션을 구체화하고 예외케이스(제약사항, 제약하지 않을 사항 등), 레퍼런스 등을 제시	솔루션 스펙의 초기 버전

AI image created by Tome.app

사용자가 강을 건너야 하는 상황이라고 치고 이에 대한 스토리를 간단하게 써 보자. 배경지식이 거의 없지만 약간의 상상력을 발휘해볼 수 있다.

"나([페르소나 유형])는 강을 건너서 친구를 만나러 가고 싶다." 설명 누가: [페르소나 유형] 원하는 것: 강 건너편으로 이동하기 기대효과: 친구를 만난다 인수조건 상황: 주말에 조건: 강 건너에 사는 친구의 연락을 받으면 결과: 일정한 수단을 통해 강의 건너편에 도착한다

사용자 스토리라기엔 많이 부족해 보인다.

페르소나에 대한 정보가 부족하거나, 이전까지 제품에서 다루지 않은 상황에 대한 문제라면 실제로 스토리에 많은 정보를 담을 수 없다. 그래도 제품 팀이 모여 솔루션을 쌓아갈 수 있는 상태다. 포인트 산출은 질문에서 시작한다.

스토리에 대해 질문하기

위 예시처럼 스토리에 담긴 정보가 부족할수록 다양한 범위에서 질문이 나온다. 사용자나 상황, 조건, 기대효과 등 가닥을 잡아야 할 요소가 많기 때문이다.

'강을 건너는 스토리'에 던질 수 있는 질문을 나열해보자.

• 강은 얼마나 넓고 깊은가?

• 유속이 어느정도 되나? 헤엄쳐서 갈 수도 있나?

• 강을 건너는 데 걸리는 비용과 시간에 제약이 있나?

• 기존에 강을 오가는 교통수단이 전혀 없나?

• 강을 건널 때가 낮인가 밤인가?

• 친구를 정말 실제로 만나야 하나? 전화나 영상통화를 하면 안되나?

• 친구를 만나는 게 사용자에게 중요한 일인가? 사용자의 삶의 질에 얼마나 큰 영향을 줄까?

적극적인 팀일수록 더 많은 질문이 나올 것이다. 하나하나 답을 찾기에 앞서, 질문의 계층을 정리하면 논의의 범위를 정리하기에 수월하다.

논의 방향	질문
1) 솔루션의 스펙을 정하는 데 필요한 정보 탐색	강은 얼마나 넓고 깊은가? 유속이 어느정도 되나? 헤엄쳐서 갈 수도 있나? 강을 건널 때가 낮인가 밤인가?
2) 솔루션의 직접 구현 여부 , 비용 등을 논의	강을 건너는 데 걸리는 비용과 시간에 제약이 있나? 기존에 강을 오가는 교통수단이 전혀 없나?
3) 스토리의 전제를 재검토	친구를 정말 실제로 만나야 하나? 전화나 영상통화를 하면 안되나? 친구를 만나는 게 사용자에게 중요한 일인가? 사용자의 삶의 질에 얼마나 큰 영향을 줄까?

범위가 넓은 논의부터 순차적으로 진행하면 솔루션의 윤곽이 드러난다. 선행된 논의의 결과에 따라 어떤 질문은 해결책과 무관하다는 결론이 날 수도 있기 때문에 시간도 절약할 수 있다. 위 예시에서는 3 > 2 > 1 의 순서가 적절하다.

이 과정을 통해 팀은 사용자에게 여객선 정기 이용권을 제공하자는 결론을 내거나 모터보트를 구매해 운송 서비스를 제공할 수도, 현수교 건설 프로젝트를 시작할 수도 있다. 만드는 제품의 목표와 성격에 따라 같은 스토리에 대한 솔루션과 규모(스토리 포인트)는 천차만별이기 때문이다.

스토리의 전제에 대한 질문에 답하기 위해서는 사용자에 대한 정보가 더 필요하다. 임의의 페르소나와 가상의 제품을 정의해 보자. 기왕이면 디지털 서비스가 좋겠다.

가상의 제품 A

페르소나 홍길동

40대 직장인. 발령을 받아 벽지에 근무 중.

주말에 친구를 만나는 것이 유일한 낙이지만, 그렇다고 모터보트를 가진 동료에게 매번 부탁하기도 곤란하다. 편하게 이동하기 위해 매주 5만원 까지는 지불할 의사가 있다.

가상의 제품: A 앱

고가물품 전용 중고거래 플랫폼. 거래금액이 50만원이 넘는 중고품이라면 품목 구분 없이 취급하며, 사용자가 안심하고 거래할 수 있도록 실명계좌 등록제, 허위 매물 적발 시스템을 적용한다.

고가품 구매의 장벽을 낮추는 전용카드 할부 결재 서비스가 사업 모델의 핵심이다. 카드사와의 파트너십과 중개 수수료로 수익을 창출한다.

맥락이 더 풍부한 상황에서 프로덕트 매니저는 더 준비된 스토리를 쓸 수 있다. 주제는 명확하되 결말은 열려있는 논의를 할 수 있도록 스토리를 써 보자.

스토리 준비하기

A 앱을 만드는 팀이 '강을 건너고 싶은 홍길동씨'에게 부여할 수 있는 맥락은 이미 잡혀있다. 홍길동씨는 강변에 거주하고 특정한 품목에 대한 수요가 있으나 제한적 예산을 가진 잠재적 구매자이다. 더 긴 타임라인에서 생각하자면 현재 지역에서의 근무가 끝난 이후에는 판매자로서 재유입될 수 있는 사용자이기도 하다.

지역 기반의 공유경제 서비스를 구매하려는 사용자로 가정해볼 수도 있겠지만, A 제품은 '고가물품 전용'이라는 타겟이 확고하다. 보트를 얻어타거나 대여하는 서비스를 구매하는 옵션은 무시하기로 한다. A 제품의 프로덕트 매니저가 되어 사용자 스토리의 초안을 다시 써 보자.

"나는 A앱에서 모터보트를 구매하고 싶다." 설명 누가: 사용자(강변 지역에 거주하는 잠재적 구매자) 원하는 것: 중고 모터보트 구입 기대효과: 거주하는 지역의 강을 건널 수 있는 수단(도구)을 확보한다. 인수조건 상황: A 앱에 접속해 조건: 키워드(보트, 모터보트 등)를 검색하면 결과: 원하는 조건의 매물 목록과 가격을 확인하고, 예산에 맞게 할부 구매를 할 수 있다.

이 스토리를 팀과공유하기 전에 프로덕트 매니저로서 집중적으로 점검할 부분은 스토리에서 제시된 정보와 전제다.

• 스토리의 전제와 임팩트에 대해

  • 현재 사용자 기반에서 얼마나 보편적인 스토리인가?

    • 현재 사용자 기반과 많이 겹치지 않는다면, 신규 사용자 유입에 유의미한 기여를 하는 타겟인가?

  • 솔루션의 임팩트는 어떻게 측정할 수 있나?

  • 임팩트가 큰 스토리를 만들기 위해 더 대표성 있는 페르소나를 상정할 수 있을까?

• 페르소나에 대해

  • 지역(강변)이나 구매 품목(수상동력기 또는 보트)으로 정의하면 어떨까?

    • 지역만으로 페르소나를 규정할 수 있을까? 유형을 특정하는 데 도움을 줄 다른 인구학적 정보는 없을까?

    • 이동용으로 보트를 원하는 사용자와 레저용으로 구매하려는 사용자가 기대하는 사양과 구입 예산은 어떤 차이가 있을까?

  • '지방에 발령받은 40대 직장인'이라는 정보가 페르소나 정의에 유의미한가?

• 인수조건에 대해

  • 반드시 키워드를 검색해야만 사용자가 원하는 품목을 제시할 수 있나?

    • 현재 검색 알고리즘의 작동방식은 어떻게 되나?

    • 임의의 사용자 정보를 가정해서 초기 화면 노출 정보를 시뮬레이션할 수 있을까?

  • 키워드를 검색했을 때 결과는 어떻게 제시되고 있나?

    • 사용자가 이전에 적용한 정렬 기준과 필터를 다른 품목을 검색했을 때도 자동으로 적용해주는 것을 선호할까?

    • 품목마다 사용자들이 더 보편적으로 적용하는 정렬 기준과 필터 조건이 있을까?

    • 거래 빈도와 매물 수가 적은 품목의 검색 결과를 개선할 수 있는 방법은 없을까?

  • 구매 전환율을 높이려면 어떻게 해야할까?

    • 원가와 월 할부 가격 중 어느쪽을 제시하는 것이 효과적인가?

      • 제휴 카드를 소지하지 않은 사용자에게도 할부를 추천하는 것이 긍정적인 경험을 줄까?

      • 사용자 설정에 선호하는 결제 방식(송금, 일시불 결제, 할부 결제)을 설정하도록 할까?

    • 금액 외의 구매 장벽은 어떤 것이 있을까?

제품의 단계에 따라 어떤 질문에는 이미 답이 있을 것이고, 답을 아예 할 수 없는 질문도 있을 것이다. 모든 질문에 대한 답이 준비되어 있을 수는 없다. 질문을 던지고 답을 고민하는 과정에서 스토리의 완성도는 자연히 높아진다. 회의에서 공유하기 전에 스토리의 완성도를 높이면, 팀이 답을 도출하는 과정이 가속화된다.

다만, 혼자 스토리를 검토할 때 주의해야 할 점이 있다.

정보는 최대로, 판단은 최소한.

스토리 포인트 산출을 처음 도입하거나, 초기 단계의 제품을 만드는 팀에게 특히 중요한 원칙이다. 이미 프로덕트 매니저가 임의로 많은 판단을 내린 채, 그 근거가 되는 정보는 제공하지 않는다면 형식만 애자일 프랙티스일 뿐 일방적 기획 전달과 크게 다를 바가 없다.

사전에 상당부분 가닥을 잡는 것이 적절할 때도 있다. 도출할 수 있는 솔루션이 '너무' 자명하거나, 요구사항이 복잡해서 구체적인 예시가 필요한 경우다. 모두 절대적 기준치는 없으니 시행착오를 통해 적절히 판단해야 한다. 그리고 이 경우, 판단의 근거와 논리를 효과적으로 전달할 자료를 준비해야 한다. 그래야 모든 구성원이 스토리를 잘 이해해 더 정확하게 산출할 수 있고, 때로는 제시된 정보를 바탕으로 더 나은 경로를 찾을 가능성도 열어둘 수 있다.

지금 팀에서는 특별한 일이 없는 한 매주 스토리 포인트 산출 회의를 한다. 최근에 3주 연속으로 회의에 올린 스토리가 있었다. 디테일이 충분치 않아 유보했다가, 스토리를 아예 다시 썼다가, 인수 조건을 설명하기 위해 화면 목업까지 그린 끝에 포인트를 부여할 수 있었다. 그 과정을 온전히 혼자 진행한 것은 아니다. 고객 인사이트를 가진 멤버와 논의하거나, 이전 버전의 스토리를 보고 엔지니어가 제시한 의문점을 소화하면서 최종적으로 '준비된' 스토리가 나왔다.

개인적으로 기획에서 가장 좋아하는 부분이 이런 과정이다. 요구사항을 이해하기 쉽게 정리하려고 정보를 한 데 묶었다 풀기를 반복하며 간과했던 디테일을 발견하고, 드러나지 않았던 연결고리를 찾는 시간. 새로운 관점과 다양한 피드백을 나누는 팀이 있다면 더욱 재미있고 생산적이다.