스토리와 기능을 반복적으로 제공할 수 있는 작은 가치 단위로 나눠서 사용자 중심의 민첩한 백로그를 만듭니다.
단계
제안 시간
다양: 1분~1시간 이상
참가자
디자이너 및 개발자의 의견을 수렴하는 제품 관리자
수행 이유
사용자 사례는 균형 잡힌 팀에 대해 중요하면서도 범용적인 형태를 가집니다. 사용자 사례를 통해 큰 아이디어를 개별적으로 제공할 수 있는 가치로 변환한 다음, 구현을 위해 백로그에서 우선순위를 지정합니다. 사용자 사례를 올바르게 파악하는 것은 건전한 프로세스와 효과적인 팀 역학 관계를 수립하는 데 매우 중요합니다.
수행 시기
사용자 사례는 제품 개발 수명주기 전반에 걸쳐 작성됩니다. 다양한 준비 상태의 사용자 사례를 보유하는 것은 백로그를 통해 가치의 건전한 흐름을 유지하는 데 중요합니다.
필요한 물품
백로그 관리 툴(예: Pivotal Tracker)
이 방식을 활용하는 방법
세 가지 기본 프로젝트 단계에 대해 스토리를 준비해야 합니다.
- 사용자 스토리를 다듬고 다음 반복 계획 회의 준비(1~2주)
- 고품질 설계를 위해 사용자 스토리를 준비하지만 일부 세부 사항을 완료하지 않음(2~4주)
- 제품이 나아갈 방향을 암시하고 리서치 작업에 정보를 제공하기 위해 사용자 스토리를 개괄적으로 구상(1~3개월)
샘플 안건 및 메시지
아이디어, 기능 또는 사용자 스토리로 세분화할 사용자 흐름을 검토하여 시작합니다. 팀과 함께 스토리 매핑 연습을 수행하거나 가벼운 아이디어 세션을 수행하여 기능이나 사용자 흐름을 생성할 수 있습니다.
제목을 작성합니다. 짧고 설명 형식의 제목을 작성합니다. 실행 가능한 제목은 전체 팀이 백로그를 이해하기 쉽습니다.
제목 예시: 영업 담당자가 영업 제안서를 PDF로 다운로드 가능
설명을 작성합니다. “[역할]로서 ...할 수 있도록 ...하기를 원합니다” 형식을 사용하여 이 사례가 사용자 관점에서 제공할 가치를 설명합니다.
설명 예시:
Alex는 영업 담당자로서
잠재 고객에게 e-메일을 보낼 수 있도록
영업 제안서의 PDF 버전을 다운로드하기를 원함
설명을 통해 팀은 누구를 위해 사용자 스토리를 작성하며, 해당 사용자가 소프트웨어에서 이 기능을 원하는 이유, 해당 사용자가 완수하는 데 도움이 되는 사항을 이해할 수 있습니다. 설명에서 이름을 사용하는 경우 이름은 “영업 담당자 Alex”처럼 팀에서 만든 역할을 나타내야 합니다. 또한 임의의 이름일 수 없으며 해당 역할이 의도된 사용자인 모든 스토리에서 일관되어야 합니다.
팁: 애플리케이션 외부에서 발생하는 일에 대해 스토리에서 “...할 수 있도록” 부분을 사용해 보십시오. 이를 통해 가치를 이해하고 있다고 사용자에게 확신을 줄 수 있습니다. “...할 수 있도록” 부분을 작성하는 데 문제가 있는 경우 스토리가 정말 유용한지 자문합니다.
팁: 사용자가 반드시 사람일 필요는 없습니다. 시스템의 작업자와 소비자가 다른 시스템, 소프트웨어 또는 기기인 경우도 있습니다. 이는 이벤트 기반 또는 사물 인터넷 시스템에서 흔한 일입니다. 이러한 시스템의 스토리 작성 방법에 대해서는 이벤트 기반 시스템의 사용자 스토리 작성에 대한 Tanzu 가이드를 참조하십시오.
검증 기준을 작성합니다. 엔지니어가 개발 중 자동화 테스트를 작성하는 데 사용할 시나리오이며, 제품 관리자가 스토리가 제공될 때 검증 테스트에 사용할 시나리오입니다. 검증 기준은 사용자의 관점에서 “수행한” 작업이 어떻게 보이는지 설명합니다. 검증 기준을 통해 팀은 수행해야 할 작업을 이해하고, 방해 요소와 종속성을 파악하고, 복잡도를 파악 및 추정하고, 작업을 테스트하고, 검증 방법을 이해하고, 테스트 기반 개발 방식에 대해 생각할 수 있습니다.
검증 기준 예시:
제안서 요약 페이지 방문한다면
“PDF 다운로드” 버튼 클릭하면
그런 다음 영업 제안서 PDF 파일이 내 컴퓨터에 다운로드됨
필요한 경우 지원 문서와 메모를 추가합니다. 필요한 경우 추가 정보를 포함하여 사용자 스토리를 명확하게 만듭니다. 설계 모형을 포함하는 경우가 가장 많지만, 스토리에 관한 일반적인 메모, 통합과 관련된 문서 등을 포함할 수도 있습니다.
경우에 따라 스토리에 포함되지 않는 사항에 관한 메모를 추가하면 유용합니다. 범위를 벗어나는 사항을 모두 작성하지 마십시오. 스토리에 포함될 수도 있지만 포함되지 않은 한두 가지 덕분에 스토리가 더 명확해질 수도 있습니다.
다음은 전체 예시입니다.
스토리 제목: 영업 담당자가 영업 제안서를 PDF로 다운로드 가능
설명:
Alex는 영업 담당자로서
잠재 고객에게 e-메일을 보낼 수 있도록
영업 제안서의 PDF 버전을 다운로드하기를 원함
검증 기준:
제안서 요약 페이지 방문한다면
“PDF 다운로드” 버튼 클릭하면
그런 다음 영업 제안서 PDF 파일이 내 컴퓨터에 다운로드됨
참고 자료:
- 다른 제품 중 하나에서 이 기능에 대한 예시:
<예시 링크> - 개발자 메모: 다른 팀이 사용하는 PDF 변환 라이브러리:
<리소스 링크>
팁: 명료성과 고품질 구현을 위해 사용자 인터페이스 구성 요소가 있는 대부분의 사용자 스토리는 디자이너의 모형 또는 문서를 포함해야 합니다. 와이어프레임부터 고품질 모형, 클릭 가능한 프로토타입 또는 설계 시스템의 구성 요소에 대한 참조까지 무엇이든 가능합니다.
- 다른 제품 중 하나에서 이 기능에 대한 예시:
성공/예상되는 성과
다음과 같은 경우에는 훌륭한 사용자 스토리를 작성한 것입니다.
- 전체 팀이 스토리를 읽고 스토리가 사용자에게 제공하는 가치가 무엇인지 이해할 수 있습니다.
- IPM의 스토리에 관한 토론이 원활하고 세부 사항을 명확하게 설명하며 전반적인 방식이 무엇인지 의문을 갖지 않습니다. 이와 관련하여 문제가 있다면 원활하게 스토리를 다듬을 수 있도록 IPM 사전 계획을 고려하십시오.
- 엔지니어가 개발을 완료하면 스토리를 구분할 수 있습니다.
- 스토리가 제공되면 쉽게 받아들일 수 있습니다.
- 팀이 매주 여러 사용자 스토리를 제공합니다.
- 백로그에 있는 대부분의 스토리를 독립적으로 그리고 다른 스토리와 함께 완료할 수 있습니다.
- 스토리가 구현 세부 사항을 자세히 이야기하지는 않지만 대신 무엇이 빌드되는지(빌드 방법이 아님)를 설명합니다.
진행자 메모 및 팁
INVEST는 좋은 사용자 스토리의 품질을 기억하기 위한 연상 기호입니다.
독립형 – 제공되는 다른 스토리와 종속성이 없습니다. 제공되는 모든 스토리는 스토리를 제공하기 위해 다른 스토리와 종속성이 없어야 합니다. 한 쌍의 개발자는 백로그의 맨 위에서 스토리 하나를 골라서 백로그의 다른 스토리를 건드리거나 코드에 다른 개발자의 코드를 넣지 않으면서 스토리가 설명하는 가치를 전달하기 위해 필요한 모든 사항을 수행해야 합니다. 자신의 백로그 내에서 종속성을 방지하는 데 문제가 있는 경우 스토리를 보다 독립적으로 만들기 위해 다시 분할하는 방법을 생각하십시오.
협의 가능성 – 기능에 대한 특정 약정이 없습니다. 스토리는 제공될 사항에 관한 엔지니어와 PM 간(또는 제품 팀과 이해관계자 간)의 계약된 합의 사항이 아니라, 제공할 가치를 함께 이해하는 가벼운 문서입니다. 스토리는 개발이 시작될 때까지 필요한 때마다 사용자와 이해관계자의 새 정보 또는 팀의 입력을 기반으로 업데이트되어야 합니다. 개발이 시작되면 스토리를 작업하는 사람들이 변경 사항을 인지하고 이해하지 않는 한, 스토리를 변경하지 마십시오. 그런 경우라도 범위 증가와 새로운 검증 기준 및 구현을 기준으로 재평가의 필요성에 주의하십시오.
가치 제공성 – 사용자에게 기술의 가로 조각(horizontal slice)이 아니라, 진정한 가치를 제공합니다. 전달된 각 스토리는 진정한 가치를 제공해야 합니다. 스토리는 가로 조각(예: 프론트엔드, 백엔드)으로 분할되어서는 안 됩니다. 전체 스택 스토리는 애플리케이션이 항상 배포 가능한(그리고 잠재적으로 릴리스 가능한) 상태임을 보장하고, 팀이 코드 제공이 아니라 작업의 결과에 집중할 수 있도록 합니다.
추정 가능성 – 적절한 근사치를 추정할 수 있습니다. 팀의 개발자는 스토리의 범위를 충분히 이해하여 관련된 노력이나 복잡도를 추정할 수 있어야 합니다. 추정하기 위해 지나치게 자세히 설명하지 않도록 하십시오. 구현 세부 내용은 스토리로 작성되지 않고 개발자에게 남겨두어야 합니다.
간소 – 반복에 적합하도록 가능한 한 작게 만듭니다. 스토리는 가치를 제공하면서 최대한 짧아야 합니다. 이상적으로 각 반복에서 여러 스토리를 제공할 것입니다. 그 결과 피드백 주기가 짧아져서 팀이 더 빠르게 배우고 필요한 경우 궤도를 수정할 수 있습니다. 또한 짧은 스토리는 테스트 또는 스테이징 환경에 지속적인 제공을 지원합니다.
팁: 여러 블록의 검증 기준이 있고(특히 많은 “그리고”), 개발자로부터 복잡성이 높다고 평가받거나(피보나치 점수 8), 반복 계획 회의 동안 의견이 갈리는 대화가 계속되면 스토리가 너무 방대하다는 신호입니다. 긴밀한 피드백 고리와 명확한 테스트 시나리오를 보장하기 위해 너무 방대한 스토리는 짧고 독립적인 스토리로 나누어야 합니다.
테스트 가능성 – 아직 테스트가 작성되지 않았더라도 원칙적으로 평가해야 합니다. 이는 스트를 이미 작성했음을 의미하지는 않지만, 스토리를 제공한 후에는 스토리를 테스트할 방법이 있어야 합니다.
관련 사례
이전 단계
다음 단계
실제 예시
권장 자료
Tanzu 가이드: 이벤트 기반 시스템에 대한 사용자 스토리 작성
Tanzu 학습 과정 - 최신 애플리케이션 개발 사례 기초: 영향력 있는 결과의 우선순위 지정: 사용자 스토리, 평가, 속도
