제품 핵심 C · 업계 관례

User Story

사용자 스토리

User Story는 짧은 문장이야. 사용자가 누구인지, 무슨 작업이 필요한지, 왜 도움이 되는지를 말해줘.

당신은 이것을 이렇게 부를 수 있습니다 User Story스토리~로서 나는 ~를 원한다

작동 방식을 확인하세요

원본 작업 예제사용자 스토리

다른 예시

“편집자로서, 연결이 끊겨도 내 초안이 사라지지 않도록 자동 저장 기능을 원합니다.”

주요 부분

  1. 01User or role
  2. 02Needed capability
  3. 03Value or outcome

사용할 때

이것은 빌드에 대한 논의를 명확한 사용자 이익과 연결하는 데 사용하세요.

다음 경우에는 사용하지 마세요

하나의 짧은 스토리가 모든 예외 사례를 다루거나 명확한 수락 체크를 대신할 것이라고 기대하지 마세요.

코드에서 사용된 이름

As a / I want / so that

출시하기 전에

Check the target user, wanted result, current baseline, evidence source, scope, owner, and success level. List assumptions, open risks, and the next test or decision.

복사 가능한 요청

Outcome:Complete the task with 사용자 스토리 (User Story)。 User context:“편집자로서, 연결이 끊겨도 내 초안이 사라지지 않도록 자동 저장 기능을 원합니다.” Product concept to apply:사용자 스토리 (User Story)。 Why it fits:이것은 빌드에 대한 논의를 명확한 사용자 이익과 연결하는 데 사용하세요. Do not use it when:하나의 짧은 스토리가 모든 예외 사례를 다루거나 명확한 수락 체크를 대신할 것이라고 기대하지 마세요. Product framing: Name the target user and wanted result. Record the current baseline and evidence. Set what is in and out of scope, the limits, the owner, and the time frame. Decision quality: Keep facts, guesses, and unknowns separate. Record the options you did not choose and what evidence would change the decision. Acceptance criteria: The document names an owner, target user, measurable result, scope limit, evidence source, open risks, and next test. Evidence and limits (evidence boundary):하나의 공식 표준이 전체 용어를 통제하지 않음. 의미는 팀, 플랫폼 또는 프레임워크마다 달라질 수 있음. Unknowns to confirm: Target group, baseline, success level, owner, time frame, dependencies, and review schedule.

이 요청을 확인하세요

Review how 사용자 스토리 (User Story) is used now. Definition: User Story는 짧은 문장이야. 사용자가 누구인지, 무슨 작업이 필요한지, 왜 도움이 되는지를 말해줘. Release checks: Check the target user, wanted result, current baseline, evidence source, scope, owner, and success level. List assumptions, open risks, and the next test or decision. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.

C
이 용어는 얼마나 공식적인가요?

업계 관례

사람들은 직장에서 이 용어를 자주 사용합니다. 나열된 출처는 실습이나 제한을 지원할 수 있습니다. 모든 부분의 정의를 제공하지는 않습니다.

하나의 공식 표준이 전체 용어를 통제하지 않음. 의미는 팀, 플랫폼 또는 프레임워크마다 달라질 수 있음.

범위
소스가 포함하는 것만:정규 이름、정의、사용 안내、피해야 할 상황 안내
문서 상태
안정적인
선택됨
2026-07-30

증거 출처 및 범위

권위 있는 출처 · Agile Alliance · 안정적인 Agile Glossary — User Stories 범위: 정규 이름、정의、사용 안내、피해야 할 상황 안내 여기 역할: 정의가 아닌 유용한 배경 출처 범위: 정규 이름, 정의, 사용 안내, 피해야 할 상황 안내

직접 복사

브라우저가 이것을 복사할 수 없습니다. 아래 요청을 선택하고 직접 복사하세요.