사용자 스토리
IT 위키
사용자 스토리(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, 이해관계자 간 협업이 쉬움.
- 예측 가능성 향상: 스토리가 작고 잘 정의된 경우 추정과 계획이 더 정확해짐.
- 변화에 대한 적응력 확보: 요구사항 변화 시 스토리 단위의 수정이나 재배치가 가능함.
유의사항 및 한계[편집 | 원본 편집]
- 너무 큰 스토리는 한 스프린트 내에 완료되지 않을 수 있으므로 분할이 필요함.
- 기술적 세부사항 과다 포함 시 이해관계자에게 혼란 줄 수 있음.
- 테스트 가능성과 수용 기준이 불명확하면 스토리 완료 여부 판단이 모호해짐.
- 동일 팀 간에는 유용하나 팀 간 비교 지표로는 부적절함.
