유저 스토리는 그 일로 이득을 보는 사람의 관점에서 설명한 작은 작업 단위입니다. 이 글은 "~로서, ~하고 싶다, ~하기 위해" 템플릿을 하나씩 풀어 보고, 좋은 스토리를 위한 INVEST 체크리스트를 설명하고, 큰 아이디어를 팀이 끝낼 수 있는 스토리로 나누는 법을 보여 줍니다. 읽는 데 약 12분이 걸립니다.
유저 스토리는 필요한 것을 화면 앞 사용자의 입장에서 일상적인 말로 설명합니다. 어떻게 만들지는 일부러 빼 둡니다. 그것은 만들 사람들이 필요로 하는 사람들과 대화하며 함께 정합니다.
이를 기억하는 잘 알려진 방법이 론 제프리스(Ron Jeffries)의 3C입니다.
꼭 유저 스토리를 써야 하나요? 아닙니다. 스크럼 가이드는 명확한 항목으로 된 프로덕트 백로그만 요구합니다. 유저 스토리는 사람과 가치에 초점을 맞추기 때문에 그 항목을 쓰는 인기 있는 방법일 뿐입니다. 버그 수정이나 업그레이드는 그냥 작업으로 두어도 됩니다.
대부분의 팀은 간단한 문장 하나를 씁니다. 부분마다 역할이 다르고, 스토리는 가장 약한 부분만큼만 강합니다.
이득을 보는 사람. 직접 찾아가 이야기할 수 있을 만큼 구체적으로 쓰세요.
그 사람이 할 수 있기를 바라는 것. 팀의 말이 아니라 그 사람의 말로.
이득. 팀에게 성공의 모습을 알려 주고, 프로덕트 오너가 무엇을 먼저 할지 정하도록 돕습니다.
| 부분 | ❌ 약함 | ✅ 더 나음 |
|---|---|---|
| 누가 | 사용자로서… | 학비를 내는 학부모로서… |
| 무엇을 | …결제 페이지에 저장된 카드 드롭다운을 원한다… | …전에 쓴 카드로 결제하고 싶다… |
| 왜 | …결제하기 위해서. | …학기마다 지갑을 찾지 않고 몇 초 만에 결제하기 위해서. |
빌 웨이크(Bill Wake)가 2003년에 스토리가 작업할 준비가 됐는지 빠르게 확인하는 방법으로 INVEST를 제안했습니다. 스토리를 스프린트에 넣기 전에 이 여섯 글자로 점검하세요.
서로 의존하는 스토리는 정해진 순서대로 해야 해서 계획이 경직됩니다.
실패: "스토리 B는 스토리 A가 끝나야만 작동한다."
해결: 둘을 합치거나, 각각 쓸 만한 것을 전달하도록 다르게 나누세요.
스토리는 대화의 출발점이지, 모든 세부 사항이 정해진 계약서가 아닙니다.
실패: 스토리에 이미 화면 배치와 데이터베이스 테이블이 정해져 있다.
해결: 필요는 남기고 설계는 빼세요. 세부 사항은 함께 정합니다.
모든 스토리는 팀 밖의 누군가가 알아차리고 신경 쓸 무언가를 전달해야 합니다.
실패: "개발자로서, 데이터베이스 테이블을 만들고 싶다."
해결: 세로로 잘라서 각 스토리가 필요한 만큼의 데이터베이스, 로직, 화면을 모두 포함하게 하세요.
아무도 크기를 짐작하지 못한다면 아직 모르는 중요한 것이 있다는 뜻입니다.
실패: 아무도 API를 본 적 없는데 "새 결제 업체와 연동".
해결: 짧게 기한을 정한 스파이크로 먼저 알아본 뒤 스토리를 쓰세요.
작은 스토리는 보드를 빠르게 지나가고 피드백을 일찍 줍니다. 스프린트마다 여러 개를 끝내는 것을 목표로 하세요.
실패: "환자로서, 내 예약을 관리하고 싶다."
해결: 나누세요. 5부를 보세요.
어떻게 테스트할지 말할 수 없다면 언제 끝났는지도 말할 수 없습니다.
실패: "…앱이 더 빠르게 느껴지도록."
해결: 인수 기준을 추가하세요: "검색의 95%에서 2초 안에 결과가 나온다."
| 점검 | 결과 |
|---|---|
| I 독립적 | ✅ 기존 예약 데이터를 씁니다. 다른 스토리가 먼저 필요하지 않습니다. |
| N 협상 가능 | ✅ 목록 모양을 정하지 않습니다. 기존 일정에 필터 하나로 충분할 수도 있습니다. |
| V 가치 있음 | ✅ 빈 시간대가 채워져 더 많은 환자를 보고 손실 수입이 줄어듭니다. |
| E 추정 가능 | ✅ 팀이 예약 데이터를 잘 압니다. |
| S 작음 | ✅ 며칠짜리 작업입니다. 대기 환자에게 연락하는 것은 별도 스토리입니다. |
| T 테스트 가능 | ✅ 네, 4부의 인수 기준으로 가능합니다. |
인수 기준은 스토리가 받아들여지려면 충족해야 하는 조건입니다. 대화에서 합의하고, 스토리에 적고, 완료로 치기 전에 확인합니다. 흔히 쓰는 형식은 Given / When / Then입니다: 시작 상황, 행동, 기대하는 결과.
큰 아이디어는 보통 처음엔 한 스프린트에 끝내기엔 너무 큽니다. 그렇게 큰 스토리를 흔히 에픽이라고 부릅니다. 목표는 그것을 각각이 여전히 실제로 쓸모 있는 작은 스토리로 자르는 것입니다. 층별로가 아니라 케이크 전체를 얇게 세로로 자르는 것이죠. 자세한 기법은 슬라이싱과 사이징 글에서 다룹니다.
좋은 목표지만 너무 큽니다. 의사 선택, 시간 찾기, 확인, 결제, 알림, 취소, 일정 변경까지 모두 들어 있습니다. 이렇게 나눌 수 있습니다.
| 나누는 기준 | 방법 | 예약 에픽에서 |
|---|---|---|
| 업무 흐름 단계 | 사용자 여정의 단계마다 스토리 하나. | 시간 보기 → 예약 → 확인 받기 |
| 단순한 경우 먼저 | 가장 단순한 버전을 만들고 변형을 더합니다. | 먼저 이번 주 담당의 한 명, 그다음 모든 의사, 모든 병원, 모든 날짜 |
| 정상 경로, 그다음 예외 | 다 잘 될 때 작동하게 하고, 그다음 문제를 처리합니다. | 먼저 빈 시간 예약. "예약하는 사이 다른 사람이 가져간 시간"은 그다음. |
| 작업 종류 | 만들기, 바꾸기, 없애기는 보통 별도 스토리입니다. | 예약, 취소, 일정 변경 |
| 사용자 역할 | 사람마다 다른 버전이 필요할 수 있습니다. | 환자 본인 예약, 그다음 부모가 자녀 예약 |
| 업무 규칙 | 규칙 하나하나가 스토리가 될 수 있습니다. | "24시간 전까지 취소 가능", "한 주에 최대 2건 예약" |
| 품질은 나중에 | 먼저 작동하게, 그다음 빠르거나 세련되게. | 먼저 기본 시간 목록, 그다음 "2초 안에 결과 표시" |
층별로 나누지 마세요. "스토리 1: 데이터베이스. 스토리 2: 백엔드. 스토리 3: 화면." 셋이 다 끝날 때까지 환자에게 아무것도 주지 못하므로 INVEST의 V를 통과하지 못합니다. 각 스토리는 필요한 모든 층을 관통해야 합니다.
| # | 유저 스토리 |
|---|---|
| 1 | 환자로서, 이번 주 내 담당의의 빈 시간을 보고 싶다. 전화하지 않고 편한 시간을 고르기 위해서. |
| 2 | 환자로서, 빈 시간을 예약하고 확인 이메일을 받고 싶다. 예약이 확정됐다는 것을 알기 위해서. |
| 3 | 환자로서, 24시간 전까지 예약을 취소하고 싶다. 가지 못하는 진료에 비용을 내지 않기 위해서. |
| 4 | 환자로서, 예약을 다른 빈 시간으로 옮기고 싶다. 취소하고 처음부터 다시 하지 않기 위해서. |
| 5 | 환자로서, 전날 SMS 알림을 받고 싶다. 예약을 잊지 않기 위해서. |
| 6 | 환자로서, 그룹 내 모든 병원의 아무 의사나 고르고 싶다. 담당의 예약이 꽉 찼을 때 더 빨리 진료받기 위해서. |
스토리 2는 예약과 확인을 일부러 합쳤습니다. 확인 없는 예약은 환자가 제대로 됐는지 확신하지 못하게 하므로, 그것만으로는 가치가 없습니다.
여러 종류의 제품에서 가져온 좋은 스토리와 핵심 인수 기준입니다. 각 스토리가 실제 사람을 정하고, 설계 없이 목표를 설명하고, 중요한 이유를 대는 것을 눈여겨보세요.
| ❌ 약한 스토리 | 문제점 | ✅ 더 나음 |
|---|---|---|
| "사용자로서, 대시보드를 원한다." | 누가 모호하고, 무엇이 불분명하고, 왜가 없음. | 영업 관리자로서, 이번 주 놓칠 위험이 있는 거래를 보고 싶다. 잃기 전에 개입하기 위해서. |
| "개발자로서, 데이터베이스를 구성하고 싶다." | 사용자 가치가 없는 기술 작업. | 그것이 필요한 첫 스토리의 일부로 넣으세요. 정말 따로여야 한다면 스토리가 아니라 그냥 작업으로 두세요. |
| "고객으로서, 오른쪽 아래에 파란 제출 버튼을 원한다." | 필요가 아니라 디자인 결정. 협상할 수 없음. | 고객으로서, 위로 다시 스크롤하지 않고 양식을 보내고 싶다. 마지막 단계를 놓치지 않기 위해서. |
| "관리자로서, 사용자를 추가, 수정, 삭제, 내보내기 하고 싶다." | 스토리 네 개가 하나에. 작지 않음. | 넷으로 나누세요: 추가, 수정, 삭제, 내보내기. 각각의 "왜"와 함께. |
| "쇼핑객으로서, 더 빠른 결제를 원한다." | 테스트할 수 없음: 얼마나 빨라야 빠른 것인가? | 같은 스토리에 기준 추가: "재방문 고객은 3단계 이하, 60초 안에 결제를 마친다". |
| "결제 페이지" | 스토리가 아니라 그냥 이름표. 누가, 무엇을, 왜가 없음. | 그 뒤에 있는 필요를 쓰세요. 예: 2부의 학비 스토리. |