예제 및 템플릿을 포함한 사용자 스토리

요약: 사용자 스토리는 최종 사용자의 관점에서 작성한 소프트웨어 기능에 대한 일반적인 비공식 설명입니다. 목적은 소프트웨어 기능이 고객에게 가치를 제공하는 방법을 명확히 설명하는 것입니다.

사용자 스토리가 간단히 말해 소프트웨어 시스템 요구 사항이라고 생각하기 쉽지만 그렇지 않습니다.

애자일 소프트웨어 개발의 핵심 컴포넌트는 사용자를 우선시하는 것이며 사용자 스토리는 최종 사용자를 대화의 중심에 둡니다. 이 스토리는 기술적이지 않은 언어를 사용하여 개발 팀과 팀의 노력에 대한 컨텍스트를 제공합니다. 사용자 스토리를 읽은 후 팀은 무엇을 왜 구축하고 있는지, 어떤 가치를 창출하는지 알 수 있습니다.

사용자 스토리는 애자일 프로그램의 핵심 컴포넌트입니다. 일상적인 작업에 대한 사용자 중심 프레임워크를 제공하여 공동 작업, 창의성 및 전반적으로 더 나은 제품을 이끌어냅니다.

사용자 스토리는 애자일 프레임워크에서 가장 작은 작업 단위입니다. 소프트웨어 사용자의 관점에서 표현한 최종 목표이며 기능이 아닙니다.

사용자 스토리는 최종 사용자 또는 고객의 관점에서 작성한 소프트웨어 기능에 대한 일반적인 비공식 설명입니다.

사용자 스토리의 목적은 어떤 작업이 고객에게 특정 가치를 제공하는 방법을 명확히 설명하는 것입니다. "고객"은 전통적인 의미에서 외부 최종 사용자일 필요는 없으며 조직 내에서 팀에 의존하는 동료 또는 내부 고객일 수도 있습니다.

사용자 스토리는 간단한 언어로 된 몇 문장을 통해 원하는 결과를 간략하게 설명합니다. 자세한 내용은 다루지 않습니다. 팀에서 합의하면 나중에 요구 사항이 추가됩니다.

스토리는 스크럼 및 칸반과 같은 애자일 프레임워크와 잘 어울립니다. 스크럼에서는 사용자 스토리가 스프린트에 추가되고 스프린트 기간 동안 “번다운"됩니다. 칸반 팀은 사용자 스토리를 백로그로 가져와서 워크플로를 통해 실행합니다. 사용자 스토리에 대한 이 작업은 스크럼 팀이 추정 및 스프린트 계획을 더 잘 수행할 수 있도록 도와주고, 예측의 정확도와 민첩성을 한층 더 향상할 수 있습니다. 스토리 덕분에 칸반 팀은 진행 중인 작업(WIP)을 관리하는 방법을 배우고 워크플로를 개선할 수 있습니다.

사용자 스토리는 에픽 및 이니셔티브와 같은 대규모 애자일 프레임워크의 구성 요소이기도 합니다. 에픽은 스토리의 집합으로 세분화된 대규모 작업 항목이며 여러 에픽이 이니셔티브를 구성합니다. 더 큰 구조는 개발 팀의 일상적인 작업(스토리)이 에픽 및 이니셔티브에 내장된 조직 목표에 기여하도록 보장합니다.

에픽 및 이니셔티브에 대해 자세히 알아보기

애자일을 처음 사용하는 개발 팀의 경우 사용자 스토리가 추가 단계처럼 보일 수 있습니다. 큰 프로젝트(에픽)를 일련의 단계로 나눈 다음 진행해 보세요. 스토리는 팀에 중요한 컨텍스트를 제공하고 작업을 해당 작업이 제공하는 가치와 연관시킵니다.

사용자 스토리의 여러 가지 주요 이점은 다음과 같습니다.

• 스토리는 사용자에게 초점을 맞춥니다. 해야 할 일 목록을 사용하면 팀은 완료 표시해야 하는 작업에 집중할 수 있지만, 스토리 컬렉션을 사용하면 팀은 실제 사용자의 문제 해결에 집중할 수 있습니다.
  
• 스토리는 공동 작업을 가능하게 합니다. 최종 목표가 정의되면 팀은 협력하여 사용자에게 가장 적합한 서비스를 제공하고 목표 달성 방법을 정할 수 있습니다.
  
• 스토리는 창의적인 솔루션을 촉진합니다. 스토리는 팀이 최종 목표를 가장 잘 해결하는 방법에 대해 비판적이고 창의적으로 생각하도록 유도합니다.
  
• 스토리는 추진력을 만듭니다. 각 스토리를 완료할 때마다 개발 팀은 작은 도전과 작은 승리를 누리고 추진력을 이끌어냅니다.

Jira에서의 사용자 스토리 작동 방식 보기

스토리를 작성했으면 워크플로에 통합해야 합니다. 일반적으로 스토리는 제품 소유자, 제품 관리자 또는 프로그램 관리자가 작성하여 검토할 수 있도록 제출합니다.

스프린트 또는 반복 계획 회의에서 팀은 스프린트를 다룰 스토리를 결정합니다. 이제 팀은 각 사용자 스토리에 필요한 요구 사항과 기능에 대해 논의합니다. 팀의 스토리를 기술적이고 창의적으로 구현할 기회입니다. 합의가 완료되면 이 요구 사항이 스토리에 추가됩니다.

이 회의의 또 다른 일반적인 단계는 복잡성 또는 완료 시간을 기준으로 스토리에 점수를 매기는 것입니다. 팀은 티셔츠 사이즈, 피보나치 수열 또는 계획 구상 기술을 사용하여 적절하게 추정합니다. 스토리는 한 스프린트에서 완료할 수 있도록 크기를 조정해야 합니다. 따라서 팀이 각 스토리를 추측할 때 완료 범위를 넘어가는 스토리를 분할해야 합니다.

사용자 스토리를 작성할 때 다음을 고려합니다.

• "완료"의 정의 — 스토리는 일반적으로 사용자가 요약된 작업을 완료할 수 있을 때 "완료"이지만 그 내용을 정의해야 합니다.
  
• 하위 작업 또는 작업 개요 — 완료해야 할 특정 단계와 각 단계의 담당자를 정합니다.
  
• 사용자 페르소나 — 대상이 누구입니까? 최종 사용자가 여러 명인 경우 스토리도 여러 개 만드는 것을 고려합니다.
  
• 순서가 지정된 단계 — 더 큰 프로세스에서 각 단계의 스토리를 작성합니다.
  
• 피드백 듣기 — 사용자와 소통하고 그들이 말하는 대로 문제 또는 요구 사항을 포착합니다. 스토리를 고객으로부터 얻을 수 있는 경우에는 스토리를 추측할 필요가 없습니다.
  
• 시간 — 시간은 민감한 주제입니다. 많은 개발 팀이 추정 프레임워크에 의존하는 대신 시간 관련 논의 자체를 아예 피합니다. 스토리는 한 스프린트에서 완료할 수 있어야 하므로, 완료하는 데 몇 주 또는 몇 달이 걸릴 수 있는 스토리는 더 작은 스토리로 나누거나 자체 에픽으로 간주해야 합니다.
  

사용자 스토리가 명확히 정의되면 팀 전체가 볼 수 있는지 확인합니다.

사용자 스토리는 다음과 같이 간단한 문장으로 표현되는 경우가 많습니다.

"저는 [페르소]로서, [하고 싶은 일]을 하여 [목적]을 이루고 싶습니다.”

자세히 살펴보면 다음과 같습니다.

• "[페르소나]로서": 누구를 위해 이것을 만듭니까? 단지 직책을 의미하는 것이 아니라 한 사람의 페르소나 예를 들어 Max를 추구합니다. 팀은 Max가 누구인지 공동으로 이해해야 합니다. 팀은 여러 Max와 인터뷰한 상태여야 합니다. 팀은 해당 사용자가 어떻게 일하고 생각하며, 무엇을 느끼는지 이해합니다. Max에 대한 공감대가 있습니다.
• "하고 싶은 일": 여기서는 사용자가 사용하는 기능이 아니라 의도를 설명합니다. 사용자가 실제로 달성하려는 목표는 무엇입니까? 이 문장은 구현과 관련이 없어야 합니다. 사용자 목표가 아닌 UI의 일부를 설명하고 있다면 논점을 놓쳤다는 의미입니다.
• “목적”: 특정 작업을 하려는 사용자의 즉각적인 바램이 그들의 더 큰 그림에 어떻게 잘 맞습니까? 사용자가 달성하고자 하는 전반적인 이점은 무엇입니까? 해결해야 할 가장 큰 문제는 무엇입니까?

예를 들어 사용자 스토리는 다음과 같습니다.

• 저는 Max로서, 친구들을 초대하여 이 서비스를 함께 즐기고 싶습니다.
• 저는 Sascha로서, 내 작업을 체계화하여 더 많은 통제력을 느끼고 싶습니다.
• 저는 매니저로서, 동료의 진행 상황을 이해하여 우리의 성공과 실패를 더 잘 보고하고 싶습니다.

이 구조가 필수는 아니지만 완료를 정의하는 데 유용합니다. 페르소나가 원하는 가치를 포착한다면 스토리가 완성됩니다. Atlassian은 팀이 자체 구조를 정의한 다음 구조를 지키는 것을 권장합니다.

사용자 스토리는 주로 페로소나 + 필요 + 목적으로 표현되는 개발 팀원의 일상적인 작업을 둘러싼 이유와 내용을 설명합니다. 스토리의 역할을 팀이 제공하는 작업의 정보 소스이자 이유로 이해하는 것이 원활한 프로세스의 핵심입니다.

다음 또는 가장 시급한 대규모 프로젝트(예: 에픽)를 평가하는 것으로 시작합니다. 사용자 스토리를 더 작게 나누고 개발 팀과 협력하여 개선합니다. 팀 전체가 볼 수 있는 스토리가 나오면 작업을 시작할 수 있습니다.