인터뷰로 사용자 스토리 쓰기: 템플릿과 인수 기준

사용자 스토리는 사용자가 얻는 가치를 설명합니다

사용자 스토리는 제품을 쓸 사람의 관점에서 원하는 결과를 짧게 설명합니다. 흔히 ‘[역할]로서 [이점]을 얻기 위해 [행동]을 하고 싶다’라는 형식을 사용합니다. 이 형식은 필요를 논의하는 출발점입니다. 요구 사항과 결과의 검증 방법은 따로 정해야 합니다.

인터뷰 중 ‘초록색 버튼을 추가해 주세요’라는 말은 해결책 제안입니다. 스토리를 쓰려면 그 사람이 무엇을 하려는지, 현재 방식에서 무엇이 방해되는지 알아야 합니다. 해석을 확인할 수 있도록 원래 발언을 보관하세요.

인터뷰를 바탕으로 스토리를 쓰는 방법

1. 구체적인 사례를 고르세요

   최근에 실제로 겪은 사례를 찾으세요. 누가 어떤 자료로 무엇을 했고, 어떤 결과를 원했나요? ‘모두에게 보고서가 필요하다’는 말만으로는 별도의 스토리를 작성하기 어렵습니다.

2. 정확한 발언과 맥락을 기록하세요

   타임코드와 앞뒤 문장을 보관하세요. 인터뷰 대상자의 말과 자신의 결론을 구분하세요. 예외적인 상황을 일상 업무로 바꾸어 설명하지 마세요.

3. 역할, 행동, 이점을 정리하세요

   역할은 ‘사용자’라는 일반적인 표현을 넘어 상황을 설명해야 합니다. 행동은 관찰할 수 있어야 하며, 이점에는 그 사람에게 행동이 필요한 이유가 드러나야 합니다.

4. 범위를 확인하세요

   따로 논의하고 확인할 수 있는 완결된 유용한 결과 하나를 고르세요. 가입부터 연간 보고서 작성까지의 전 과정을 한 스토리에 담지 마세요.

5. 인수 기준을 추가하세요

   원하는 동작이 구현되었는지 확인할 조건을 적으세요. 주요 사례와 중요한 예외를 포함하세요. 한 사람의 발언을 고객 요구 사항으로 확정하기 전에 팀과 기준을 합의하세요.

6. 미해결 질문을 다시 논의하세요

   접근 권한이나 데이터 양, 결과 형식이 확실하지 않으면 질문으로 남기세요. 가장 익숙한 구현 방식으로 빈칸을 채우지 마세요.

조정 담당자의 발언을 스토리 카드로 정리하기

가상의 메모 관리 시스템을 예로 든 것으로, Transkribator의 실제 기능을 설명하지 않습니다. 필요한 것은 선택한 부분만 불필요한 정보 없이 보내는 일입니다. 버튼을 만든다면 색상은 설계 과정에서 정할 수 있습니다.

출처는 있지만 이 일이 대다수 고객에게 중요한지는 확인이 필요합니다. 녹음 한 건은 한 사람의 경험을 보여 줍니다. 다른 증거, 제품 목표, 구현 비용을 함께 살펴 개발 우선순위를 별도로 정하세요.

스토리와 기술 작업 목록을 구분하는 방법

‘데이터베이스에 테이블 만들기’와 ‘이벤트 핸들러 추가하기’는 기술 작업입니다. 스토리 구현에 필요할 수 있지만 사용자가 얻는 이점을 설명하지는 않습니다. 또한 템플릿을 잘 채운 문장만으로 팀이 모든 제약을 이해했다고 볼 수는 없습니다.

인터페이스 요소의 이름을 쓰지 않고 테스트 담당자에게 스토리를 설명해 보세요. 변경 전후에 사람이 무엇을 하는지 설명하기 어렵다면 인터뷰로 돌아가세요. 데이터 미선택, 권한 부족, 재시도 같은 예외도 확인하세요. 해당 스토리에 중요한 예외만 골라 카드가 제품 전체의 명세서로 커지지 않게 하세요.

출처와 미해결 질문이 있는 카드

스토리 제목:
역할과 업무 상황:
[누구]로서 [이유] 때문에 [행동]을 하고 싶다.

출처: 인터뷰 / 날짜 / 타임코드:
원래 발언:
팀의 해석:

인수 기준:
1. [조건]에서 [행동]을 할 수 있고 [결과]를 얻는다.
2. [중요한 예외]가 생기면 [예상 동작]이 일어난다.

스토리 범위에 포함되지 않는 내용:
추가 확인 사항:
누가 언제 표현을 확인했는가:

• 역할이 구체적이고 이점이 분명하다.
• 원래 발언과 팀의 해결책이 구분되어 있다.
• 기준을 관찰로 검증할 수 있다.
• 질문은 질문으로 명시되어 있다.