사용자 스토리 편집하기

사용자 스토리(User Story)는 애자일 개발, 특히 스크럼 및 칸반 프레임워크에서 사용자 또는 고객(내부 또는 외부)의 관점에서 기능적 요구사항을 간단하고 명확하게 표현한 서술 방식이다.
==정의 및 개념==
사용자 스토리는 최종 사용자의 관점에서 “누구(Who)”, “무엇(What)”, “왜(Why)” 등의 요소를 포함하여 가치를 전달하는 기능이 무엇인지 설명한다.  이 방식은 기술적 세부사항보다는 맥락(Context)과 목적(Purpose)에 초점을 맞추며, 나중에 팀 대화(Conversation)를 통해 세부 요구사항을 정리한다.
==특징==
*사용자 중심(User‑centric) 표현 방식으로, 기능이 사용자 또는 고객에게 어떠한 가치를 제공하는지를 강조함.
*간결성(Conciseness) 유지: 가능한 한 짧고 이해하기 쉬운 언어로 작성됨.
*유연성(Flexibility): 초기에는 상세하지 않더라도, 개발 과정에서 필요에 따라 세부사항이 추가됨.
*백로그(Product Backlog)의 기본 단위: 에픽(Epic)보다 작은 단위이며, 하나의 스프린트에서 완료 가능하도록 조정됨.
==작성 기준 및 베스트 프랙티스==
사용자 스토리를 잘 작성하기 위해 흔히 사용되는 기준과 관행은 다음과 같다:
*역할(Role), 기능(Feature/Action), 목적(Reason) 세 부분을 포함하는 템플릿: 
**''[사용자 유형]으로서''', '''[~하고 싶다]''', '''그래서 ~할 수 있게'' 와 같은 형식.
*INVEST 원칙 사용: Independent (독립적), Negotiable (협의 가능), Valuable (가치 있음), Estimable (추정 가능), Small (작은 단위), Testable (테스트 가능) 등.
*수용 기준(Acceptance Criteria) 정의: 완료 여부를 판단할 수 있는 조건들을 명확히 설정함.
==장점 및 이점==
*사용자 가치 중심의 개발이 가능해짐: 사용자의 필요를 명확히 하여 올바른 기능에 우선순위 집중.
*팀 내 이해 공유 및 커뮤니케이션 원활화: 기능의 목적이 분명하므로 개발자, PO, 이해관계자 간 협업이 쉬움.
*예측 가능성 향상: 스토리가 작고 잘 정의된 경우 추정과 계획이 더 정확해짐.
*변화에 대한 적응력 확보: 요구사항 변화 시 스토리 단위의 수정이나 재배치가 가능함.
==유의사항 및 한계==
*너무 큰 스토리는 한 스프린트 내에 완료되지 않을 수 있으므로 분할이 필요함.
*기술적 세부사항 과다 포함 시 이해관계자에게 혼란 줄 수 있음.
*테스트 가능성과 수용 기준이 불명확하면 스토리 완료 여부 판단이 모호해짐.
*동일 팀 간에는 유용하나 팀 간 비교 지표로는 부적절함.
==같이 보기==
*[[스토리 포인트|스토리 포인트 (Story Point)]]
*[[벨로시티 (스크럼)|벨로시티 (Velocity)]]
*[[제품 백로그|제품 백로그 (Product Backlog)]]
*[[에픽 (스크럼)|에픽 (Epic)]]
*[[INVEST 원칙]]
==참고 문헌==
*[https://www.atlassian.com/ko/agile/project-management/user-stories Atlassian 공식 문서 – 사용자 스토리의 정의 및 활용]
*[https://jeonyoungho.github.io/posts/Chapter5-%EC%9A%94%EA%B5%AC-%EC%82%AC%ED%95%AD%EA%B3%BC-%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%8A%A4%ED%86%A0%EB%A6%AC/ 에센셜 스크럼 – 요구 사항과 사용자 스토리]
==각주==
<references />
[[분류:소프트웨어 공학]]