유저 스토리 작성법 VOC를 프로덕트 백로그로 전환하는 실무가이드

작성자:꾸선 마지막 수정일:

유저 스토리(User Story) 작성법 VOC를 프로덕트 백로그로 전환하는 실무 가이드

수많은 기획자와 개발팀이 고객의 요구를 완벽하게 충족시키기 위해 밤낮없이 고군분투한다. 하지만 고객이 명시적으로 요청한 기능을 토씨 하나 틀리지 않고 그대로 구현하여 시장에 출시했음에도 불구하고, 정작 아무도 해당 기능을 사용하지 않는 참담한 결과를 마주하는 경우가 산업계 전반에 걸쳐 빈번하게 발생한다. 철야 작업을 통해 배포한 기능이 외면받을 때 기획자와 개발팀이 느끼는 허탈감은 이루 말할 수 없다. 기획자 꾸선이 실무 현장에서 수없이 목격하고 분석해 온 바에 따르면, 이러한 비극은 고객의 목소리(VOC)에 담긴 표면적인 ‘요구(Request)’와 실제 고객이 일상에서 겪고 있는 근본적인 ‘문제(Problem)’를 명확히 구분하지 못할 때 싹트게 된다. 이 가이드는 애자일(Agile) 실무의 핵심인 유저 스토리(User Story) 작성법을 통해 단순한 요구사항을 진정한 사용자 가치와 프로덕트 백로그로 번역해 내는 구체적인 방법론을 제시한다.

첫 번째 관문: VOC를 그대로 기능으로 만들 때 발생하는 문제와 유저 스토리 작성법의 필요성

고객이 원하는 것은 기능이 아니라 문제 해결이다

많은 조직이 고객의 목소리를 경청하는 것을 곧 고객이 불러주는 대로 기능을 개발하는 것으로 오해한다. 그러나 고객은 제품 설계 전문가가 아니며, 자신이 겪고 있는 불편함을 자신이 인지하고 있는 제한적인 기술적 상식 내의 ‘해결책’으로 포장하여 표현하는 경향이 짙다. 이를 여과 없이 수용하면 제품은 산으로 가게 된다.

존 디어 사례가 보여주는 ‘요구사항의 함정’

이러한 오류의 위험성을 가장 극명하게 보여주는 사례가 바로 농기계 제조사 존 디어(John Deere)의 잔디깎이 트랙터 개발 일화다. 과거 존 디어의 기획팀은 대대적인 고객 조사를 통해 “회전 반경이 더 작은 트랙터를 만들어 달라”는 다수의 VOC를 수집했다. 엔지니어들은 이 요구를 충실히 반영하여 제자리에서 완벽하게 회전할 수 있는 혁신적인 ‘스핀 스티어(Spin-Steer)’ 트랙터를 개발해 냈다. 기획팀은 완벽한 제품이라 자부했으나, 이 제품은 시장에서 처참하게 실패하고 말았다. 고객이 진정으로 원했던 것은 ‘잔디를 더 빠르고 쉽게 깎는 것’이라는 목적이었을 뿐, 기술적으로 정교한 회전 기능 그 자체가 아니었기 때문이다. 기획자가 고객의 요구를 표면적인 기능으로 곧이곧대로 번역하면, 이처럼 근본적인 사용자 문제를 놓치는 치명적인 결과를 낳는다.

기능 공장이 되면 사용하지 않는 기능이 쌓인다

표면적인 VOC에만 집착하여 맹목적으로 기능을 찍어내는 개발 조직은 이른바 ‘기능 공장(Feature Factory)’으로 전락하게 된다. 기능 공장 체제에서는 사용자에게 전달되는 실질적인 가치나 결과(Outcome)보다는, 단순히 정해진 기한 내에 기능을 얼마나 많이 배포했는가 하는 산출물(Output) 자체가 조직의 성공 지표로 둔갑한다. 그 결과 소프트웨어는 극도로 비대해지고 유지보수 비용은 기하급수적으로 증가하게 된다. 데이터 분석 기업 펜도(Pendo)의 2019년 기능 채택 보고서와 스탠디시 그룹(Standish Group)의 과거 연구 데이터를 종합해 보면, 일반적인 상용 소프트웨어 제품에 포함된 기능 중 무려 64%에서 80%가 거의 또는 전혀 사용되지 않는 것으로 나타났다. 이는 고객의 목소리를 맹목적인 기능 추가로 수용하는 관행이 얼마나 막대한 시간과 자원의 낭비를 초래하는지를 보여주는 강력한 실증적 근거다. 따라서 올바른 기획은 고객이 제시한 어설픈 해결책을 정중히 기각하고, 그 이면에 숨겨진 진짜 문제를 발굴하는 것에서부터 출발해야 한다.

유저 스토리(User Story)란 무엇인가: 대화와 가치의 매개체

요구사항 정의서와 유저 스토리는 무엇이 다른가

고객의 표면적인 요구사항을 넘어 실질적인 가치를 탐구하기 위해 현대 애자일(Agile) 방법론이 채택한 핵심 도구가 바로 유저 스토리(User Story)다. 흔히들 유저 스토리를 기존의 요구사항 정의서나 기능 명세서를 짧게 줄여 쓴 대체재 정도로 오해하곤 한다. 그러나 전통적인 폭포수(Waterfall) 모델에서의 요구사항 정의서가 시스템이 ‘어떻게(How)’ 동작해야 하는지를 데이터베이스 구조나 화면 UI 요소 수준까지 세밀하게 통제하려는 기술적 계약서라면, 유저 스토리는 철저하게 최종 사용자의 관점에서 소프트웨어가 제공해야 할 혜택을 서술하는 도구라는 점에서 본질적인 차이가 있다.

론 제프리스의 3C로 이해하는 유저 스토리

소프트웨어 개발의 선구자인 론 제프리스(Ron Jeffries)는 이러한 유저 스토리의 본질을 ‘3C’라는 개념으로 명쾌하게 체계화했다. 3C 모델을 이해하면 유저 스토리가 단순한 텍스트 쪼가리가 아니라, 팀 전체의 협업과 문제 해결을 이끌어내는 살아있는 프로세스임을 깨달을 수 있다.

3C 구성 요소실무적 의미 및 활용 목적
Card (카드)사용자 문제와 가치를 짧게 요약하여 물리적 포스트잇이나 디지털 칸반 보드에 기록한 매개체다. 이는 완벽한 문서가 아니라, 팀원들 간의 논의를 촉발하기 위한 핵심 단서 역할을 수행한다.
Conversation (대화)기획자(Product Owner)와 개발팀, 디자이너가 모여 카드의 내용을 바탕으로 세부 사항, 사용자의 맥락, 그리고 이를 기술적으로 구현할 수 있는 가장 혁신적이고 효율적인 방법을 치열하게 논의하는 협업 과정이다.
Confirmation (확인)대화를 통해 합의된 방향성을 바탕으로, 해당 기능이 성공적으로 구현되었음을 객관적으로 검증하기 위한 명확한 인수 조건(Acceptance Criteria)을 확정하는 마무리 단계다.
유저 스토리 3C 카드 대화 확인과 Given When Then 인수 조건 작성 과정
유저 스토리 3C 카드 대화 확인과 Given When Then 인수 조건 작성 과정
(이해를 돕기 위해 AI로 생성한 이미지입니다.)

‘As a, I want, So that’로 사용자 가치를 표현한다

이러한 3C 과정을 원활하게 시작하기 위해 실무에서는 “어떤 사용자(Role)로서, 나는 어떤 목적(Benefit)을 달성하기 위해, 특정 기능(Action)을 원한다(As a [Role], I want to [Action], so that [Benefit])”라는 보편적인 템플릿을 널리 활용한다. 이 구조는 요구사항을 작성할 때 누가 이 기능을 필요로 하는지, 시스템이 무엇을 제공해야 하는지, 그리고 그것이 왜 중요한지를 강제적으로 명시하게 만든다. 기획자가 이 형식을 빌려 방향성을 제시하면, 개발팀은 기획서에 적힌 사양을 맹목적으로 타이핑하는 코딩 기계가 아니라, 사용자의 목적을 달성하기 위한 최적의 기술적 대안을 스스로 고민하고 제안하는 진정한 문제 해결사로 거듭나게 된다.

VOC를 유저 스토리로 변환하는 실무 방법론

VOC에서 표면적인 요구와 진짜 문제를 분리한다

산발적으로 쏟아지는 VOC를 접수하여 개발팀이 즉시 작업할 수 있는 유저 스토리로 변환하는 과정은 기획자 꾸선이 가장 공을 들이는 정교한 분석과 번역의 연속이다. 이 변환 프로세스는 VOC 수집에서 시작하여 문제 정의, 사용자 유형(Persona) 정의, 스토리 작성, 인수 조건 설정, 그리고 백로그 편입이라는 일련의 논리적인 흐름을 따른다.

유저 스토리 작성법 VOC를 사용자 문제와 가치 중심의 유저 스토리로 변환하는 과정
유저 스토리 작성법 VOC를 사용자 문제와 가치 중심의 유저 스토리로 변환하는 과정
(이해를 돕기 위해 AI로 생성한 이미지입니다.)

JTBD로 고객이 진짜 해결하려는 일을 찾는다

가장 먼저 선행되어야 할 핵심 단계는 수집된 VOC 이면에 숨겨진 ‘해결해야 할 과제(Jobs to be Done, JTBD)’를 도출하여 진짜 문제를 재정의하는 것이다. 클레이튼 크리스텐슨(Clayton Christensen) 교수와 앤서니 울윅(Anthony Ulwick) 등이 정립한 JTBD 프레임워크는, 고객이 단순히 인구통계학적 특성 때문에 제품을 구매하는 것이 아니라 자신의 삶이나 업무에서 특정 맥락의 문제를 해결하기 위해 제품을 ‘고용(Hire)’한다고 설명한다. 예를 들어, B2B 대시보드 사용자가 “화면 우측 상단에 엑셀 데이터 다운로드 버튼을 추가해 달라”고 강력히 요구(VOC)했다고 가정해 보자. 기획자가 이를 즉각적인 기능으로 수용하여 엑셀 다운로드를 구현하는 것은 하수들의 방식이다. 심층 인터뷰를 통해 사용자의 JTBD를 탐구해 보면, 그들이 엑셀을 다운로드해서 가공한 뒤 ‘매주 월요일 아침 경영진 미팅을 위해 핵심 지표의 추이를 시각적인 요약 보고서로 만들어야 하는’ 근본적인 과제를 안고 있음을 발견하게 된다.

문제를 해결할 핵심 사용자(Persona)를 정의한다

진짜 문제가 정의되면, 이 문제를 겪고 있는 특정 사용자 유형(Persona)을 구체화한다. 모든 사람을 위한 기능은 결국 아무도 만족시키지 못하므로, 해당 과제를 수행하는 핵심 주체의 동기와 행동 패턴을 명확히 설정해야 한다. 그다음, 앞서 논의한 기본 템플릿을 활용하여 유저 스토리를 서술한다. 앞선 엑셀 사례라면 “마케팅 실무자(사용자)로서, 나는 대시보드 데이터를 요약된 PDF 리포트로 바로 출력(기능)하여, 매주 반복되는 보고서 취합 및 가공 시간을 단축(가치)하고 싶다”와 같이 완벽한 가치 중심의 언어로 번역되는 것이다.

문제와 가치를 중심으로 유저 스토리를 작성한다

이 스토리의 완성도를 실무 수준으로 끌어올리는 마지막 화룡점정이 바로 인수 조건(Acceptance Criteria)의 작성이다. 인수 조건은 기능이 배포되어도 좋다는 것을 증명하는 객관적인 기준이자 테스트 시나리오를 제공한다. 개발팀과 QA(품질 보증) 조직 간의 모호성을 제거하기 위해 실무에서는 ‘Given-When-Then’ 포맷을 엄격하게 적용한다.

Given-When-Then으로 인수 조건을 구체화한다

Given-When-Then 단계실무적 의미와 작성 예시
Given (주어진 상황)테스트가 시작되기 전의 사전 조건이나 시스템의 초기 상태를 명확히 규정한다. (예: 마케팅 권한을 가진 사용자가 대시보드에 로그인하여 지난 7일간의 광고 데이터를 조회한 상태에서)
When (행동 발생)사용자가 시스템 내에서 취하는 구체적인 조작이나 트리거 이벤트를 설명한다. (예: 우측 상단의 ‘주간 요약 리포트 PDF 생성’ 버튼을 클릭했을 때)
Then (예상 결과)행동으로 인해 발생해야 하는 시스템의 명확한 상태 변화, 제약 사항, 결괏값을 수치화하여 정의한다. (예: 1. 조회된 데이터 기반의 요약 그래프가 포함된 PDF 파일이 3초 이내에 사용자 기기로 다운로드되어야 한다. 2. 다운로드 내역이 시스템 로그에 기록되어야 한다.)

이처럼 체계적인 번역 프로세스를 거치게 되면, 고객이 감정적으로 던진 불분명한 VOC는 팀 전체가 목적에 깊이 공감하고 즉각적으로 기술적 테스트를 수행할 수 있는 견고하고 논리적인 요구사항으로 탈바꿈하게 된다.

올바른 유저 스토리 작성법과 INVEST 원칙의 적용

유저 스토리는 템플릿보다 ‘가치’가 중요하다

단순히 “As a… I want… So that…” 템플릿의 빈칸을 채워 넣었다고 해서 모든 것이 가치 있는 기획으로 인정받는 것은 아니다. 형태만 흉내 낸 껍데기뿐인 스토리는 오히려 소통의 비용을 증가시킨다. 기획자 꾸선이 실무 현장에서 개발팀의 존경을 받는 기획자와 그렇지 못한 기획자를 구분하는 가장 명확한 기준은 바로 ‘INVEST 원칙’의 체화 여부다. 2003년 빌 웨이크(Bill Wake)가 고안한 INVEST 원칙은 유저 스토리 작성법의 품질을 평가하고 검증하는 가장 핵심적인 체크리스트로 널리 활용되고 있다. 뛰어난 스토리는 다음의 여섯 가지 필수 조건을 반드시 충족해야 한다.

좋은 유저 스토리를 판단하는 INVEST 6원칙

INVEST 원칙의미와 실무 적용 가이드
Independent (독립성)각 스토리는 다른 스토리가 완료되지 않더라도 그 자체로 온전히 개발되고 테스트될 수 있도록 독립적이어야 한다. 서로 꼬리표처럼 의존성이 얽혀 있으면 스프린트 일정을 계획하거나 중간에 우선순위를 변경할 때 심각한 병목 현상이 발생한다.
Negotiable (협상 가능성)스토리는 수정 불가능한 강압적인 계약서가 아니다. 목표로 하는 비즈니스 가치(Why)는 고정되어 있더라도, 그것을 구현하는 화면의 형태나 기술적 접근 방식(How)은 개발팀과의 대화를 통해 언제든 더 나은 방향으로 유연하게 조정될 수 있어야 한다.
Valuable (가치 제공)스토리는 사용자, 고객, 또는 비즈니스에 실질적이고 가시적인 효용을 제공해야 한다. 내부적인 데이터베이스 마이그레이션이나 서버 리팩토링이라 할지라도, 그것이 최종 사용자에게 어떤 가치(예: 응답 속도 향상으로 인한 체류 시간 증가)를 주는지 수직적으로(Vertical) 설명할 수 있어야 한다.
Estimable (추정 가능성)개발팀이 해당 스토리를 구현하는 데 필요한 시간, 노력, 복잡도를 스토리 포인트(Story Points) 단위로 가늠할 수 있을 만큼 요구사항의 내용과 범위가 명확해야 한다. 추정이 불가능하다면 아직 충분히 논의되지 않았거나 쪼개지지 않은 것이다.
Small (적절한 크기)하나의 스프린트(일반적으로 2~4주) 내에, 가급적이면 며칠 이내에 설계부터 테스트까지 쾌속으로 완료될 수 있을 만큼 작업의 단위가 작아야 한다. 거대한 덩어리의 에픽(Epic)은 스프린트에 진입하기 전 반드시 작고 실행 가능한 스토리들로 분할되어야 위험도를 낮출 수 있다.
Testable (테스트 가능성)개발이 완료되었을 때 이것이 성공적으로 목표를 달성했는지 객관적으로 검증할 수 있는 명확한 합격/불합격 기준이 존재해야 한다. 앞서 언급한 명시적인 인수 조건(Acceptance Criteria)이 없는 스토리는 영원히 완료(Done) 상태에 도달할 수 없다.

형식만 갖춘 유저 스토리가 실패하는 이유

현실의 실무 환경에서 이러한 원칙이 얼마나 철저하게 무시되고 있는지 확인하기 위해 IEEE에 발표된 소프트웨어 공학 실증 연구들을 살펴보면 매우 충격적인 사실을 발견할 수 있다. QUS(Quality User Story) 프레임워크와 AQUSA(Automatic Quality User Story Artisan)라는 자연어 처리(NLP) 기반 분석 도구를 통해 수십 개 소프트웨어 기업의 유저 스토리 수만 건을 분석한 결과, 무려 50%에 달하는 스토리에서 문법적, 의미론적 결함이 발견되었다. 연구에 따르면 가장 빈번하게 발생하는 치명적인 오류는 ‘그래서 이 기능을 통해 얻는 궁극적인 이점(Benefit)이 무엇인지’에 대한 가치 서술의 누락, 결과물에 대한 모호한 표현, 그리고 다른 스토리와의 과도한 의존성 설계였다. 이는 정해진 템플릿의 양식만 채우는 기계적인 타이핑 작업만으로는 결코 훌륭한 유저 스토리 작성법을 마스터할 수 없으며, INVEST 원칙에 입각하여 가치와 기술적 한계를 조율하는 치열한 고민이 반드시 동반되어야 함을 강력하게 시사하는 데이터다.

유저 스토리를 프로덕트 백로그로 전환하고 관리하는 프로세스

유저 스토리 매핑을 활용해 사용자 여정과 프로덕트 백로그를 구조화하는 방법
유저 스토리 매핑을 활용해 사용자 여정과 프로덕트 백로그를 구조화하는 방법
(이해를 돕기 위해 AI로 생성한 이미지입니다.)

백로그가 ‘요구사항 쓰레기장’이 되는 이유

정성껏 작성된 양질의 유저 스토리들이 모여 최종적인 집결지를 이루는 곳이 바로 프로덕트 백로그(Product Backlog)다. 그러나 아무리 개별 유저 스토리가 INVEST 원칙을 완벽히 준수하더라도, 이를 단순히 위에서 아래로 우선순위(Priority) 숫자만 매겨 1차원적인 긴 목록으로 쌓아두면 예기치 못한 치명적인 부작용이 속출하게 된다. 기획자 꾸선은 이러한 안타까운 현상을 ‘프로덕트 백로그 파산(Product Backlog Bankruptcy)’이라고 칭한다. 이는 백로그가 고객이 던진 모든 요구사항과 기획자의 아이디어가 무비판적으로 수용되어 끝없이 방치되는 거대한 쓰레기장이나 아이디어의 무덤으로 전락하는 대표적인 안티 패턴(Anti-pattern)이다. 단순히 목록이 통제 불가능할 정도로 길어질수록, 항목들을 리뷰하고 이해하는 데 소모되는 시간이 급증하며 제품이 시장에 나가는 리드 타임은 한없이 지연된다. 결국 팀원들은 전체적인 제품의 방향성을 상실하고 기계적으로 티켓만 쳐내는 소극적인 태도를 보이게 된다.

유저 스토리 매핑으로 백로그에 맥락을 더한다

이러한 평면적인 백로그의 치명적 한계를 극복하고 수많은 유저 스토리를 릴리즈 가능한 의미 있는 개발 계획으로 전환하기 위해 실무에서 필수적으로 활용하는 기법이 바로 제프 패튼(Jeff Patton)이 고안한 ‘유저 스토리 매핑(User Story Mapping)’이다. 평평하고 맥락 없는 백로그 가방에서 낙엽(스토리)을 꺼내어 전체 나무의 구조를 복원하는 이 작업은, 백로그를 2차원 공간으로 시각화하여 제품 전체의 큰 그림(Big Picture)을 팀원 모두가 직관적으로 조망할 수 있게 돕는다.

사용자 여정을 Backbone으로 구조화한다

유저 스토리 매핑의 체계적인 과정은 사용자의 여정을 대변하는 뼈대(Backbone)를 구축하는 것에서부터 시작된다. 사용자가 제품에 진입하여 목표를 달성하고 빠져나가기까지 거치는 핵심 활동(Activities)을 시간순 또는 논리적 흐름에 따라 왼쪽에서 오른쪽으로 수평하게 배치한다. 예를 들어 프로젝트 관리 툴을 기획한다면 ‘프로젝트 생성’, ‘팀원 초대’, ‘업무 계획 수립’, ‘진척도 추적’, ‘결과 보고’라는 거시적인 뼈대가 일렬로 형성된다. 그 후, 앞서 VOC에서 변환하고 다듬어 둔 구체적인 유저 스토리 카드들을 각각의 활동 뼈대 아래에 수직 방향으로 매달아 배치한다. 위쪽에 가깝게 배치될수록 제품의 핵심 과업을 수행하는 데 절대적으로 필요한 우선순위가 높은 스토리이며, 아래로 내려갈수록 부가적인 편의 기능이나 나중에 처리해도 되는 엣지 케이스(Edge case) 스토리들이 자리 잡게 된다.

우선순위를 기준으로 릴리즈를 슬라이싱한다

매핑이 완료되면 2차원 보드 위에 거대한 지도가 완성된다. 기획자는 이 지도 위에 수평으로 선을 그어 릴리즈(Release) 단위를 슬라이싱(Slicing)하는 권한을 행사한다. 첫 번째 가로선 위에 있는 최상단의 필수 스토리들만 묶어내면, 사용자가 가장 기본적인 목적을 달성하는 데 필요한 최소한의 엔드투엔드(End-to-End) 경험을 제공하는 ‘워킹 스켈레톤(Walking Skeleton)’이자 최소 기능 제품(MVP)이 정의된다. 두 번째, 세 번째 가로선 아래의 항목들은 다음 분기나 향후 업데이트를 위한 백로그로 자연스럽게 연기된다.

유저 스토리 매핑을 실제 개발 백로그로 연결한다

이렇게 매핑 보드상에서 명확하게 슬라이스(분할)된 단위들만이 지라(Jira)와 같은 관리 도구의 실제 개발 백로그로 이관되어 이번 스프린트 계획에 착수하게 된다. 이 매핑 과정을 거치면 팀은 파편화된 개별 스토리 하나하나에 집착하다가 전체 사용자 여정이 끊어지는 우를 범하지 않으며, 한정된 자원 안에서 사용자의 목적 달성 흐름 전체에 걸쳐 균형 잡힌 가치를 제공하는 데 온전히 집중할 수 있게 된다.

결론: 좋은 기획은 요구사항이 아닌 사용자 가치로 번역하는 것이다

좋은 기획은 기능이 아니라 사용자 가치를 설계한다

끝없이 쏟아지는 VOC와 요구사항의 홍수 속에서 길을 잃고 방황하는 기획자들과 개발 조직을 위해, 본 연구와 실무 가이드가 전달하고자 하는 명확한 해답은 단 하나다. 훌륭한 프로덕트를 구축하는 뼈대 있는 기획은 결코 고객의 목소리를 있는 그대로 수용하여 맹목적으로 구현하는 것이 아니다. 고객이 아무도 사용하지 않을 기능을 찍어내는 공장에서 벗어나 진정한 성과를 창출하기 위해서는, 고객의 표면적 요구 이면에 도사리고 있는 진짜 문제를 발굴하고 해석하려는 치열한 탐구 정신이 필요하다.

VOC를 가치로 번역하는 것이 기획자의 역할이다

무분별한 VOC 수집에서 멈추지 않고 JTBD 프레임워크를 활용해 문제를 재정의하는 과정, 3C 모델과 INVEST 원칙을 엄격하게 적용하여 가치 중심의 유저 스토리를 서술하는 과정, 그리고 유저 스토리 매핑을 통해 2차원적 맥락을 확보하고 이를 체계적인 프로덕트 백로그로 전환하는 일련의 실무 프로세스는 기획자가 갖추어야 할 가장 과학적이고 효과적인 방법론이다. 이 가이드라인을 깊이 숙지하고 실무에 적용한다면, 개발 후 버려지는 80%의 쓰레기 기능을 양산하며 귀중한 자원을 낭비하는 일 없이, 고객의 문제를 완벽하게 해결하고 비즈니스 지표를 견인하는 가장 영향력 있는 20%의 핵심 가치에 팀의 모든 역량을 온전히 쏟아부을 수 있을 것이다. 유저 스토리 작성법의 궁극적인 본질은 단순한 소프트웨어 기능의 설계가 아니라, 최종 사용자의 실질적인 성공과 더 나은 경험을 설계하는 과정임을 명심해야 한다.

📚 참고 자료 및 출처 (References)

1. 프로덕트 씽킹과 JTBD (Jobs-to-be-Done) 프레임워크

2. 유저 스토리(User Story) 작성법 및 INVEST 원칙

3. 인수 조건(Acceptance Criteria)과 유저 스토리 매핑

4. 기능 우선순위 설정 및 백로그 안티패턴(Anti-patterns)

관련 글 보기