수용 기준이 있는 사용자 스토리 템플릿 (무료)

유저 스토리 템플릿은 두 가지 역할을 합니다. 모든 스토리가 동일한 세 가지 질문(누가, 무엇을, 왜)에 답하도록 하고, 팀이 스토리가 완료되었음을 어떻게 알지 여부를 기록할 고정된 장소를 제공합니다. 이 페이지에서는 한 줄 스토리 형식, 복사할 수 있는 전체 카드 템플릿, 세 가지 형식의 수용 기준, 준비 완료 및 완료 기준, 그리고 실제 예시를 제공합니다.

유저 스토리가 처음이시라면, 먼저 user stories 작성 방법가이드를 참고하신 후, 여기로 돌아와 템플릿을 확인해 주세요.

한 줄 유저 스토리 템플릿

대부분의 팀은 2001년 런던의 Connextra 팀에서 나온 형식과 Mike Cohn의 책 User Stories Applied에서 대중화된 형식을 사용합니다(유저 스토리 개요 는 좋은 입문 자료입니다):

나는 [유저 유형]로서, [행동 또는 기능]을 원하며, 이를 통해 [혜택 또는 결과]를 얻고 싶다.

각 부분은 특정 역할을 수행합니다:

• “As a(나는 ~로서)”는 첫 구매자, 계정 관리자, 재방문 환자 등 실제 유저 유형을 지칭합니다. “As a user(유저로서)”는 팀에게 아무것도 알려주지 않습니다. 페르소나가 있다면 그 이름을 사용하세요.
• “I want(나는 ~을 원한다)”는 유저가 하거나 얻는 것을 유저의 언어로 설명합니다. 솔루션(“드롭다운”, “Redis 캐시” 등)을 설명해서는 안 되며, 팀이 최선의 방법을 찾을 수 있도록 여지를 남겨야 합니다.
• “So that(이를 통해)”는 가치를 명시합니다. 이는 가장 자주 생략되지만 가장 중요한 부분으로, 팀이 동일한 결과를 제공하는 더 간단한 옵션을 제안하는 방법이자, 프로덕트 오너가 우선순위를 결정하는 기준이 됩니다.

이 문장이 요구사항 그 자체는 아니라는 점을 기억하세요. Ron Jeffries는 스토리를 카드, 대화, 확인 세 가지로 설명했습니다(3C). 템플릿은 카드와 확인(수용 기준)에 도움이 되지만, 대화를 대체할 수는 없습니다.

전체 유저 스토리 카드 템플릿

한 줄 형식은 스티키 노트에는 충분합니다. 백로그 도구에서는 스토리를 순위 매기고, 추정하며, 테스트할 수 있도록 몇 가지 더 많은 필드가 필요합니다. 여기서는 유용하다고 생각하는 필드를 제시하며, 팀이 읽지 않는 필드는 제외하세요.

“Context and notes”는 간결하게 유지하세요: 사양 페이지로 변질되면 해당 스토리는 아마도 에픽이며 분할이 필요합니다(우리의 스토리 매핑 가이드 에서 방법을 확인하세요).

복사 가능한 유저 스토리 템플릿

이 내용을 Jira 또는 Linear 이슈의 설명 필드, Notion 데이터베이스 템플릿 또는 스프레드시트의 헤더 행에 붙여넣으세요. 괄호로 표시된 텍스트를 대체하고 사용하지 않는 줄은 삭제하세요.

• ID: [PROJECT-000]
• 제목: [동사 + 목적어, 예: “인보이스를 CSV로 내보내기”]
• 스토리: [유저 유형]로서, [행동 또는 기능]을/를 원하며, 이를 통해 [혜택]을/를 얻고 싶습니다.
• 배경: [지금 이것이 중요한 이유; 리서치, 지원 티켓 또는 지표에 대한 링크]
• 수용 기준: [3~7개의 테스트 가능한 조건, 체크리스트 또는 Given/When/Then 형식]
• 범위 외: [이 스토리가 의도적으로 다루지 않는 사항]
• 디자인: [프레임 또는 프로토타입에 대한 링크]
• 의존성: [다른 스토리, 서비스 또는 결정 사항]
• 우선순위: [Must / Should / Could 또는 백로그 순위]
• 추정: [팀이 입력하는 포인트 또는 사이즈]
• 미해결 질문: [스프린트가 시작되기 전에 답변해야 할 사항]

“범위 외” 항목은 논쟁을 방지합니다: 카드에 “SMS 재설정 미포함”이라고 적어두는 것이 스프린트 리뷰에서 누군가가 포함되었다고 가정했음을 발견하는 것보다 낫습니다.

수용 기준이란 무엇이며, 누가 작성하는가

수용 기준은 스토리가 제품 오너에게 수용되기 위해 충족해야 하는 조건입니다. 이는 코드가 작동하는 방식이 아니라 유저 관점의 관찰 가능한 행동을 설명합니다. 좋은 기준은 다음과 같습니다:

• 테스트 가능: 해석 없이 예 또는 아니오를 말할 수 있어야 합니다. “빠름”은 테스트 가능하지 않지만, “결과가 2초 이내에 표시됨”은 테스트 가능합니다.
• 해당 스토리에 특화됨: 모든 스토리에 적용되는 규칙(코드 리뷰, 스테이징 배포)은 완료 정의(Definition of Done)에 속하며, 여기에 속하지 않습니다.
• 구현 세부 사항 배제: 어떤 컴포넌트나 테이블이 이를 실현하는지가 아니라, 어떤 일이 일어나는지 서술합니다.
• 실패에 대한 정직함: 적어도 하나의 기준이 잘못된 입력, 네트워크 없음 또는 권한 누락 상황을 다루어야 합니다.
• 적음: 3~7개의 기준이 건강한 범위입니다. 10개 이상이면 보통 스토리를 분할해야 함을 의미합니다.

제품 오너는 기준에 대해 책임을 지지만 단독으로 작성하지 않아야 합니다. 가장 신뢰할 수 있는 패턴은 제품, 개발자, 테스터 간의 짧은 리파인먼트 대화(흔히 “three amigos”라고 함)입니다: 가치는 무엇인가, 어떻게 구축될 것인가, 어떻게 실패할 수 있는가.

형식 1: 체크리스트 수용 기준

단순한 조건 목록입니다. 작성과 읽기가 가장 빠르며, 단순한 스토리와 수동 테스트를 수행하는 팀에 적합합니다.

스토리: 재구매 고객으로서, 이메일로 비밀번호를 재설정하기를 원하며, 이를 통해 지원팀에 연락하지 않고 계정에 다시 접근할 수 있기를 바랍니다.

• 로그인 화면에는 재설정 폼을 여는 “비밀번호를 잊으셨나요?” 링크가 있습니다.
• 등록된 이메일 주소를 제출하면 1분 이내에 재설정 링크가 전송됩니다.
• 재설정 링크는 한 번만 작동하며 30분 후 만료됩니다.
• 새 비밀번호는 기존 비밀번호 규칙을 충족해야 하며, 폼은 어떤 규칙이 실패했는지 알려줍니다.
• 성공적으로 재설정된 후, 해당 계정의 다른 모든 세션이 로그아웃됩니다.
• 등록되지 않은 주소를 제출해도 등록된 주소와 동일한 확인 메시지가 표시되므로, 양식은 누가 계정을 가지고 있는지 드러내지 않습니다.

행동이 직관적인 경우 체크리스트를 사용하세요. 단점으로는 시작 상태와 이벤트의 순서를 숨기며, 이는 다음 형식에서 명시적으로 다룹니다.

형식 2: Given/When/Then (Gherkin) 인수 기준

Given/When/Then은 Chris Matts와 Dan North가 설명한 행동 주도 개발(BDD)에서 유래했습니다. BDD 소개. 각 시나리오는 시작 컨텍스트(Given), 동작(When), 예상 결과(Then)를 명시합니다. Gherkin 은 Cucumber와 유사한 도구에서 사용되는 이 언어의 구조화된 버전으로, 이렇게 작성된 시나리오는 소량의 수정만으로 자동화 테스트로 변환될 수 있습니다.

다음은 유효한 링크로 재설정하는 동일한 비밀번호 재설정 스토리를 세 가지 시나리오로 표현한 것으로, 두 가지 실패 경로가 포함됩니다.

시나리오 1: 유효한 링크로 재설정

• Given anna@example.com으로 등록된 계정이 있고
• And 비밀번호 재설정을 요청했으며
• When 30분 이내에 재설정 링크를 열고 규칙을 충족하는 새 비밀번호를 입력하면
• Then 비밀번호가 변경되고
• And 로그인 상태가 되며
• And 다른 세션은 로그아웃됩니다.

시나리오 2: 링크가 만료된 경우

• Given 30분 전에 비밀번호 재설정을 요청했으며
• When 리셋 링크를 열면
• Then 링크가 만료되었다는 메시지를 확인하고
• And 새 링크를 보내는 버튼이 제공됩니다.

시나리오 3: 이메일 주소가 등록되지 않은 경우

• Given sam@example.com에 대한 계정이 존재하지 않고
• When sam@example.com으로 비밀번호 재설정을 요청하면
• Then 등록된 사용자가 보는 것과 동일한 확인 메시지를 보고
• And 이메일이 전송되지 않습니다.

하나의 시나리오가 여러 입력값(예: 거부되어야 할 비밀번호 목록)으로 실행되어야 하는 경우, Gherkin의 시나리오 개요(Scenario Outline)를 사용하여 한 번만 작성하고 입력값을 예제 테이블에 나열할 수 있습니다.

Gherkin은 가독성을 유지하세요: 시나리오당 하나의 행동만 포함하고, 선언적으로 작성(“When I request a reset link”)하여 클릭 단위로 작성(“When I click the Send button”)하지 않도록 하세요. 이렇게 하면 시나리오가 리디자인을 견딜 수 있습니다.

형식 3: 규칙 기반 인수 기준

주로 비즈니스 규칙(가격, 자격, 검증, 권한)으로 구성된 스토리의 경우, 규칙을 직접 명시하고 복잡한 조합에 대해서만 시나리오를 추가하세요.

스토리: 쇼핑객으로서, 결제 시 할인 코드를 적용하여 프로모션 가격을 지불하고 싶습니다.

• 규칙 1: 주문당 하나의 코드만 사용.
• 규칙 2: 백분율 코드는 배송비나 세금이 아닌 제품 소계에만 적용됩니다.
• 규칙 3: 최소 구매 금액이 있는 코드는 할인 전 소계가 최소 금액을 충족할 때만 적용됩니다.
• 규칙 4: 만료되거나 사용된 코드는 이유를 명시하는 메시지로 거부됩니다.
• 규칙 5: 항목을 제거하여 소계가 최소 금액 아래로 떨어지면 코드가 제거되고 알림이 표시됩니다.

하나의 스토리에서 여러 형식을 혼합할 수 있습니다. 일반적인 패턴은 로직에 규칙을 적용하고 사람들이 가장 잘못 이해하기 쉬운 사례에 대해 두세 개의 Given/When/Then 시나리오를 사용하는 것입니다.

준비 완료 정의 vs 완료 정의

수용 기준은 하나의 스토리에 특화됩니다. 준비 완료 정의와 완료 정의는 모든 스토리에 적용되는 팀 전체의 합의입니다.

The Scrum Guide 준비 완료 정의는 Scrum의 일부가 아니며, 많은 팀이 반쯤 이해된 작업이 스프린트에 들어오는 것을 막기 위해 채택하는 관행입니다(아래 Agile Alliance의 준비 완료 정의 그리고 완료 정의(Definition of Done)).

준비 완료 정의 예시

• 스토리가 템플릿을 따르고 “so that” 부분이 채워져 있습니다.
• 수용 기준이 제품, 개발, 테스트에 의해 작성되고 검토되었습니다.
• 디자인이 연결되었거나, 팀이 디자인이 필요하지 않다고 합의했습니다.
• 의존성이 완료되었거나 일정 잡힘.
• 팀이 추정을 완료했으며, 하나의 스프린트에 맞습니다.

완료 정의 예시

• 모든 수용 기준 통과.
• 코드가 검토되어 main 브랜치에 병합됨.
• 자동화 테스트가 새로운 동작을 커버하고 전체 테스트 스위트가 통과함.
• 기본 접근성 검사 통과(키보드 사용, 라벨, 대비).
• 스테이징에 배포되었으며 제품 오너가 승인함.

준비 완료 기준(Definition of Ready)을 게이트가 아닌 정제(refinement)를 위한 체크리스트로 취급하세요. 한 항목이라도 빠진 스토리를 모두 거부하면 작업이 느려지고, 스토리가 시작하려던 대화가 일어나지 않게 됩니다.

실제 사례

다른 종류의 제품에서 가져온 두 가지 추가 스토리. 나머지 40개는 여기서 확인하세요. 사용자 스토리 예시.

SaaS: 팀원 초대(체크리스트)

워크스페이스 관리자로서, 팀원을 이메일로 초대하여 내 로그인 정보를 공유하지 않고도 우리 프로젝트를 볼 수 있도록 하고 싶습니다.

• 관리자는 멤버 페이지에서 '초대' 버튼을 볼 수 있으며, 다른 역할은 볼 수 없습니다.
• 관리자는 전송 전에 역할을(멤버 또는 관리자) 선택할 수 있습니다.
• 초대 이메일은 1분 이내에 도착하며, 링크는 7일간 유효합니다.
• 이미 멤버인 주소를 초대하면 두 번째 초대를 보내는 대신 메시지가 표시됩니다.

이커머스: 나중에 구매할 항목 저장(Given/When/Then)

구매할 준비가 되지 않은 쇼핑객으로서, 카트에 있는 항목을 저장된 목록으로 이동시켜 주문 합계에 영향을 주지 않고 나중에 다시 찾을 수 있도록 하고 싶습니다.

• Given 로그인 상태이고 카트에 두 개의 항목이 있을 때
• When 한 항목에서 '나중에 저장'을 선택하면
• Then 해당 항목이 저장된 목록으로 이동합니다
• And 카트 합계에서 해당 항목을 제외하고 다시 계산됩니다
• Given 로그인하지 않은 상태일 때
• When '나중에 저장'을 선택하면
• Then 로그인을 요청받으며, 로그인 후 해당 항목이 저장됩니다

Jira, Linear, Notion 또는 스프레드시트에서 템플릿 사용

Jira에서는 Story 이슈 유형을 사용하고 템플릿을 설명란에 붙여넣으세요(또는 관리자가 별도 필드를 추가했다면 수용 기준을 해당 필드에 유지하세요). Linear에서는 이슈 템플릿으로 저장하세요. Notion에서는 데이터베이스 템플릿에 넣어 새 백로그 페이지가 미리 채워지도록 하세요. 스프레드시트는 스토리당 한 행으로 구성하여 첫 번째 백로그나 워크숍에 적합하지만, 여러 사람이 편집하기 시작하면 트래커로 이동하세요. 어떤 도구를 사용하든, 사람들이 채워 넣을 수 있을 만큼 템플릿을 간결하게 유지하세요.

AI를 사용하여 스토리와 수용 기준 작성

언어 모델은 스토리와 기준의 초안을 작성하는 데 뛰어납니다. 잘 작동하는 프롬프트 예시:

당신은 제품 관리자입니다. 아래 기능에 대해 'As a [user], I want [action], so that [benefit]' 형식으로 사용자 스토리를 작성하세요. 각 스토리에 대해 Given/When/Then 형식으로 3~6개의 수용 기준을 추가하고, 적어도 하나의 실패 경로(unhappy path)를 포함하세요. 가정 사항과 미해결 질문은 별도로 나열하세요. 기능: [기능, 사용자 및 제약 조건 설명].

그 후 초안을 다른 입력 자료와 마찬가지로 검토하세요:

• 사용자가 실제로 대화해 본 세그먼트인지, 아니면 일반적인 '사용자'인지?
• 모델이 비즈니스 규칙, 제한 사항 또는 숫자를 발명했나요? 그것들을 여러분의 것으로 대체하세요.
• 실패 경로가 사용자들이 실제로 겪는 상황인가요? 초안은 정제 대화를 대체할 수 없습니다.

자주 묻는 질문

팀이 여러분의 스토리를 작동하는 소프트웨어로 전환하도록 도와드릴까요? 백로그나 아이디어를 가져오세요. 스프린트 크기의 스토리로 형성하고 구축하는 데 도움을 드리겠습니다. 확인하기 월간 개발 플랜.