Jira에서 사용자 스토리를 작성하는 방법

웹 애플리케이션 및 소프트웨어 개발의 핵심 요소: 사용자 스토리

웹 애플리케이션이나 소프트웨어를 제작하는 과정은 단순한 코딩 작업을 넘어섭니다. 요구 사항 분석, 설계, 테스트, 개선 및 최종 배포와 같이 다양한 단계를 거칩니다. 때로는 복잡한 개발 과정과 아이디어를 시각화하는 것이 이해에 도움이 됩니다. 사용자 스토리는 이러한 복잡성을 해소하고 개발 우선순위를 정하는 데 필수적인 도구입니다.

사용자 스토리는 소프트웨어 개발 여정에서 핵심적인 역할을 하며, 개발해야 할 기능과 우선순위를 시각적으로 제시합니다. 특히 Jira와 같은 플랫폼에서 사용자 스토리를 효과적으로 작성하는 방법을 이해하는 것은 매우 중요합니다. 이 글에서는 사용자 스토리의 개념과 Jira에서 이를 생성하는 방법을 상세히 살펴보겠습니다.

사용자 스토리란 무엇인가?

사용자 스토리는 웹 앱이나 소프트웨어 기능에 대한 최종 사용자의 관점에서 작성된 간결한 설명입니다. 이는 단순히 소프트웨어 요구 사항을 나열하는 것이 아니라, 해당 기능이 최종 사용자에게 어떤 가치를 제공하는지를 비공식적인 방식으로 설명합니다. 사용자 스토리는 기능이 실제로 사용자에게 어떻게 도움이 되는지를 명확히 함으로써 개발 과정에 중요한 방향성을 제시합니다.

사용자 스토리의 기본 구조

사용자 스토리는 프로젝트 작업 단계를 결정하는 ‘할 일 목록’과 같습니다. 핵심적으로 ‘누가’, ‘무엇을’, ‘왜’를 명확히 해야 합니다. 각 요소는 10-15단어 내외로 간결하게 구성되어야 합니다. 이러한 구조는 제품과 프로세스가 사용자 요구 사항을 충족하는지 확인하는 데 중요한 역할을 합니다.

론 제프리스에 따르면, 모든 사용자 스토리에는 ‘카드, 대화, 확인’이라는 세 가지 요소(3C)가 필요합니다. Jira에서 사용자 스토리를 작성할 때 이 3C 요소를 어떻게 적용해야 하는지 자세히 알아보겠습니다.

카드

초기의 사용자 스토리는 물리적인 카드나 포스트잇에 기록되었습니다. Jira에서는 사용자 정의가 가능한 디지털 카드를 사용합니다. 이 카드에는 기능에 대한 핵심 정보만 간략하게 기록되며, 요구 사항을 이해하는 데 필요한 충분한 정보를 제공합니다. 또한 우선 순위나 비용과 같은 중요한 세부 정보도 카드에 포함될 수 있습니다. 제품 담당자나 프로젝트 관리자는 모든 세부 정보가 기록되면 개발자에게 스토리를 전달합니다.

대화

카드에 사용자 스토리를 구성한 후에는 관련 당사자 간의 대화가 중요합니다. 개발자에게 요구 사항을 전달하기 전에 사용자 스토리에 대해 논의하고 개선하는 과정이 필요합니다. 이러한 대화는 제품 소유자, 스크럼 마스터, 개발자 및 이해 관계자 간의 협력을 촉진합니다. 이들은 계획 단계에서 실행을 위한 스토리 선택까지 의견을 공유합니다. 이러한 대화는 구두로 진행될 수 있으며, 필요한 경우 문서로 보충될 수 있습니다.

확인

대화는 여러 날 또는 몇 주 동안 지속될 수 있습니다. 그러나 때로는 명확하지 않은 요소가 있을 수 있으므로 검증 과정이 필요합니다. 특정 측정값을 기준으로 한 몇 가지 조건을 추가하여 허용 기준을 설정할 수 있습니다. 이러한 기준은 스토리 내에 목록 형태로 작성할 수 있습니다. 확인은 인수 테스트 형태로 제공되며, 필수 요구 사항을 파악하고 생성된 제품이 기준을 충족하는지 확인하는 데 도움이 됩니다. 제품 소유자는 인수 기준을 정의하고, 개발자는 이를 구현해야 합니다.

사용자 스토리 작성의 목적

사용자 스토리는 디자이너, 제품 담당자 및 개발자가 최종 사용자를 중심으로 생각하도록 돕습니다. 최종 사용자가 제품과 어떻게 상호 작용하는지 고려하는 것은 현대 제품 개발의 핵심입니다. 사용자 스토리는 사용자 중심 설계를 가능하게 하는 중요한 접근 방식입니다.
사용자 스토리는 단순하고 유연한 형식을 가지고 있습니다. Jira에서 사용자 스토리는 복잡할 필요 없이, 최소한의 단어로 필요한 모든 정보를 포착할 수 있습니다. 시스템/소프트웨어 애플리케이션이 성장함에 따라 요구 사항도 변경될 수 있으며, 사용자 스토리는 이러한 변화를 수용할 수 있도록 유연하게 설계되어야 합니다.
사용자 스토리는 팀 내에서 공통된 언어를 제공합니다. 개발 팀은 제품 담당자, 디자이너, 개발자 등 다양한 구성원으로 이루어져 있습니다. 사용자 스토리는 팀 구성원 모두가 요구 사항과 최종 목표를 명확히 이해하도록 돕는 중요한 도구입니다.
사용자 스토리는 협업을 촉진합니다. 최종 목표를 정의함으로써 팀원들이 협력하여 최종 사용자에게 최상의 서비스를 제공하고 목표를 달성하는 데 집중할 수 있도록 합니다.

사용자 스토리 작성 시 모범 사례

#1. 사용자를 명확히 정의해야 합니다.

사용자가 명확히 식별되어야 합니다. 기능을 요청하는 사용자는 외부 사용자, 클라이언트, 제품 관리자 또는 개발 팀의 구성원일 수 있습니다. 사용자는 다음 형식으로 표현됩니다.

“[사용자 이름]으로서…”

예를 들어, “임차인으로서…” 또는 “집주인으로서…”와 같이 표현할 수 있습니다.

#2. 사용자 스토리는 필요를 포착해야 합니다.

사용자가 제품에서 무엇을 원하는지 파악해야 합니다. 예를 들어, 친구들과 제품 사진을 공유하고 싶어하는지, 아니면 과거 구매 내역을 확인하고 싶어하는지 등을 질문을 통해 파악해야 합니다. 이는 제품 팀이 무엇을 만들어야 하는지 이해하는 데 도움이 됩니다.

주의해야 할 점은 사용자 스토리에 대한 해결책을 미리 제시해서는 안 된다는 것입니다. 제품 개발자는 사용자 스토리를 작성할 때 사용자와 협력하여 요구 사항을 파악해야 하며, 성급하게 결론을 내리지 않도록 해야 합니다. 필요성은 다음 형식으로 표현됩니다.

“[사용자 이름]으로서, [무엇을] 할 수 있기를 원합니다…”

예를 들어, “집주인으로서 월세 징수 내역을 볼 수 있기를 원합니다…”와 같이 표현할 수 있습니다.

#3. 적격 진술이 있어야 합니다.

“~하도록”과 같은 구문으로 적격 진술을 추가하여 기능이 제공하는 가치를 명확히 해야 합니다. 단순히 앱에 기능을 추가하는 것이 아니라, 해당 기능이 어떤 가치를 제공해야 하는지를 설명해야 합니다.

적격 진술은 다음 형식으로 제시할 수 있습니다.

“[사용자 이름]으로서, [무엇을] 할 수 있기를 원합니다, [가치] 하도록…”

예를 들어, “집주인으로서 월세 징수 내역을 볼 수 있어 지출 계획을 세울 수 있도록 원합니다.”와 같이 표현할 수 있습니다.

적격 진술은 제품 팀이 제안된 기능에 대해 작업해야 하는 이유를 명확히 제시합니다.

#4. 사용자 스토리는 독립적이어야 합니다.

생성된 모든 사용자 스토리는 독립적이고 고유한 비즈니스 가치를 나타내야 합니다. 개발자는 사용자 스토리를 구현할 때 점진적인 가치를 제공할 수 있어야 합니다.

#5. 사용자 스토리는 협상 가능해야 합니다.

사용자 스토리의 최종 목표는 명확해야 하지만, 목표 달성 과정은 협상 가능해야 합니다. 사용자 스토리는 제품 담당자와 개발 팀이 기능에 대한 비현실적인 제약을 피할 수 있도록 협상의 여지를 남겨야 합니다.

#6. 사용자 스토리는 단순하고 작아야 합니다.

주어진 스프린트 주기 내에 목표를 달성하려면 Jira의 사용자 스토리를 작게 만들어야 합니다. 스토리가 너무 복잡하면 스토리를 더 세분화해야 한다는 신호입니다.

Jira에서 사용자 스토리 생성 단계별 과정

Jira는 현대 프로젝트 관리 도구 중 하나로, 원래 버그 및 문제 추적을 위해 사용되었지만 이제는 개발 팀을 위한 애자일 소프트웨어 개발 도구로 발전했습니다. Jira의 강력한 기능과 다양한 앱과의 통합은 사용자 스토리를 작성하는 데 큰 도움이 됩니다. 다음은 첫 번째 사용자 스토리를 만드는 단계입니다.