아래에는 제품 유형(SaaS, 이커머스, 모바일 앱, 마켓플레이스, 핀테크, 헬스케어, 내부 도구, AI 기능)별로 그룹화된 40개의 user stories가 있습니다. 각 항목에는 acceptance criteria가 포함되어 있으며, acceptance criteria가 없는 story는 절반만 작성된 것과 같습니다. 그 다음에는 나쁜 것에서 좋은 것으로의 재작성, epic을 story로 분해한 예시, 비기능적 story가 있습니다.
2026년 10월 업데이트. user stories가 처음이신가요? 먼저 user stories 작성 방법을 확인한 후, 적용할 자료를 위해 여기로 돌아오세요.
여기서 사용하는 형식
각 story는 역할-기능-혜택 템플릿을 따릅니다:
나는 [유형의 사용자]로서 [목표 또는 행동]을 원하며, 이를 통해 [혜택]을 얻고 싶습니다.
Acceptance criteria는 표에 맞도록 짧은 번호 매긴 체크리스트이며, 사용자 스토리 템플릿 는 Given/When/Then 대안을 보여줍니다. 숫자(시간 제한, 임계값)는 귀사의 비즈니스 규칙을 위한 플레이스홀더입니다.
SaaS 및 B2B user story 예시
B2B story는 계정, 역할, 청구와 관련되며, 두 명의 사용자가 동시에 중요합니다: 작업을 수행하는 사람과 비용을 지불하는 관리자입니다.
| User story | Acceptance criteria |
|---|---|
| 1. 워크스페이스 관리자로서, 팀원을 이메일로 초대하여 우리 계정에서 작업할 수 있도록 하고 싶습니다. | (1) 초대 링크는 7일간 유효합니다. (2) 전송 전에 역할(관리자, 멤버 또는 뷰어)을 선택합니다. (3) 이미 멤버인 사람을 초대하면 중복 전송 대신 오류가 표시됩니다. |
| 2. 계정 소유자로서, 앱 내에서 유료 플랜으로 업그레이드하여 영업 담당자와 연락하지 않고도 좌석을 추가할 수 있기를 원합니다. | (1) 확인하기 전에 가격과 변경 사항을 확인합니다. (2) 결제가 성공하면 즉시 새로운 제한 사항이 적용됩니다. (3) 카드 결제가 거절되면 현재 플랜을 유지하며 거절 사유를 확인합니다. |
| 3. 팀 멤버로서, 회사 Google 또는 Microsoft 계정으로 로그인하여 별도의 비밀번호를 사용할 필요가 없기를 원합니다. | (1) 로그인 시 두 가지 옵션 모두 제공됩니다. (2) 허용된 회사 도메인에서 처음 로그인하면 해당 워크스페이스에 추가됩니다. (3) 관리자가 허용하지 않은 도메인의 계정은 명확한 메시지와 함께 거부됩니다. |
| 4. 관리자로서, 활동 보고서를 CSV로 내보내어 재무팀과 공유할 수 있기를 원합니다. | (1) 내보내기 시 현재 적용된 필터가 사용됩니다. (2) 파일에는 헤더 행과 ISO 날짜(YYYY-MM-DD)가 포함됩니다. (3) 50,000행을 초과하는 내보내기는 페이지를 차단하지 않고 다운로드 링크로 이메일로 전송됩니다. |
| 5. 신규 사용자로서, 문서를 읽지 않고도 첫 번째 유용한 결과를 얻을 수 있도록 짧은 온보딩 체크리스트를 제공받기를 원합니다. | (1) 완료되면 자동으로 체크되는 3~5단계로 구성됩니다. (2) 체크리스트를 닫고 도움말 메뉴에서 다시 열 수 있습니다. (3) 진행 상황이 기기 간에 동기화됩니다. |
| 6. 워크스페이스 관리자로서, 고객의 보안 설문조사에 답변할 수 있도록 권한 변경에 대한 감사 로그를 제공받기를 원합니다. | (1) 각 항목은 누가, 무엇을, 언제, 어떤 IP에서 변경했는지 기록합니다. (2) 관리자를 포함한 누구도 항목을 편집하거나 삭제할 수 없습니다. (3) 로그는 사용자 및 날짜로 필터링하고 내보낼 수 있습니다. |
이커머스 사용자 스토리 예시
쇼핑 스토리는 재고 부족, 카드 결제 거절, 배송 지연 및 반품과 같은 부정적 경로에서 성패가 갈립니다.
| User story | Acceptance criteria |
|---|---|
| 7. 쇼핑객으로서, 사이즈와 색상으로 제품을 필터링하여 구매할 수 있는 상품만 볼 수 있기를 원합니다. | (1) 필터는 재고가 있는 사이즈와 색상만 제공합니다. (2) 결과가 새로고침 없이 업데이트되며, URL에 필터가 유지되어 뷰를 공유할 수 있습니다. (3) “전체 초기화”는 목록을 초기화합니다. |
| 8. 게스트 쇼핑객으로서, 계정을 생성하지 않고도 결제하여 빠르게 구매할 수 있기를 원합니다. | (1) 이메일, 주소 및 결제 정보만 필요합니다. (2) 결제 후 한 번의 클릭으로 계정을 생성할 수 있습니다. (3) 확인 이메일이 1분 이내에 도착합니다. |
| 9. 쇼핑객으로서, 결제 전에 배송 날짜를 확인하여 주문이 제시간에 도착하는지 알 수 있기를 원합니다. | (1) 각 배송 옵션에 예상 배송 기간이 표시됩니다. (2) 주소를 변경하면 기간이 업데이트됩니다. (3) 별도로 배송되는 상품은 개별 날짜가 표시됩니다. |
| 10. 쇼핑객으로서, 품절된 상품이 재입고되면 알림을 받아 계속 확인하지 않아도 되기를 원합니다. | (1) 재고가 0일 때 “알림 받기”가 “장바구니 담기”를 대체합니다. (2) 상품이 재입고되면 이메일을 한 번 받고 알림이 종료됩니다. (3) 이메일은 내 사이즈가 미리 선택된 상태로 제품 페이지를 엽니다. |
| 11. 고객으로서, 온라인으로 반품을 시작하여 지원팀에 이메일을 보내지 않아도 되기를 원합니다. | (1) 반품 기간 내 주문에만 반품 버튼이 표시됩니다. (2) 상품과 사유를 선택하면 라벨 또는 QR 코드를 받습니다. (3) 환불 상태가 주문 이력에 표시됩니다. |
| 12. 매장 관리자로서, 주말 프로모션을 실행할 수 있도록 만료 날짜가 있는 할인 코드를 생성하기를 원합니다. | (1) 백분율 또는 고정 금액, 날짜 및 사용 한도를 설정합니다. (2) 결제 시 만료된 코드는 “이 코드는 만료되었습니다”라고 표시됩니다. (3) 허용하지 않는 한 코드는 결합할 수 없습니다. |
배달 앱의 결제 흐름 및 주문 추적에 대해서는 온디맨드 앱의 필수 요소.
모바일 앱 사용자 스토리 예시
모바일 스토리는 웹 스토리가 자주 생략할 수 있는 기준이 필요합니다: 신호 없음, 기기 권한 및 생체 인증.
| User story | Acceptance criteria |
|---|---|
| 13. 출퇴근자로서, 신호가 없는 기차에서도 티켓을 보여줄 수 있도록 오프라인에서 티켓을 사용할 수 있기를 원합니다. | (1) 티켓과 QR 코드는 연결 없이 열립니다. (2) 오프라인 배너가 마지막으로 동기화된 시간을 표시합니다. (3) 연결이 필요한 작업은 설명과 함께 비활성화됩니다. |
| 14. 사용자로서, 매번 비밀번호를 입력하지 않도록 Face ID 또는 지문으로 로그인하기를 원합니다. | (1) 첫 번째 비밀번호 로그인 후 제공되며, 사용자가 선택할 때까지 꺼진 상태입니다. (2) 3회 실패하거나 기기의 생체 인증 정보가 변경되면 비밀번호를 요청합니다. (3) 설정에서 꺼낼 수 있습니다. |
| 15. 사용자로서, 앱이 스팸하지 않도록 받을 푸시 알림을 선택하기를 원합니다. | (1) 설정에 각 알림 카테고리가 개별 토글과 함께 나열됩니다. (2) 변경 사항이 즉시 적용됩니다. (3) 앱은 첫 실행 시가 아니라 사용자가 카테고리를 처음 켤 때 알림 권한을 요청합니다. |
| 16. 신규 사용자로서, 가입 전에 앱을 사용해 볼 수 있어 가치가 있는지 결정할 수 있기를 원합니다. | (1) 계정 없이도 주요 콘텐츠를 탐색할 수 있습니다. (2) 저장하거나 게시할 때만 가입이 요청됩니다. (3) 게스트로 저장한 내용은 계정으로 이관됩니다. |
| 17. 사용자로서, 친구에게 보낼 수 있도록 항목을 WhatsApp 또는 Messages로 공유하기를 원합니다. | (1) 공유 기능은 전화기의 기본 공유 시트를 사용합니다. (2) 링크는 앱이 설치된 경우 앱에서 항목을 열며, 그렇지 않으면 웹사이트에서 열립니다. (3) 링크 미리보기에는 항목의 제목과 이미지가 표시됩니다. |
마켓플레이스 및 온디맨드 사용자 스토리 예시
마켓플레이스는 최소 세 가지 역할(구매자, 공급자, 운영자)을 가지며, 각 역할에 대한 스토리가 완성되기 전까지는 기능이 거의 완료되지 않습니다.
| User story | Acceptance criteria |
|---|---|
| 18. 고객으로서, 언제 문 앞에 있어야 하는지 알기 위해Courier의 위치를 지도에서 추적하고 싶습니다. | (1) 픽업 후, Courier의 위치는 최소 15초마다 업데이트됩니다. (2) 도착 예정 시간이 표시되며 최신 상태로 유지됩니다. (3) 배송 완료 시 위치 공유가 중지됩니다. |
| 19. 서비스 제공자로서, 수락할 수 있는 요청만 받기 위해 주간 가용 시간을 설정하고 싶습니다. | (1) 각 요일별 시간을 설정하고 특정 날짜를 차단할 수 있습니다. (2) 고객은 설정된 시간 외의 슬롯을 요청할 수 없습니다. (3) 가용 시간 변경 시 이미 확정된 예약은 취소되지 않습니다. |
| 20. 고객으로서, 다른 고객이 잘 선택할 수 있도록 작업 후 제공자를 평가하고 싶습니다. | (1) 평가 프롬프트는 작업이 완료로 표시될 때 나타나며 14일간 열려 있습니다. (2) 1~5개의 별점과 선택 사항인 코멘트를 남깁니다. (3) 완료된 예약이 있는 고객만 해당 제공자를 리뷰할 수 있습니다. |
| 21. 판매자로서, 현금 흐름을 계획할 수 있도록 각 지급금이 언제 도착하는지 확인하고 싶습니다. | (1) 각 완료된 주문에는 수수료 차감 후 지급금과 예상 지급 날짜가 표시됩니다. (2) 지급 이력에는 날짜, 금액, 주문 내역이 나열됩니다. (3) 지급이 실패하면 실패 이유와 해결 방법이 안내됩니다. |
| 22. 마켓플레이스 운영자로서, 금지된 항목이 사이트에 올라오지 않도록 새 판매자의 목록을 라이브로 게시하기 전에 검토하고 싶습니다. | (1) 새 판매자의 첫 목록은 검토 대기열로 들어갑니다. (2) 검토자는 판매자가 볼 수 있는 이유를 들어 승인하거나 거부합니다. (3) 승인 후, 판매자의 이후 목록은 플래그가 지정되지 않는 한 즉시 게시됩니다. |
핀테크 사용자 스토리 예시
규제 대상 제품에서는 EU 및 UK의 결제용 강력한 고객 인증 또는 신원 확인과 같이 일부 기준이 법으로 정해집니다. 이를 출발점으로 삼고, 규정 준수 자문가와 규칙을 확인하십시오.
| User story | Acceptance criteria |
|---|---|
| 23. 신규 고객으로서, 지점을 방문하지 않고도 계정을 개설할 수 있도록 앱에서 신원을 확인하고 싶습니다. | (1) 앱에서 신분증 사진과 셀피를 촬영합니다. (2) 인증이 통과, 실패, 또는 검토가 필요한지 확인하고 다음 단계를 안내받습니다. (3) 이미지는 암호화되어 저장되며 모든 직원 접근이 기록됩니다. |
| 24. 카드 소유자로서, 카드를 분실할 경우 아무도 사용할 수 없도록 즉시 카드를 동결하고 싶습니다. | (1) 동결은 몇 초 내에 적용되며 새로운 카드 결제는 거절됩니다. (2) 동결 해제 시 동일한 카드로 복원됩니다. (3) 화면에는 동결 상태에서의 정기 결제 처리 방식이 설명됩니다. |
| 25. 사용자로서, 매달 돈이 어디로 가는지 볼 수 있도록 거래가 자동으로 분류되기를 원합니다. | (1) 새로운 거래는 표시된 후 1분 이내에 카테고리가 지정됩니다. (2) 카테고리를 변경하면 동일한 상점의 향후 거래가 선택한 카테고리를 따릅니다. (3) 월간 뷰에는 카테고리별 합계가 표시됩니다. |
| 26. 계좌 보유자로서, 누군가가 비밀번호를 알게 되더라도 자금이 안전하도록 큰 금액의 이체에 2차 확인이 필요하도록 하고 싶습니다. | (1) 설정한 한도 이상의 이체는 앱 내 승인 또는 일회용 코드가 필요합니다. (2) 새로운 수취인 대상 첫 번째 결제에도 동일한 단계가 필요합니다. (3) 실패한 확인은 기록되며 알림을 받습니다. |
| 27. 소규모 사업자로서, 고객이 카드로 결제할 수 있도록 즉시 결제 링크가 포함된 견적서를 보내고 싶습니다. | (1) 견적서 이메일에는 안전한 결제 링크가 포함됩니다. (2) 결제가 성공하면 견적서가 자동으로 결제 완료로 표시됩니다. (3) 기한이 지난 견적서는 사용자가 선택한 날짜에 알림이 전송됩니다. |
헬스케어 사용자 스토리 예시
건강 데이터는 미국의 HIPAA, EU의 GDPR과 같은 규칙에 해당하므로, 대부분의 기준에 접근 제어와 감사 로그가 포함됩니다. 적용되는 규칙의 세부 사항은 해당 분야 전문가와 확인하십시오.
| User story | Acceptance criteria |
|---|---|
| 28. 환자로서, 클리닉에 전화하지 않고도 온라인으로 예약을 하고 싶습니다. | (1) 선택한 의료진과 방문 유형에 대한 빈 슬롯만 표시됩니다. (2) 캘린더 추가 링크가 포함된 확인서가 이메일 또는 SMS로 도착합니다. (3) 클리닉의 마감 시간 전까지 취소 또는 변경할 수 있으며, 마감 후에는 클리닉 전화번호가 표시됩니다. |
| 29. 환자로서, 용량을 놓치지 않도록 약물 복용 알림을 받고 싶습니다. | (1) 각 약물에 대한 알림 시간을 설정합니다. (2) 허용하지 않는 한 잠금 화면 알림에 약물 이름이 표시되지 않습니다. (3) 각 용량을 복용했거나 건너뛴 것으로 표시하고 이력을 확인할 수 있습니다. |
| 30. 의료진으로서, 방문을 빠르게 준비할 수 있도록 환자의 최근 검사 결과를 한 화면에서 보고 싶습니다. | (1) 최근 12개월의 결과가 최신순으로 표시되며, 기준 범위를 벗어난 값이 강조됩니다. (2) 환자의 케어 팀만 해당 화면을 열 수 있습니다. (3) 모든 뷰가 접근 로그에 기록됩니다. |
| 31. 환자로서, 아무것도 설치하지 않고 브라우저에서 영상 예약에 참여하고 싶습니다. | (1) 링크는 데스크톱 및 모바일의 최신 Chrome, Safari, Edge, Firefox에서 작동합니다. (2) 의료진이 입장시키기 전까지 대기실에서 대기합니다. (3) 카메라와 마이크 체크가 먼저 실행되며, 접근이 차단된 경우 도움이 제공됩니다. |
내부 도구 및 관리자 사용자 스토리 예시
내부 도구는 '우리만 사용한다'는 이유로 사용자 스토리 없이 구축되는 경우가 많으며, 이로 인해 명확한 목적 없이 100개 이상의 필드가 쌓이게 됩니다.
| User story | Acceptance criteria |
|---|---|
| 32. 지원 에이전트로서, 저는 도구 전환 없이 답변할 수 있도록 고객의 최근 주문과 티켓을 한 화면에서 보고 싶습니다. | (1) 이메일, 전화번호 또는 주문 번호로 검색할 수 있습니다. (2) 화면에는 최근 10건의 주문과 모든 미해결 티켓이 표시됩니다. (3) 에이전트는 결제 정보를 볼 수 있지만 수정할 수 없습니다. |
| 33. 운영 관리자로서, 저는 수백 건의 레코드를 수동으로 편집하지 않도록 CSV에서 주문 상태를 일괄 업데이트하고 싶습니다. | (1) 적용 전에 변경될 행과 오류가 있는 행을 미리보기로 확인할 수 있습니다. (2) 오류가 있는 행은 건너뛰고 보고됩니다. (3) 각 일괄 업데이트는 실행한 사람과 함께 기록됩니다. |
| 34. IT 관리자로서, 저는 퇴사자의 계정을 한 곳에서 비활성화하여 모든 내부 도구에 대한 접근 권한을 즉시 박탈하고 싶습니다. | (1) 비활성화 시 모든 활성 세션이 즉시 종료됩니다. (2) 미완료 작업은 상사로 재배정됩니다. (3) 데이터는 삭제되지 않고 보존 정책에 따라 보관됩니다. |
| 35. 재무 담당자로서, 저는 임계값을 초과하는 지출에 승인이 필요하도록 설정하여 대규모 구매가 검토되도록 하고 싶습니다. | (1) 임계값을 초과한 지출은 지정된 승인자에게 전달됩니다. (2) 승인자는 이메일이나 앱에서 코멘트를 남기며 승인하거나 거부할 수 있습니다. (3) 3영업일 이내에 처리되지 않은 요청은 상급자에게 에스컬레이션됩니다. |
AI 기능 사용자 스토리 예시
AI 기능에는 추가 기준이 필요합니다: 모델이 알지 못할 때의 처리 방법, 데이터의 저장 위치, 그리고 도움이 되는지 판단하는 방법입니다. 전송, 게시 또는 결제되는 모든 사항에 대해 인간이 통제권을 유지해야 합니다.
| User story | Acceptance criteria |
|---|---|
| 36. 지원 에이전트로서, 저는 각 티켓에 대해 AI가 초안을 작성해 주기를 원하며, 이를 통해 일반적인 질문에 더 빠르게 답변하고 싶습니다. | (1) 초안은 답변 상자에 AI 생성으로 표시되며, 제가 '보내기'를 클릭할 때만 전송됩니다. (2) 사용된 도움말 센터 아티클에 링크가 포함됩니다. (3) 관련 아티클이 없으면 추측하지 않고 해당 사실을 명시합니다. |
| 37. 사용자로서, 저는 평이한 언어로 내 문서에 대해 질문할 수 있기를 원하며, 이를 통해 모든 파일을 열지 않고도 답변을 찾고 싶습니다. | (1) 답변은 제가 볼 수 있는 문서만 사용합니다. (2) 각 답변은 출처 구절에 링크합니다. (3) 문서에 답변이 없으면 알지 못한다고 명시합니다. |
| 38. 팀원으로서, 저는 긴 회의록의 짧은 요약을 원하며, 이를 통해 1분 만에 상황을 파악하고 싶습니다. | (1) 요약에는 결정 사항과 담당자가 지정된 실행 항목이 나열됩니다. (2) 저는 요약을 재생성하거나 편집할 수 있습니다. (3) 자동 요약은 없으며, 누군가 요청할 때만 요약이 생성됩니다. |
| 39. 워크스페이스 관리자로서, 저는 팀의 AI 기능을 켜거나 끌 수 있기를 원하며, 이를 통해 데이터 정책을 준수하고 싶습니다. | (1) 하나의 설정으로 워크스페이스의 모든 AI 기능을 제어합니다. (2) 페이지에는 데이터를 처리하는 제공자와 학습에 사용되는지 여부가 명시됩니다. (3) 변경 사항은 몇 분 내에 모든 사용자에게 적용되며 기록됩니다. |
| 40. 제품 관리자로서, 저는 사용자가 AI 제안을 수락, 편집 또는 거부하는 빈도를 확인하여 기능이 도움이 되는지 판단하고 싶습니다. | (1) 모든 제안은 수락, 편집 또는 거부로 기록됩니다. (2) 대시보드에서 주간별 비율을 확인할 수 있습니다. (3) 분석 데이터에는 결과만 저장되며, 프롬프트나 문서 내용은 저장되지 않습니다. |
나쁜 스토리 vs 좋은 스토리: 6개의 사용자 스토리 재작성
각 재작성은 구체적인 사용자를 명시하고, 목표에서 디자인 결정 사항을 배제하며, 실질적인 이점을 제공합니다.
| 약한 스토리 | 실패하는 이유 | 더 나은 버전 |
|---|---|---|
| 시스템은 PDF 내보내기를 지원해야 합니다. | 요구사항 언어: 사용자도 이유도 없습니다. | 회계사로서, 저는 매월의 명세서를 PDF로 다운로드하여 기록에 첨부하고 싶습니다. |
| 사용자로서, 저는 앱이 사용하기 쉬웠으면 합니다. | 테스트할 수 없으며, 구체적인 목표가 없습니다. | 초보 사용자로서, 저는 템플릿으로 첫 프로젝트를 시작하여 몇 분 안에 앱이 어떻게 작동하는지 보고 싶습니다. |
| 개발자로서, 저는 PostgreSQL로 마이그레이션하고 싶습니다. | 기술적 작업이며, 사용자 가치는 숨겨져 있습니다. | 분석가로서, 저는 회의 중 검토할 수 있도록 월간 보고서가 3초 이내에 로드되기를 원합니다. 마이그레이션은 이 스토리 하의 작업이 됩니다. |
| 고객으로서, 저는 결제하고 싶습니다. | 너무 큼: 결제 방법, 실패 및 환불을 숨기고 있습니다. | 고객으로서, 저는 결제 시 카드로 결제하여 한 단계로 주문을 완료하고 싶습니다. Apple Pay, 환불 및 결제 실패는 별도의 스토리가 됩니다. |
| 사용자로서, 나는 우측 상단에 파란색 저장 버튼을 원합니다. | 설계를 일방적으로 지시하고 논의할 여지를 남기지 않습니다. | 편집자로서, 브라우저가 닫히더라도 작업이 손실되지 않도록 변경 사항이 자동으로 저장되기를 원합니다. |
| 관리자로서, 보고서를 볼 수 있도록 보고서를 보고 싶습니다. | 이점은 목표를 단순히 반복할 뿐입니다. | 영업 관리자로서, 분기가 끝나기 전에 정체된 거래를 파악할 수 있도록 각 영업사원의 파이프라인을 단계별로 보고 싶습니다. |
The 사용자 스토리 가이드 이러한 재작성 뒤에 있는 INVEST 체크리스트를 설명합니다.
에픽에서 스토리로: 분해 예시
에픽은 하나의 스프린트로는 너무 큰 결과물입니다. 여기 B2B SaaS 제품에서 “고객이 구독하고 결제할 수 있다”를 각자 독립적으로 배포할 수 있는 스토리로 분해한 예시입니다:
- 새로운 고객으로서, 저는 아무런 부담 없이 제품을 평가할 수 있도록 카드 없이 무료 체험을 시작하기를 원합니다.
- 체험 사용자로서, 저는 데이터와 설정을 유지할 수 있도록 체험 기간이 끝나기 전에 플랜을 선택하고 카드를 등록하기를 원합니다.
- 계정 소유자로서, 저는 세금 신고를 위해 과거 청구서를 보관할 수 있도록 다운로드할 수 있기를 원합니다.
- 계정 소유자로서, 저는 요금이 예상치 못하게 청구되지 않도록 매년 갱신 일주일 전에 이메일 알림을 받기를 원합니다.
- 계정 소유자로서, 저는 카드 만료로 인해 팀이 잠금되지 않도록 결제 실패 시 유예 기간을 제공받기를 원합니다.
MVP의 경우, 1번부터 3번 스토리만으로도 과금을 시작하는 데 충분합니다. 4번과 5번은 고객이 갱신하기 시작하면 중요해집니다. 유저 스토리 매핑 가이드 그 경계를 어떻게 그리는지 보여줍니다.
기술적 및 비기능적 사용자 스토리 예시
성능, 접근성 및 신뢰성도 스토리가 될 수 있습니다. 문제를 체감하는 사용자를 명시하고 기준을 측정 가능하게 만드세요:
- 모바일 쇼핑객으로서, 저는 중간급 스마트폰에서 제품 페이지가 빠르게 로드되기를 원합니다. 그래야 페이지가 나타나기 전에 포기하지 않을 수 있습니다. 기준: 지정된 테스트 기기에서 4G 환경으로 2.5초 이내에 주요 콘텐츠가 표시되고, 접힌 부분 아래 이미지는 지연 로드됩니다.
- 스크린 리더 사용자로서, 저는 모든 가입 필드가 라벨링되고 안내되기를 원합니다. 그래야 혼자서 계정을 만들 수 있습니다. 기준: 양식이 WCAG 2.2 AA 레벨을 충족하고, 키보드만으로 완료할 수 있으며, 오류가 안내됩니다.
이 예시를 MVP에 맞게 조정하는 방법
- 역할을 실제 사용자로 교체하세요. “쇼핑객으로서”는 해당 대상이 학부모라면 “교복을 사는 학부모로서”가 됩니다.
- 모든 숫자를 자체 규칙으로 대체하세요. 위의 7일 초대, 24시간 마감, 3초 목표는 모두 플레이스홀더입니다.
- 첫 출시에는 핵심 여정상의 스토리만 유지하세요.
- 고객과 지원 팀이 이미 언급하는 부정적 경로(실패 시나리오)를 추가하세요.
- 각 스토리를 이를 구축할 사람들과 함께 정교하게 다듬으세요. 복사한 스토리도 여전히 대화를 필요로 합니다.
기술적 공동 창업자 없이 첫 버전의 범위를 결정하고 있다면, 비기술적 창업자가 MVP를 구축하는 방법 옵션을 다룹니다. 모든 필드가 있는 빈 카드가 있다면, 사용자 스토리 템플릿.
스토리로 구성된 백로그가 있지만 이를 구축할 사람이 없나요? 저희 팀은 스프린트 단위로 사용자 스토리를 작동하는 소프트웨어로 전환합니다. 월간 개발 플랜.
자주 묻는 질문
좋은 사용자 스토리 예시는 무엇인가요?
“재구매 고객으로서, 저는 이전 구매를 한 번의 탭으로 재주문하기를 원합니다. 그래야 다시 검색하지 않고 재고 보충을 할 수 있습니다.” 이는 구체적인 사용자, 설계 결정이 없는 목표, 그리고 실제 이점을 명시합니다. 다음과 같은 기준을 추가하세요: 더 이상 판매되지 않는 항목은 결제 전에 표시되고, 원래 가격이 아닌 현재 가격이 사용됩니다.
에픽의 예시는 무엇인가요?
“고객이 구독하고 결제할 수 있다”는 에픽입니다: 하나의 스프린트로는 너무 큰 결과물입니다. 무료 체험 시작, 체험 종료 전 카드 추가, 청구서 다운로드, 결제 실패 처리와 같은 스토리로 분해됩니다.
기술적 사용자 스토리는 어떻게 작성하나요?
이점을 체감하는 사람을 명시하세요(동료일 경우 “온콜 엔지니어로서…”), so-that 절에 가치를 서술하고, 측정 가능한 기준을 제공하세요. 사용자 가시적 가치가 전혀 없다면, 그것은 다른 스토리 하위의 태스크일 가능성이 높습니다.
사용자 스토리에는 몇 개의 수용 기준이 있어야 하나요?
보통 3개에서 6개입니다. 그보다 적으면 unhappy paths(비정상 경로)가 누락되었을 가능성이 높고, 그보다 많으면 스토리가 너무 커서 분할해야 할 것입니다.