"구매자로서, 다음에 더 빨리 결제할 수 있도록 결제 수단을 저장하고 싶습니다." 이것이 바로 사용자 스토리입니다. 이는 명세서가 아니라 한 문장입니다. 애자일 소프트웨어 개발팀은 이러한 사용자 스토리를 인덱스 카드나 포스트잇에 적습니다. 이 형식은 작성자가 역할, 목표, 그리고 이유를 명확히 밝히도록 합니다. 데이터베이스 스키마가 아닌 실제로 기능을 사용할 사람에게 초점을 맞추게 해줍니다.

사용자 스토리는 1990년대 후반 켄트 벡과 론 제프리스에 의해 널리 알려졌습니다. 사용자 스토리는 의도적으로 불완전한 형태로 작성됩니다. 이 카드는 대화를 위한 약속입니다. 개발자, 디자이너, 제품 관리자는 세부 사항을 논의하고, 승인 기준은 나중에 추가됩니다. 너무 큰 스토리는 에픽이라고 하고, 너무 모호한 스토리는 버그 발생 가능성을 높입니다.

세 가지 C

• Card
• 대화
• 확인

좋은 스토리는 독립적이고, 협상 가능하며, 가치 있고, 평가 가능하며, 작고, 검증 가능합니다. 이 네 가지를 나타내는 약자는 INVEST입니다. 하지만 이는 종교가 아닙니다. 어떤 팀은 스토리를 직무 스토리처럼 작성하기도 합니다. 예를 들어, "시간이 촉박할 때, 기차를 놓치지 않도록 한 번의 탭으로 결제하고 싶다."와 같이 말이죠. 같은 아이디어지만 관점이 다를 뿐입니다.