유저 스토리 매핑: INVEST 원칙 및 스토리 분할 방법

평평한 백로그는 우선순위로 정렬된 목록입니다. 다음에 무엇을 구축할지는 알려주지만, 조각들이 어떻게 맞물리는지는 보여주지 않으며, 사용자가 완료할 수 있는 것과는 무관한 10개의 다듬어진 기능을 출시하기 쉽습니다. 사용자 스토리 맵은 스토리를 사용자가 거치는 여정 boyunca 배치하여 전체 제품을 보고 시작부터 끝까지 작동하는 첫 번째 릴리스를 잘라낼 수 있도록 합니다.

이 가이드에서는 스토리 맵을 구축하는 방법, 그 상단 슬라이스를 MVP 범위로 전환하는 방법, 각 스토리를 INVEST 기준으로 점검하는 방법, 그리고 큰 스토리를 스프린트 크기로 나누는 분할 패턴을 다룹니다. 기본 개념이 먼저 필요하시다면 user stories 작성 방법.

사용자 스토리 맵이란 무엇인가

스토리 맵핑은 Jeff Patton이 2005년 기사 “It's all in how you slice it”에서 처음 소개하고, 2008년 게시물 The new user story backlog is a map, 그리고 이후 그의 책 User Story Mapping (O'Reilly, 2014)에서 다뤘습니다. 또한 그의 스토리 맵핑 리소스 와 Agile Alliance 사전 항목.

지도에는 두 가지 방향이 있습니다:

• 왼쪽에서 오른쪽은 서사입니다: 사용자가 순서대로 거치는 큰 활동과 각 활동 안의 단계입니다. 이 상단 행을 백본(backbone)이라고 합니다.
• 위에서 아래로가는 방향은 우선순위와 세부 사항입니다: 각 단계 아래에는 그 단계를 가능하게 하는 스토리가 배치되며, 가장 필수적인 것은 상단에, 대안, 예외 케이스, 그리고 있으면 좋은 기능은 하단에 배치됩니다.

지도에 가로로 그은 선들은 지도를 릴리스 슬라이스로 나눕니다. 첫 번째 선 위쪽의 모든 것은 첫 번째 릴리스입니다; 이는 백본의 모든 활동을 포함해야 하며, 그 범위가 얇더라도 마찬가지입니다.

6단계로 스토리 맵 구축하기

이 작업은 벽에 스티커 노트를 사용하거나 디지털 화이트보드를 통해 수행할 수 있습니다. 범위를 결정할 사람들과 이를 구축할 사람들을 초대하세요: 제품, 디자인, 개발자 최소 1명, 그리고 이상적으로는 고객과 소통하는 사람이 포함되도록 하세요. 작은 제품의 첫 번째 맵은 보통 몇 시간의 워크숍 세션이 소요됩니다.

1. 문제 정의하기

제품의 대상 사용자, 해결하는 문제, 그리고 첫 번째 릴리스가 성공했음을 알려줄 결과를 적어 내려가세요. 이를 지도 상단에 3문장으로 요약하세요. 이후 모든 범위의 축소(컷)는 이 결과에 대해 판단됩니다.

2. 백본 매핑하기

“사용자가 먼저 무엇을 하고, 그 다음에는 무엇을 하는가?”라고 질문하며 각 활동을 카드로 작성하고 왼쪽에서 오른쪽으로 배치하세요. 동사를 사용하세요: “산책꾼 찾기”라고 하고 “검색”이라고 하지 마세요. 그런 다음 각 활동을 단계로 분해하세요. 진행하면서 이야기를 소리 내어 말해 보세요; 누군가 “잠깐, 어떻게 여기까지 온 거지?”라고 물을 때 공백이 명확해집니다.

3. 세부 사항 탐색하기

각 단계 아래에 그 단계를 작동하게 하는 스토리를 추가하세요: 옵션, 대안, 오류 케이스, 관리자 요구 사항 등. 아직 필터링하지 마세요. 전체 여정을 한눈에 볼 수 있을 때 누락된 부분을 사람들이 인식하므로, 이 부분이 맵의 가치를 증명합니다.

4. 워킹 스켈레톤 찾기

워킹 스켈레톤(Alistair Cockburn이 만든 용어)은 끝에서 끝까지 작동하는 제품의 가장 얇은 버전입니다. 각 단계 아래에서 사용자가 없이는 할 수 없는 하나의 스토리를 선택하여 상단으로 이동하세요. 만약 어떤 단계에 필수적인 것이 없다면, 그 단계가 백본에 속해야 하는지 질문해 보세요.

5. 릴리스 슬라이싱하기

가로선을 그려 스토리를 릴리스로 그룹화하세요. 각 슬라이스에 결과를 명시하는 이름을 부여하세요. 예를 들어 “Release 1” 대신 “소유자가 한 번의 산책을 예약하고 결제할 수 있다”와 같이. 각 슬라이스는 단독으로 사용 가능해야 하며, 제품에 대한 질문 하나에 답해야 합니다.

6. 첫 번째 슬라이스 계획 수립 및 맵 유지 관리

첫 번째 슬라이스의 스토리에 대해 인수 기준을 작성하세요(우리의 사용자 스토리 템플릿 에는 세 가지 형식이 있음), 각 스토리를 INVEST 기준으로 점검하고, 너무 큰 것은 분할한 후 스프린트 백로그로 이동하세요. 맵을 가시적으로 유지하고 각 릴리스 후 업데이트하세요; 이는 일회성 워크숍 산출물이 아니라 계획 도구입니다.

예시: 개 산책 앱의 스토리 맵

개 소유자와 지역 산책꾼을 연결하는 마켓플레이스를 위한 압축된 맵입니다. 열은 백본이며, 각 행은 릴리스 슬라이스입니다.

스켈레톤에서 제외된 사항을 확인하세요: 실시간 추적, 리뷰, 앱 내 메시지가 없으며 산책사 승인은 수동으로 처리됩니다. 하지만 소유자는 가입부터 완료된 유료 산책까지의 전체 흐름을 경험할 수 있으며, 이는 타인에게 개 산책을 맡길 의향이 있는지를 테스트하는 데 충분합니다.

맵이 MVP 범위로 전환되는 방법

좋은 맵의 최상위 슬라이스가 바로 MVP 범위입니다. 이를 확정하기 전에 다음 항목을 확인하세요:

• 백본의 모든 활동을 포함해야 합니다. 예약은 가능하지만 결제는 불가능한 제품은 MVP가 아니라 반쪽짜리 데모입니다.
• 하나의 주요 사용자와 하나의 핵심 여정을 제공해야 합니다. 보조 역할(관리자, 파트너)은 여정이 유지되는 데 필요한 최소한의 기능(종종 스프레드시트나 수동 단계)만 제공하면 됩니다.
• 특정 가설을 테스트해야 합니다. 슬라이스가 답하는 질문을 옆에 적어두세요. 예를 들어 “소유자는 산책사를 만나기 전에 비용을 지불할 것인가?” 등입니다.
• 백그라운드에서의 수동 작업은 허용됩니다. 초기 사용자에 한해 산책사 승인을 수동으로 하거나 요약을 직접 보내는 것은 괜찮으며, 자동화할 가치가 있는 부분을 알려줍니다.
• 예산과 일정에 맞아야 합니다. 맞지 않는 경우, 전체 열을 제거하기보다 각 열 내의 스토리를 줄이세요(아래 패턴을 사용하여 분할).

기술적 공동 창업자가 없는 창업자에게 이 맵은 개발 팀에게 전달할 수 있는 가장 유용한 문서입니다. 전체 제품, 첫 번째 릴리스 및 절감의 근거를 한 페이지에 보여주기 때문입니다. 우리의 가이드는 비기술적 창업자가 MVP를 구축하는 방법 다음 단계에 대해 설명합니다.

INVEST 체크리스트

스토리가 맵에 배치되면, 첫 번째 슬라이스의 각 스토리를 2003년 Bill Wake가 INVEST in good stories, and SMART tasks.

독립성은 완전히 충족하기가 가장 어려운 기준이며, 규칙이 아닌 목표로 삼는 것이 좋습니다. 작음과 테스트 가능성은 엄격하게 지켜야 할 기준입니다.

사용자 스토리 분할 방법

스토리를 세로로 분할하세요: 모든 조각은 시스템의 모든 계층을 통해 사용자가 볼 수 있는 무언가를 전달해야 합니다. 계층별로 분할(“데이터베이스 구축”, “API 구축”, “화면 구축”)하면 세 가지가 모두 완료될 때까지 아무것도 전달되지 않아 분할의 목적을 무너뜨립니다. 이 패턴들은 Humanizing Work의 사용자 스토리 분할 가이드 에 Richard Lawrence와 Peter Green이 집필한 내용으로, 대부분의 경우를 다룹니다.

워크플로우 단계

다단계 프로세스를 각 단계로 분할하거나, 먼저 간단한 엔드투엔드 버전을 구축하고 나중에 단계를 추가하세요. “산책 예약”은 다음과 같이 나뉩니다: 슬롯 요청; 산책 수락; 소유자에게 확인 알림. 이후: 산책이 다른 시간을 제안.

비즈니스 규칙 변형

스토리에 여러 규칙이 있다면 가장 일반적인 규칙을 먼저 출시하세요. “취소 환불”은 다음과 같이 나뉩니다: 24시간 전에 취소 시 전액 환불; 24시간 이내 취소 시 부분 환불; 산책 시작 후 취소 시 환불 없음.

데이터 변형

하나 종류의 데이터로 시작하고 나머지를 추가하세요. “위치 검색”은 다음과 같이 나뉩니다: 우편번호로 검색; 현재 위치로 검색; 지도에서 영역을 그려 검색.

먼저 정상 경로, 그다음 비정상 경로

주요 성공 경로를 구축한 후, 실패를 개별 스토리로 처리하세요. 발생 빈도와 피해 규모에 따라 순서대로 정합니다. “카드 결제”는 다음과 같이 나뉩니다: 결제 성공; 카드 거절; 결제 제공자 사용 불가.

운영

“개 관리”에는 생성, 보기, 편집, 삭제가 숨어 있습니다. 첫 출시에는 보통 생성과 보기만 필요합니다.

인터페이스 또는 플랫폼 변형

먼저 하나의 플랫폼이나 하나의 입력 방식으로 출시하세요. 첫 사용자들이 허용한다면, 모바일보다 웹을 먼저, 다른 언어보다 영어를 먼저 출시하세요.

먼저 간단한 버전, 성능은 나중에

먼저 작동하게 만들고, 그다음 빠르게 만드세요. 50명의 산책이 3초 안에 로드되는 산책 목록은 파일럿 도시에는 충분합니다. 숫자가 이를 정당화할 때, 별도의 스토리로 최적화하세요.

스파이크

미지 요소(“두 전화 플랫폼 모두에서 백그라운드에서 실시간 위치를 얻을 수 있나요?”)로 인해 스토리를 추정할 수 없을 때, 짧은 시간 제한된 조사를 분리하세요. 스파이크의 산출물은 지식과 더 잘 추정된 스토리이며, 출시된 기능은 아닙니다.

SPIDR: 기억하기 위한 짧은 버전

Mike Cohn은 주요 분할 기법을 SPIDR이라는 약어로 분류합니다: Spikes, Paths, Interfaces, Data, Rules(사용자 스토리를 분할하는 다섯 가지 간단하지만 강력한 방법). 스토리가 너무 크고 어디서부터 시작해야 할지 모르겠다면, 이 다섯 가지를 그 순서대로 검토하세요.

스토리 매핑의 흔한 실수

• 사용자 활동이 아닌 기능을 매핑하는 것. “로그인, 대시보드, 설정”으로 구성된 백본은 화면을 설명할 뿐 여정을 설명하지 않습니다.
• 첫 번째 슬라이스를 한 열 깊이로 구축하는 것. 예약 기능이 존재하기 전에 가입 절차를 다듬는 것은 테스트할 것이 아무것도 없는 상황을 초래합니다.
• 맵을 너무 상세하게 만드는 것. 벽에 수용 기준을 작성하고 있다면 매핑에서 리파인먼트로 넘어간 것입니다.
• 개발자가 없는 상태에서 매핑하는 것. 개발자 없이 그린 슬라이스는 상위 부분에 비용이 큰 스토리를 숨기는 경우가 많습니다.
• 맵을 완성된 것으로 취급하는 것. 각 릴리스 후 배운 내용을 맵에 반영하고 다음 슬라이스를 다시 잘라내야 합니다.

자신의 맵에 적용할 수 있는 잘 형성된 스토리를 확인하려면, 저희의 사용자 스토리 예시.

스토리 매핑 도구

모두가 한 방에 모인 첫 세션에는 여전히 벽과 스티키 노트가 가장 효과적입니다. 원격 팀의 경우 Miro와 FigJam과 같은 일반 화이트보드에는 스토리 맵 템플릿이 제공되며, StoriesOnBoard와 같은 전용 도구는 맵을 백로그 트래커와 동기화합니다. Jira와 유사한 트래커는 에픽별로 그룹화된 스토리를 보여줌으로써 백본을 제공하지만, 릴리스 슬라이스를 보기 위해서는 일반적으로 플러그인이나 화이트보드가 필요합니다. 팀이 계속 열어둘 도구를 선택하세요. 아무도 업데이트하지 않는 맵은 1~2개의 스프린트 안에 유용성을 잃습니다.

자주 묻는 질문

맵이나 아이디어가 있어 첫 번째 슬라이스를 구축해야 하는 경우? 끝에서 끝까지 작동하는 MVP 범위를 잘라내고 짧은 스프린트로 출시하는 데 도움을 드릴 수 있습니다. 확인하기 월간 개발 플랜.