목표: User Story가 무엇인지 이해한다.
이해의 기준:
- User Story가 무엇인지 설명할 수 있다.
- User Story를 작성할 수 있다.
방법:
- Business Analyst의 User Story에 관한 자료를 찾아본다.
아티클1: EY / Analysts who embrace user stories can improve results
User story 개념
A user story is the smallest unit of work in an agile framework. It's not a feature, but an end goal that the user has when using the software. The user story will convey what the user wants to achieve and states it simply, non-technically.
User story 만드는 법
1. 사용자 요구사항 검증하기
- 서비스 사용자 정의하기
2. Epic 만들기
- Epic = 서비스의 주요 구성요소
- 여러 User Story 하나의 Epic에 속한다
- Epic 예: 로그인
3. User Story 작성하기
- Epic은 언제든 추가되거나 삭제될 수 있다
- User Story Template: A사용자는 ~을 하기 위해, ~을 한다
As a <type of user/role>, I want <some goal> so that <some reason/benefit>
- User Story는 INVEST 하여야 한다.
-- Independent: 어떤 상황에서든 개발자는 User Story를 구현할 수 있어야 한다
-- Negotiable: 너무 자세해선 안된다. 제약이 되어선 안된다
-- Valuable: 사용자가 어떤 가치를 얻는지 알 수 있다
-- Estimatable: 소요될 프로젝트 일정을 가늠할 수 있어야 한다
-- Small: 작은 User Story가 더 좋다
-- Testable: 완료의 기준을 문서화할 수 있어야 한다
4. 허용 기준 정의하기
- 허용 기준이란 User Story의 세부 사항을 정의하고, 분명하고 기술적이지 않은 용어로 작성된다
- 개발자들의 이해를 돕는다
- 테스터에게 체크리스트로 활용될 수 있다
- 대게 BA가 먼저 작성하고 구현 단계 이후부턴 전체 팀이 함께 정의한다
- 허용 기준 작성에 있어 중요한 것은 구현 단계 전에 정의되어야 하고 모호함이 없어야 한다.
user story 예
| User Type | Epic | User Story |
| Mobile User | Registration | As a user, I can registar for the application, by entering my email, password, and confirming my password |
| Mobile User | Registration | As a user,... |
아티클2: Linkedin / User Stories for Business Analysts
User story 개념
User Stories are the building blocks of effective software development, particulary in Agile methodologies. They are concise, informal descriptions of features or functionality from the user's perspective, and they are structured to answer three essential questions: "Who", "What", and "Why".
User story 만드는 법
Who:
- 기능을 통해 이익을 얻는 자를 확인할 수 있다
- Template: "As a [type of user]..."
- e.g. "As a customer..."
What:
- 사용자가 원하는 행동이나 기능을 묘사한다
- Template: "I want [an action]..."
- e.g. "I want to be able to search for products..."
Why:
- 기능을 통해 얻는 가치나 이익을 설명한다
- Template: "so that [benefit/value]
- e.g. "so that I can quickly find the product I need."
Example:
As a hungry customer (who),
I want to be able to browse nearby restaurants (what)
so that I can quickly find a place to order my favorite meal (why).
INVEST
- Independent: 모든 User Story는 독립적이어야 하고 다른 User Story에 의존적이어선 안된다. 이를 통해 자유롭게 우선순위를 정의할 수 있으며 여러 User Story를 동시에 구현할 수 있다
- Negotiable: User Story는 협상 가능해야 한다. 이는 팀과 이해관계자 간 계약이 아닌 이야기의 시작점이어야 한다
- Valuable: 모든 User Story는 사용자나 비즈니스에게 제공하는 가치가 있어야 한다. 프로젝트 목표를 달성하는데 직접 기여해야 한다
- Estimable: 팀은 User Story를 작성하는 데 필요한 시간과 노력을 가늠할 수 있어야 한다. 이는 일정 계획 및 자원 할당에 도움을 준다
- Small: User Story는 한 스프린트에 완수될 수 있을 정도로 작아야 한다. 작을수록 관리하고 잦은 배포가 가능하다
- Testable: 모든 User Story는 분명한허용기준을 가지고 있어야 한다. 이 허용 기준은 테스트 및 검증에 활용된다
아티클3: GALAXYCONSULTING / business analysis user stories and agile methodology
User story 개념과 이해
A user story is a short, simple description of a feature told from the perspective of the person who desires the new system capabilities, usually a user or a customer of the system. It is one or few sentences in the everyday or business language that captures what a user does or needs to do as part of his or her job functions.
User Story는 Agile 방법론과 함께 사용되며 비즈니스 시스템이 제공해야할 기능을 정의하는데 근간이 된다.
User Story는 요구사항의 "who, "what" 그리고 "why"를 간단한 방식으로 담아낸다
User Story는 요구사항 관리 문서 없이 요구사항을 빠르게 다루는 방법이다. User Story는 논의될 때만 사용된다.
User Story 만드는 법
요구사항 수집 기간 동안, BA는 사용자 대표를 만나 구체적인 비즈니스 요구사항을 식별하고 User Story를 만든다.
User Story는 INVEST에 따라 작성되도록 한다
- Independent: 독립적이어야 한다
- Negotiable: 항상 변경되거나 다시 작성될 수 있다
- Valuable: end user에게 가치를 제공해야 한다
- Estimatable: User Story의 크기를 가늠할 수 있어야 한다
- Sized appropriately or Small: 계획(구현에 얼만큼 소요될지), 작업(누가 작업해야할지), 우선순위(뭐를 먼저 구현할지)를 정할 수 없을 정도로 커선 안된다.
- Testable: 테스트 수행에 필수적인 정보를 제공해야 한다
Template:
- As a "role", I want "goal" so that "benefit"
- As a "user", I want to "do something" so that "I can accomplish goal"
- As a "user", I want "function" so that "value"
아티클4: CREDERA / The BA perspective: How to INVEST in a good user story?
User story 개념
A user story is an informal, non-technical, concise description of the user's needs a given feature addresses in the project. User stories, which can be modified as the porject progresses, help maintain a customer-centric approach to development.
User Story 만드는 법
User Story를 작성하기 전, BA는 고객의 요구사항을 이해하고 있어야 한다. 요구사항은 요구사항 수집 또는 요구사항 도출이라는 구조화되고, 반복적인 프로세스를 통해 습득된다. 이 정보를 기반으로 사용자의 요구사항을 충족시킬 User Story를 작성한다.
User Story는 User Persona, Feature, Goal로 구성된다.
- User Persona: 기능이 구현될 때 이득을 얻을 사용자를 정의한다
- Feature: 구현되어야 할 기능을 묘사한다
- Goal: 기능 구현으로 사용자가 얻는 이득을 묘사한다
User Story는 INVEST해야 한다.
fail-safe mechanism에 의해, 모든 User Story는 허용 기준을 가지고 있어야 한다. 만약 그렇지 않다면 다시 작성되어야 한다.
- Independent: User Story는 의존적이어선 안된다. 각각 작업될 수 있어야 하는 동시에 최적의 프로세스로 빠른 출시가 가능해야 한다.
- Negotiable: 꼭 지켜야하는 계약이 아닌, 협업을 위해 협상 가능한 것이어야 한다. User Story는 소비자의 기대와 구현된 제품 간 간극을 줄이기 위한, 요구사항의 이해 용도이다.
- Valuable: 여기서 가치란 비기능적인 요구사항 형태가 될 수도 있다. 또한 가치는 User Story가 작성되고 우선순위가 정해지는 와중에도 계속 고민이 필요한 부분이다.
- Estimable: User Story의 우선순위를 정의하기 위해선 가늠 가능해야 한다. 이를 기반으로 개발자들이 자원을 할당하고 적절한 구현 일정을 세울 수 있다.
- Small: User Story는 업무의 작은 단위이다. 이는 한 iteration(sprint) 내에 구현될 수 있어야 한다
- Testable: User Story 초기에 분명한 허용 기준은 QA에게 도움이 되고 ATDD 프로세스로(acceptance test-driven development)의 전환을 용이하게 한다
User Story는 사용자 요구사항 수집 과정 중 혹은 이후 BA가 작성하는 문서이다.
who, what, why로 구성되며 작성된 문장은 INVEST를 충족해야 한다.
'해외 > 직무 분석' 카테고리의 다른 글
| Business Analyst 이해하기 (1) (0) | 2024.07.27 |
|---|