19장. 사용자 스토리와 백로그

목표와 사용자 가치를 Epic·Feature·Story·Task로 분해하되 백로그 계층이 요구의 근거를 대신하지 않게 한다.

이번 장에서 해결할 질문

학습 목표

• “가치를 작은 전달 단위로 나누면서 업무 규칙과 품질 요구를 어떻게 잃지 않는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

애자일 백로그백로그제품에 필요한 작업·기능·개선 후보를 우선순위와 상태로 관리하는 목록이다.의 계층은 일을 나누는 데 유용하지만 요구의 근거를 자동으로 보존하지는 않는다. Epic·Feature·Story·Task가 단순한 크기 구분으로만 쓰이면 사용자 가치와 정책, 품질 조건이 하위 작업에서 사라질 수 있다. 짧은 항목일수록 연결된 대화와 증거가 더 중요하다.

이 장에서는 목표와 사용자 가치를 Epic·Feature·Story·Task로 분해하고 각 수준의 책임을 구분한다. 인수 조건과 비기능 요구, 업무 규칙을 적절히 연결하며, 백로그가 명세 전체를 대신하지 않도록 출처·결정·추적 정보를 함께 관리하는 방법을 다룬다.

1. 사용자 스토리란 무엇인가

18장18장. 유스케이스와 시나리오사용자 목표와 정상·대안·예외 흐름을 유스케이스로 어떻게 명세하는가?페이지로 이동의 유스케이스는 학생이 강좌를 신청해 결과를 얻는 전체 목표와 분기를 한곳에 모았다. 실제 제품 개발에서는 이 목표를 한 번에 모두 구현하기보다 사용자가 확인할 수 있는 작은 가치 단위로 나눠 순서를 정하고 피드백을 받는다. 사용자 스토리는 그 대화를 시작하고 계획하기 위한 짧은 단위다.

많이 쓰는 형식은 다음과 같다.

<역할>로서, <목표>를 원한다. 그러면 <가치·이유>를 얻을 수 있다.

수강신청 사례의 초안은 이렇게 쓸 수 있다.

학생으로서, 강좌 신청 결과와 사유를 확인하고 싶다. 그러면 승인 여부를 알 수 없어 같은 신청을 반복하지 않고 다음 행동을 결정할 수 있다.

이 한 문장이 스토리의 전부는 아니다. 카드는 제목과 의도를 기억하게 하고, 대화는 규칙·예외·사례를 발견하게 하며, 확인 조건은 기대 결과를 구체화한다. Agile Alliance의 사용자 스토리 설명도 스토리를 단순 문서나 화면 단위로 보지 않고, 가치 있는 제품 증가분을 만들기 위한 지식과 대화로 설명한다. “–로서, –을 원한다” 형식을 잘 채웠다고 준비가 끝난 것이 아니다.

스토리는 보통 다음 속성을 함께 가진다.

스토리는 화면이나 기술 구성요소와 일대일 대응하지 않는다. “신청 버튼 스토리”, “데이터베이스 스토리”보다 학생이 얻는 업무 결과를 중심에 둔다. 기술 작업이 필요하면 6절의 Task로 연결하되 가치 단위와 추적 관계를 잃지 않는다.

2. 사용자 스토리는 요구사항인가

사용자 스토리는 요구를 다루는 한 가지 작업 산출물이지만, 짧은 카드만으로 완전한 요구사항 명세가 되지는 않는다. 조직에 따라 승인된 요구 단위로 관리할 수도 있고 제품 백로그 항목의 형식으로만 쓸 수도 있다. 중요한 것은 이름이 아니라 어떤 정보와 책임을 갖는지다.

앞의 스토리 문장에는 신청 기간, 규칙 기준 시점, 선수과목·정원 분기, 보류, 응답 성능, 판정 기록이 없다. 대화와 수용 기준, 연결된 규칙·모델·품질 요구가 이를 보완한다. 반대로 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다., IR-001IR-001 · 인터페이스 요구자격·운영 흐름.처럼 원자 의무만 모아 두면 작은 사용자 가치와 전달 순서가 잘 보이지 않는다. 두 형식은 목적이 다르다.

스토리를 요구 문서의 각 절에서 기계적으로 하나씩 만들면 사용자 가치가 아니라 기존 문서 구조를 작은 카드로 복사하게 된다. 유스케이스와 스토리도 일대일 변환되지 않는다. UC-REG-01UC-REG-01 · 프로젝트 항목강좌를 신청한다 한 개는 결과 조회, 안전한 보류, 중복 방지 등 여러 가치 증가분으로 나뉠 수 있고, 한 스토리가 여러 유스케이스의 공통 결과를 개선할 수도 있다.

이 책에서는 스토리를 대화와 계획을 위한 가치 단위, 원자 요구를 검증 가능한 의무 단위, 유스케이스를 목표 흐름 단위, 모델을 관계·상태·규칙 단위로 사용한다. 어느 하나도 나머지를 자동으로 대체하지 않는다.

3. Epic

Epic은 한 번의 짧은 개발 주기에 완성하기에는 큰 사용자 스토리나 가치 영역을 가리키는 관행적 이름이다. Scrum Guide가 요구하는 공식 백로그 계층은 아니다. 조직은 Initiative, Capability, Theme 같은 다른 수준을 사용할 수 있으므로 용어와 완료 기준을 먼저 정한다.

수강신청 사례의 Epic 후보는 다음과 같다.

EPIC-REGEPIC-REG · 프로젝트 항목> 수강신청 결과를 설명 가능하고 복구 가능하게 만든다. 수강신청 결과를 설명 가능하고 복구 가능하게 만든다. 학생은 검색부터 신청·결과 확인·취소까지 자신의 상태를 알 수 있고, 운영자는 판정과 복구 근거를 추적할 수 있다.

이 Epic은 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.에 연결되지만 그 자체로 한 번에 구현할 항목은 아니다. 검색, 신청 준비, 판정 결과, 취소·복구처럼 학습과 배포가 가능한 조각으로 나눈다. “수강신청 시스템 개발”처럼 제품 전체와 같은 Epic은 우선순위·완료를 판단하기 어렵다.

Epic을 나눌 때 계층의 균형보다 가치·위험·의존성을 본다.

• 학생이 독립적으로 확인할 수 있는 결과가 있는가?
• 가장 큰 정책·기술 불확실성을 일찍 시험할 수 있는가?
• 일부만 전달해도 안전하고 일관된 경험인가?
• 상위 목표와 운영 지표에 어떤 변화를 기대하는가?
• 제외한 시나리오를 명시해 거짓 완전성을 피했는가?

Epic은 상태가 완료됐다는 사실만으로 사업 목표 달성을 증명하지 않는다. BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.은 이전 학기 대비 수동 재처리 감소를 운영 데이터로 평가해야 한다.

4. Feature

Feature는 여러 스토리를 묶어 사용자가 인식할 수 있는 기능 결과나 제품 능력을 나타내는 팀·조직 관행이다. 이것도 Scrum이 규정한 필수 수준이 아니다. 이 책의 사례에서는 Epic과 Story 사이의 탐색·계획 수준으로 사용한다.

Feature는 메뉴 묶음이 아니다. 조회 화면, 신청 화면, 관리자 화면처럼 나누면 화면 간에 걸친 사용자 결과와 공통 규칙이 끊긴다. 하나의 Feature가 여러 화면·서비스를 거칠 수 있고, 같은 화면이 여러 Feature를 지원할 수 있다.

Feature마다 성공 지표와 경계를 붙인다. 예를 들어 F-RESULTF-RESULT · 프로젝트 항목결과·사유 조회. 현재 상태와 다음 행동 확인.의 결과는 화면 출시가 아니라 학생이 현재 상태·사유를 확인하고 반복 제출을 줄이는 것이다. 이를 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전., BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자., QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.과 연결해 제품 성과와 시스템 성능을 구분한다.

5. Story

Story는 가까운 계획 지평에서 대화하고 구현·검증할 수 있을 만큼 작은 가치 단위다. “작다”는 포인트 숫자가 아니라 한 흐름 안에서 독립적인 피드백을 받을 수 있다는 뜻이다. 다음은 F-APPLYF-APPLY · 프로젝트 항목요청 제출 후 승인·거절·보류 확인.와 F-RESULTF-RESULT · 프로젝트 항목결과·사유 조회. 현재 상태와 다음 행동 확인.를 나눈 후보들이다.

S-02S-02 · 프로젝트 항목학생으로서 승인 결과를 확인하고 싶다. 그러면 수강 계획을 확정할 수 있다.와 S-03S-03 · 프로젝트 항목학생으로서 거절 사유를 확인하고 싶다. 그러면 규칙을 이해하고 선택을 바꿀 수 있다.을 결과 조회 하나로 합칠 수도 있다. 분리 여부는 독립 가치, 정책 불확실성, 시험·배포 가능성을 본다. 승인만 먼저 제공하고 거절을 “오류”로 남기는 증가분은 안전하거나 가치 있지 않을 수 있다. 사용자에게 완결된 세로 조각이어야지 데이터베이스→서버→화면의 가로 기술 층으로 나누지 않는다.

스토리가 지나치게 크다는 신호는 수용 기준이 여러 독립 규칙·역할·상태를 가로지르고 일부만 완료될 수 있을 때다. 지나치게 작은 신호는 사용자·이해관계자가 차이를 확인할 수 없고 오직 내부 작업만 남을 때다. 나눈 뒤에도 상위 Feature와 Epic, 요구·유스케이스 분기를 추적한다.

6. Task

Task는 스토리나 백로그 항목을 구현하기 위해 팀이 수행할 구체적인 작업이다. 사용자 요구가 아니라 방법과 실행 계획에 가깝다. 설계, 코드, 데이터 준비, 시험 자동화, 정책 확인, 운영 문서 작성이 포함될 수 있다.

S-04S-04 · 프로젝트 항목학생으로서 판정 불가 상태와 다음 행동을 알고 싶다. 그러면 불필요한 재제출을 피할 수 있다. “보류 상태와 다음 행동”의 Task 후보를 보자.

• 보류 상태·원인 코드의 도메인 정의와 매핑을 합의한다.
• 규칙 서비스 시간 초과·무효 응답 시험 대역을 준비한다.
• 학생용 결과 제공 인터페이스와 접근성 표현을 설계한다.
• 장애 주입 시험에서 자동 승인이 생기지 않는지 확인한다.
• 보류 조회·재평가의 운영 관측 지표를 추가한다.
• 운영 담당자의 조사·복구 절차 초안을 검토한다.

Task를 스토리처럼 “개발자로서 데이터베이스를 만들고 싶다”라고 포장하지 않는다. 내부 품질·인프라 작업도 필요하지만 누가 왜 하는지 연결하면 된다. Task가 완료됐어도 스토리의 수용 기준과 제품의 Definition of Done을 충족하지 못하면 가치 증가분은 완료되지 않았다.

정책 확인 Task도 중요하다. ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?을 확인하거나 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.을 결정하는 일은 코딩보다 먼저 백로그 위험을 줄인다. 조사 결과가 요구·모델·수용 기준에 반영되어야 하며, “회의 완료”만으로 항목을 닫지 않는다.

7. Acceptance Criteria

Acceptance Criteria, 즉 수용 기준은 특정 스토리가 기대한 행동과 범위를 충족했는지 확인하는 사례·규칙이다. 스토리의 의도를 구체화하지만 전체 제품 품질 기준이나 상세 시험 절차와 같지 않다. 정상·대안·예외와 중요한 경계를 포함하되 모든 조합은 결정표와 요구에 참조할 수 있다.

S-04S-04 · 프로젝트 항목학생으로서 판정 불가 상태와 다음 행동을 알고 싶다. 그러면 불필요한 재제출을 피할 수 있다.의 수용 기준 후보를 Given–When–Then 형태로 적는다. 형식보다 업무 의미가 중요하다.

두 번째 기준에는 재평가 사건과 기준 시점이 미결정이라는 사실을 표시해야 한다. 정책을 임의로 확정한 채 자동화하면 잘못된 요구를 빠르게 검증할 뿐이다.

수용 기준은 다음을 점검한다.

• 역할·선행 상태·입력이 구체적인가?
• 한 사례에서 관찰할 결과와 금지 결과가 있는가?
• 경계·대안·예외 중 위험한 사례가 포함됐는가?
• RULE-001–RULE-005RULE-001–RULE-005RULE-001: 신청자가 적용되는 선수과목의 동시 이수·대체·면제·성적 시점 조건을 충족해야 한다는 업무 규칙 후보다. · RULE-002: 승인으로 계산되는 학점 합계가 학생에게 적용되는 최대 신청 학점을 넘지 않아야 한다는 업무 규칙 후보다. · RULE-003: 시간 충돌 판정. · RULE-004: 분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다. · RULE-005: 우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다., 상태·데이터 모델과 모순되지 않는가?
• 수치 기준은 환경·관측 지점·표본을 참조하는가?
• 합의되지 않은 정책을 테스트 문장으로 몰래 결정하지 않았는가?

수용 기준은 테스트 코드보다 오래 유지될 수 있는 업무 사례다. 자동화할 세부 입력은 시험 설계에서 확장하되, 스토리와 요구·규칙으로 되돌아갈 링크를 남긴다.

8. Definition of Ready

Definition of Ready(DoR)는 팀이 항목을 가까운 개발 계획으로 가져오기 전에 필요한 최소 준비 상태를 합의한 관행이다. 2026년 현재 공식 최신인 2020 Scrum Guide는 Product Backlog와 정제, 개발에 선택 가능한 정도로 구체화된 상태를 설명하지만 Definition of Ready를 공식 Scrum 산출물의 commitment로 규정하지 않는다. 따라서 “Scrum 규칙”이라고 강요하지 않고 팀의 명시적 작업 정책으로 사용한다.

수강신청 팀의 DoR 후보는 다음과 같다.

• 사용자·이해관계자 가치와 상위 목표가 설명되어 있다.
• 주요 수용 기준과 범위 밖 사례가 대화로 확인되었다.
• 필요한 정책 출처·결정권자가 식별되고 치명적 쟁점의 처리 계획이 있다.
• 상태·데이터·인터페이스 의존성이 보이며, 팀이 합리적으로 나눌 수 있다.
• 보안·개인정보·접근성·운영 위험을 검토했다.
• 검증 환경과 필요한 데이터의 확보 가능성을 안다.
• 항목이 한 주기 안에서 목표에 맞게 완성될 크기이거나 분해 계획이 있다.

DoR을 문서 승인 관문으로 만들어 대화를 막지 않는다. 불확실성이 없을 때까지 기다리면 학습이 늦어진다. 위험을 알고 안전하게 시작할 수 있는가가 핵심이다. 예를 들어 ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?이 미확인인 상태에서 보류의 전체 구현을 시작하기는 위험하지만, 시간 초과 시 자동 승인 금지와 보류 상태 관측을 검증하는 탐색 항목은 가능할 수 있다.

체크리스트가 오래돼도 자동으로 통과하는 관행을 막기 위해 실제 실패 회고와 흐름 데이터를 보고 갱신한다. DoR 미충족은 사람을 평가하는 수단이 아니라 준비 결함과 의존성을 드러내는 신호다.

9. Definition of Done

Definition of Done(DoD)은 제품 증가분에 필요한 공통 품질 기준이다. Scrum Guide에서는 Increment에 연결된 공식 commitment다. Product Backlog Item이 DoD를 만족하는 순간 Increment의 일부가 될 수 있으며, 여러 Scrum Team이 같은 제품을 만들면 같은 DoD를 따라야 한다.

DoD와 수용 기준을 구분한다.

수강신청 제품의 DoD 후보에는 코드 검토·자동 시험 같은 개발 활동만 아니라 다음 결과가 포함될 수 있다.

• 승인된 요구·수용 기준과 추적 링크가 갱신되었다.
• 정상·대안·예외와 관련 회귀 시험이 통과했다.
• 권한·개인정보·접근성·감사 기준을 충족했다.
• 상태·규칙·데이터 변경이 모델과 운영 문서에 반영되었다.
• 운영 관측·오류 진단·복구 절차가 준비되었다.
• 제품 증가분이 통합되어 사용 가능한 상태다.

실제 DoD는 팀·제품·조직 표준과 위험에 맞게 승인해야 한다. 모든 품질 목표를 한 줄에 “테스트 완료”로 줄이지 않는다. QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 부하 시험처럼 항상 각 스토리마다 실행하기 어려운 검증도 릴리스 기준선·지속 시험 전략과 연결해 누가 언제 증거를 낼지 정한다.

10. Story Mapping

Story Mapping은 사용자의 활동과 시간 흐름을 가로축에 두고, 각 활동을 실현하는 스토리를 세로로 배치해 전체 여정과 릴리스 조각을 함께 보는 기법이다. 단순 우선순위 목록은 중요한 단계가 빠져도 알아보기 어렵지만, 지도는 검색부터 취소·복구까지 빈칸을 보여 준다.

수강신청 사례의 골격을 만든다.

가로축의 순서는 화면 이동이 아니라 사용자의 업무 이야기다. 세로로 아래로 갈수록 반드시 중요도가 낮다는 절대 규칙도 아니다. 릴리스 선은 사용자가 처음부터 끝까지 의미 있는 결과를 얻는 조각을 만든다. 검색만 완벽히 만들고 신청 결과를 알 수 없는 릴리스는 수평 기술·기능 층이지 완결된 가치 조각이 아니다.

Release 1도 모든 규칙을 생략한 단순 승인을 뜻하지 않는다. 수강신청의 안전에 필요한 선수과목·학점·시간·정원 판정과 거절 결과는 기본 흐름에 포함해야 한다. 미결정인 RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.를 임의로 구현하지 않고, 결정 전에는 우선 배정이 필요한 범위를 제한하거나 릴리스 조건으로 명시한다. RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.의 정원 한도와 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 자동 승인 금지는 첫 릴리스부터 지켜야 할 안전 기준 후보다.

지도에서 발견한 정보 손실을 확인한다.

백로그 계층의 최종 예시는 다음과 같다.

Scrum Guide 다운로드 페이지는 2020년 11월판을 현재 공식판으로 제공한다. Scrum은 Product Backlog를 제품 개선에 필요한 것의 창발적이고 순서 있는 목록으로 정의하지만 사용자 스토리, Epic–Feature–Story 계층, DoR, Story Mapping을 의무 형식으로 지정하지 않는다. Agile Alliance의 Product Backlog 설명도 백로그 항목이 기능뿐 아니라 결함·인프라 등 여러 형식을 가질 수 있음을 보여 준다. IREB RE@Agile 자료는 애자일 환경에서 기능·품질·제약 요구, 사용자 스토리, 우선순위와 규모 조정을 함께 다룬다.

이 장에서 정리한 결과는 Epic–Feature–Story–Task 계층, 스토리 비교표, 수용 기준, DoR·DoD 구분과 릴리스 스토리 맵이다. 다음 장에서는 같은 요구를 경계·프로세스·상태·상호작용·데이터·결정 모델로 다시 표현한다. 그때 스토리 지도에서 숨었던 규칙 조합과 상태 불변식이 더 선명해진다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로