유저 스토리는 무엇인가?

본문은 위시켓과 김서영 번역가가 함께 만든 해외 콘텐츠 기반 번역문입니다. 프로덕트 매니저에게 필요한 다양한 정보를 다루는 블로그 매체 ‘Is that Product Management?’의 글을 번역했습니다. 작가는 JB로 엔지니어에서 개발자, 디지털 제품 제작에 관한 글들을 연재 중입니다. 본문은 유저 스토리가 무엇인지, 사례를 들어 설명하는 내용으로 유저 스토리에 대한 개념이 낯선 분들께 추천하는 글입니다.

아, 유저 스토리요! 의심할 것도 없이 애자일 개발의 주요 부분 중 하나이자 프로덕트 매니저의 필수 툴입니다.  

애자일 개발에서 중요한 것 중 하나는 큰 개발 요소들을 나누어, 스토리라고 불리는 작은 조각들로 만드는 것입니다. 여러분이 닌자 마스터 같은 프로덕트 매니저라면, 제품을 통해 고객들에게 가치를 전달하는 과정에서 백로그[1]와 백로그에 있는 여러 유저 스토리를 관리할 필요가 있을 겁니다. 

그런데 유저 스토리는 무엇일까요? 이 질문에 대답하기 위해 그 의미를 낱낱이 파헤쳐봅시다. 

• 문맥상 스토리는 구두로 혹은 글로 쓰인 가상의 이야기입니다.
• 사용자는 컴퓨터, 소프트웨어, 시스템 또는 컴퓨터 서비스를 이용하는 사람 혹은 이용하고 싶은 욕구에 의해 무언가를 소유하고 즐기는 사람입니다.

유저 스토리란 하나의 시스템 사용에 대한 이야기라고 말할 수 있겠네요. 우리가 애자일 개발 방법론에 대해 이야기할 때, 유저 스토리는 ‘시스템 요구사항을 상세하게 설명하는 것’에서 ‘요구사항에 대해 이야기하는 것’으로 초점을 바꿀 수 있게 도움을 주는 툴입니다. 그렇기에 유저 스토리 툴은 보통 요구사항을 개진하는 문장을 사용해 실행됩니다. 예를 들면, <사용자 유형>으로서, 나는 <어떤 욕구>를 원한다, <어떤 보상을> 받을 수 있도록, 같은 형식입니다.

설명을 위해 간단한 스토리를 예로 들어볼까요?

• 마케팅 매니저로서, 나는 우리 제품의 최고의 커뮤니케이션 채널이 무엇인지 알 수 있도록 우리 웹사이트에서 사용자 구매까지 이르게 하는 트래픽 매체와 출처를 알고 싶습니다.
• CEO로서, 나는어떤 제품에 투자할지 결정할 수 있도록 제품당 대략의 평균 수익률을 알고 싶습니다. 

이 모델을 따르는 것의 한 가지 장점은 스토리의 집필자가 "어떻게" 대신에 "무엇"에 집중하게 된다는 것입니다. 후자(“어떻게”)는 개발 팀의 책임 소재가 됩니다. 

새로운 스토리를 만들어낼 때, 집필자는 항상 니즈와 성취하려 하는 목적을 설정하고 집중해야 합니다. 이를 통해 팀은 그 이야기를 듣고, 기존 해결 방법에 제한받지 않아야 합니다. 문제를 풀기 위한 최고의 대안을 만들고, 이를 제안하는 데 있어 자유로워야 한다는 뜻입니다.

스토리의 배우와 페르소나는 누구일까요?

스토리의 마지막 사용자입니다. 보통 그 스토리를 요청하거나, 작성한 사용자가 실제 마지막 사용자가 됩니다. 예를 들어, 우리는 위의 예시에서 마케팅 매니저와 그 회사의 CEO를 스토리의 배우로 활용했습니다. 그런데 그 배우는 여러분의 제품과 관련된 모든 사람이 될 수 있습니다. 마지막 고객, 내부 사용자, 외부 사용자, PM 등등.

프로덕트 매니저만이 스토리를 쓰는 유일한 사람인가요?

꼭 그런 것은 아닙니다. PM은 프로덕트 팀의 한 일원으로서 행동하며, 고객과 다른 이해관계자 또는 심지어 팀 자체에서 나올지 모르는 이야기의 편집자로서 수행할 뿐입니다. 다만 PM의 테스크는 스토리를 짜임새 있게 잘 설명하고, 팀원들이 쉽게 이해할 수 있도록 충분한 정보를 담아내는 일입니다. 팀원들이 일을 계획하고 복잡도를 산출하는 것은 구체적인 유저 스토리를 기반으로 합니다.

잘못된 유저 스토리 사례

컨셉의 이해를 돕기 위해 잘못 쓰인 유저 스토리의 몇 가지 예시를 확인해볼까요?

A) 다운로드 버튼이 없다.

B) 나는 첨부된 화면에 더 많은 프로덕트 정보를 노출하고 싶다. 

C) 더 많은 이미지를 넣길 원한다.

최악의 스토리를 사용 가능한 스토리로 바꾸기 위한 한 가지 방법으로 5가지 Why방법을 사용해봅시다. 이 방법은 집필자를 준비하게 만들고, 다음 스토리를 정확하게 구체화할 수 있도록 돕습니다. 

가상으로 위에 언급된 예시들 중 첫 번째 (A)에 이 과정을 사용해봅시다. 

문제: 다운로드 버튼이 안 보인다

• 첫 번째 왜? 리포트를 다운로드를 하기 위해
• 두 번째 왜? 엑셀에서 데이터를 사용하기 위해
• 세 번째 왜? 데이터로 다른 소스와 정보를 크로스-체크하기 위해 
• 네 번째 왜? 판매와 수입 정보를 담은 완벽한 리포트를 제공하기 위해
• 다섯 번째 왜? 이사회는 회사의 중요한 투자 결정을 하기 위해 판매와 수입에 관한 정확한 정보가 필요하다.

이러한 정보와 함께 초기 스토리를 개선이 가능할 것 같습니다. 예를 들면, 

• BI 분석가로서
• 나는 XYZ 리포트의 데이터를 CSV 포맷으로 내보내고 싶다. 
• 회사 중역들에게 우리 제품의 정확한 판매와 수익 정보를 제공할 수 있도록

인수 기준

좋은 유저 스토리는 잘 정의된 인수 기준이 포함된 것임을 잊지 말아야 합니다. 인수 기준이라는 명칭이 암시하는 것은 유저 스토리가 수용되고, 걸러지는 기준을 말합니다. 이는 일련의 지침을 말하며, 각각 명확하게 통과 또는 실패의 결과로 하나의 체크리스트와 같이 작동하여 만족하는 요건과 아닌 요건을 명시합니다.

이러한 인수 기준은 "완료에 대한 정의" 즉, 스프린트[2] 완료에 이르게 됩니다. 말하자면 백로그 항목을 충족하여 개발 작업이 완료된 상태입니다. 훌륭한 인수 기준을 작성하기 위한 한 가지 팁은 준비 단계에서 기능 작동을 보여주는 방법에 대해 생각하는 것입니다. 어떻게 작동할까? 다음 단계에서는 무엇이 필요하지?라는 생각과 모델 히스토리를 다시 활용하여, 몇 개의 인수 기준을 정의할 수 있었습니다. “저는 BI 분석가로서 회사 중역들에게 우리 제품의 판매, 수익에 관한 정밀한 정보를 제공하기 위해 XYZ 리포트의 데이터를 CSV 포맷으로 내보내고자 합니다.”

최종 인수 기준

- XYZ 리포트를 열 때, 여러분은 결과 리스트의 끝에서 한 개의 버튼을 발견할 것이고, CSV 포맷의 리포트를 다운로드할 수 있습니다: 

- 여러분이 그 버튼을 클릭하면 다운로드가 자동으로 실행될 것입니다. 

- 파일은 현재 포맷에서 사용할 수 있도록 호환이 가능한 UTF-8 포맷으로 내보내기 됩니다.

물론 인수 기준들은 훨씬 더 많이 복잡해질 수 있고, 더 많은 과정을 포함할 수도 있습니다. 실제 인수 기준의 수에는 제한이 없습니다. 인수 기준의 수는 해당 유저 스토리의 규모에 달려있습니다. 하지만, 만약 423개의 인수 기준이 있다면 그건 분명 "애자일"방식이 아닐 겁니다.

[1] 여러 개의 유저 스토리로 구성되어있다. 프로덕트 오너(PO)가 정의한 우선순위대로 정렬되어 있으며, 팀원들을 이를 존중하여 실행, 수행할 필요가 있다. PO는 주기적으로 실행 여부에 따라 스토리를 정리해야 합니다. 쉽게 말해 제품 개선을 위한 일정을 일컫는다.

[2] 어려운 프로젝트를 빠른 시간 내에 효율적으로 해결하기 위해 만들어진 팀에 구체적인 방법을 제시하는 5일짜리 프로그램이다.