유저스토리 모르는 사람 없게 해 주세요.
[Agile/Scrum] 3단계. 유저 스토리
스크럼 두 번째 단계인 로드맵&프로덕트 백로그 단계에서 할 일을 유저 스토리(User Story) 형태로 만드는 을 추천드렸는데요 ([Scrum] 로드맵&프로덕트 백로그).
다들 뭐야 뭐야 그게 뭐야 하고 궁금해하고 계셨을 텐데 오늘은 바로 그 유저 스토리에 대해 설명드리려고 합니다.
유저 스토리(User Story)는 기본적으로 이렇게 기술합니다.
“고객/사용자는 목적/목표를 위해 필요/욕구를 원한다.”
워킹어스 유튜브프로덕트 백로그의 할 일을 기술할 때, 우리가 흔히 알고 있는 육하원칙 중 누가, 무엇을, 왜 이렇게 세 가지 항목을 포함하여 작성한다고 생각하면, 이해가 더 쉬울 것 같습니다. 잊지 않으셨죠? 우리는 죠스바 팀이라는 거! 앞에서 생각해 본 프로덕트 백로그를 기반으로 ‘블랙핑크 멤버별 죠스바 포장지 디자인 하기’라는 할 일을 유저 스토리(User Story) 형태로 바꾸어 볼까요?
먼저 '누가'에 해당하는 고객이나 사용자가 누구인지를 파악해야 하겠죠. 블랙핑크 멤버별로 제작된 죠스바를 구입할 우리의 고객은 누구일까요? 아마도 죠스바에서 마저 블랙핑크를 만나고 싶은 ‘전 세계의 블랙핑크 팬들'이 아닐까 싶은데요. 내가 블랙핑크 팬이라면, 어떤 디자인을 원할까요? 죠스바 패키지를 보자마자, 한눈에 어떤 멤버인지를 알아보고 싶지 않을까요? 블랙핑크 팬들은 왜 이걸 원할까요? 내 최애 멤버의 죠스바를 딱 찾아서 구입하고 싶어서! 또는 멤버별 패키지를 모두 모으고자 한다면, 빠르게 눈에 들어와야 모두 찾을 수 있기 때문이겠죠?
이 내용을 정리해 유저 스토리(User Story) 형태로 적어보면 다음과 같습니다.
전 세계의 블랙핑크 팬들은 최애 멤버의 죠스바를 구입하기 위해
죠스바 포장지에 그려져 있는 블랙핑크 멤버를 한눈에 딱 알아보고 싶다.
워킹어스 유튜브할 일을 단순히 나열하는 것이 아니라, 이렇게 유저 스토리(User Story) 형태로 표현해야 하는 이유는 무엇일까요?
첫째, 처음부터 끝까지 고객의 니즈를 중심으로
우리가 어떤 제품이나 서비스를 만들 때, 고객의 니즈에 대해 끊임없이 생각하게 되는데요. 그 중요성을 잘 알고 있지만, 또 일을 하는 과정에서 이 부분을 놓치지 않고 가져가기가 쉽지는 않습니다. 하지만 우리가 해야 할 일을 애초에 유저 스토리(User Story) 형태로 작성하게 되면, 이미 고객의 니즈가 반영된 형태의 할 일이기 때문에 이를 달성하는 데 있어서 고객(사용자)을 계속 생각할 수 있는 거죠.
둘째, 자연스러운 디벨롭
블랙핑크 멤버별 죠스바 패키지를 준비하는 우리는 원래 멤버들이 광고에서 촬영한 사진을 활용하려고 했어요. 그런데 유저 스토리(User Story)를 작성하면서, 우리의 주 고객은 전 세계 블랙핑크 팬 중에서도 만 12세 미만 어린이 팬들임을 인지하게 되었습니다. 우리의 주 고객은 캐릭터를 사랑하는 연령대라는 것을 데이터를 통해 알게 되었다고 해 볼까요? 그럼 우리는 패키지에 블랙핑크 사진을 넣기보다는 블랙핑크 캐릭터를 활용하는 것이 더욱 적절하겠죠. 유저 스토리(User Story) 작성한 것을 바탕으로 생각해보면, 각 멤버를 한눈에 알아볼 수 있도록 캐릭터를 구현하는 것이 매우 중요해지겠네요.
셋째, 효율적인 의사소통
일반적으로 우리는 기획안으로부터 어떤 프로젝트를 시작하게 되는 경우가 많잖아요. 이 기획안을 작성하기 위해 시장 조사하고, 고객 데이터 분석하고, 그에 맞는 디자인 콘셉트 시안까지 만들어서 '완벽한' 기획안을 만들려고 하죠. 제품이나 서비스를 만드는 데 있어서 이 모든 것들은 필수적이고, 또 매우 중요합니다. 그러나 이 자료들을 '완벽한(이라 쓰고 안 까이게 라고 읽음)' 기획안으로 만들기 위해, 그 단계에서도 얼마나 많은 시간과 에너지가 드는지, 해보신 분들은 아실 거예요.
애자일과 스크럼에서는 문서 아웃풋 보다 커뮤니케이션을 더 중요하게 생각합니다. 보고를 위한 기획안을 만드는 시간에, 유저 스토리(User Story)를 설정하고 이를 기반으로 자주 소통하고 단계마다의 결과물을 바로바로 공유하고 피드백하는 것이 보다 빠르고 효율적으로 일을 진행시킬 수 있습니다.
또한, 유저 스토리(User Story)는 이 프로젝트를 함께 하는 모든 사람들의 공용어(official language) 역할을 한다는 점에서 의사소통에서 매우 중요한데요. 하나의 프로젝트에는 다양한 전문가들이 모여 협업을 하게 되죠. 이때, 자신의 분야에 대한 전문적인 이야기는 다른 분야의 사람들에게는 이해하기 어려울 수 있습니다. 예를 들면, 어떤 문제가 발생했을 때 처리 방식에 대해 개발자가 서버나 프로그래밍 언어를 사용해 이야기하면, 마케팅이나 디자이너 담당은 뭐가 문제라는 것인지, 이게 왜 안 되는 것인지 이해가 잘 되지 않을 수 있잖아요. 그러나 서로 대화할 때 이미 설정한 유저 스토리(User Story)를 사용해 소통하면, 동일한 언어를 사용하여 소통이 가능합니다. 현장에서 유저 스토리(User Story)가 활용하는 매우 중요한 이유 중의 하나죠.
마지막으로, 계속 말씀드리는 것처럼 스크럼의 각 단계는 팀 단위로도 활용할 수 있지만, 개인으로도 활용이 가능합니다. 유저 스토리(User Story) 역시 마찬가지! 내 업무를 유저 스토리(User Story)로 한 번 변경해 보세요. 새로운 관점에서 여러분의 아이디어를 얻으실 수 있고, 또한 보다 정확하게 목표에 접근할 수 있습니다. 어떤 제품이나 서비스에 기반한 일도 사실은 모두 고객을 고려하지 않을 수 없으니까요.
유저 스토리(User Story) 나는 이렇게 사용해봤다! 일하는 우리가 공유할 수 있는 여러분의 댓글을 기다립니다.
▼ 유저 스토리를 직접 써보고 싶다면?
▼ 본 글을 영상 콘텐츠로 보고 싶다면?
