유저스토리는 불확실성을 거래하는 단위였다

Jira에서 Story는 대개 티켓의 한 종류다. 제목 아래에 As a... 문장을 쓰고, 세부 요구사항과 acceptance criteria를 채운 뒤 개발자에게 넘긴다. 내용이 자세할수록 준비가 잘된 티켓처럼 보인다.

1990년대 후반 켄트 벡이 XP에서 사용한 유저스토리는 이런 문서가 아니었다. 스토리는 고객이 원하는 진전을 작은 단위로 나누고, 개발자가 그 비용을 추정하며, 양쪽이 지금 무엇을 만들지 선택하기 위한 도구였다. 요구사항의 그릇보다 불확실성을 거래하는 단위에 가까웠다.

구현할 만큼 자세하지 않아도 됐다

1999년에 켄트 벡의 초기 글을 중심으로 정리된 XP 개요는 유저스토리를 “추정하고 우선순위를 정할 수 있을 만큼의 유스케이스”로 설명한다. 구현에 필요한 모든 정보를 담는 대신, 다른 스토리와 비용과 순서를 비교할 수 있을 정도만 적었다.

카드가 모이면 고객은 제품 전체를 한눈에 놓고 볼 수 있었다. 프로그래머가 추정치를 붙이면 무엇을 먼저 얻고 무엇을 미룰지 결정했다. 스토리는 고객이 프로그래머의 피드백을 받아 직접 썼기 때문에 자연스럽게 사업의 언어를 유지했다.

초기 XP 위키에 남은 켄트 벡의 설명은 범위를 더 넓힌다. 스토리가 매번 직접적인 사업가치를 나타낼 필요는 없지만, 고객이 인정하는 진전은 나타내야 한다. 무엇을 진전으로 셀 것인지 아는 쪽이 고객이므로 스토리를 자르는 권한도 고객에게 있었다.

이 관점에서 스토리와 엔지니어링 태스크는 다르다. 스토리는 고객이 알아볼 수 있는 진전이고, 태스크는 그 진전을 만들기 위해 개발팀이 선택하는 기술 작업이다. 데이터베이스 변경, API 추가, 화면 수정은 한 스토리를 구현하는 과정에서 나올 수 있지만 그 자체로 고객의 진전이 되는 것은 아니다.

유명한 문장 형식은 나중에 붙었다

As a [역할], I want [기능], so that [가치] 형식은 켄트 벡이 만든 원형이 아니다. 2001년경 영국 Connextra 팀에서 등장했고 이후 널리 퍼졌다. Agile Alliance도 이 형식을 초보 팀을 위한 보조 바퀴로 설명한다. 누구를 위한 일이며 왜 필요한지 놓치지 않게 돕지만, 문장을 채우는 행위가 대화를 대신할 수는 없다.

스토리 카드가 짧았던 이유도 여기에 있다. 카드에는 합의 전체가 들어가지 않는다. 모두가 나중에 어떤 대화를 해야 하는지 기억할 만큼만 남는다. 세부사항을 미리 고정하지 않았기 때문에 고객은 작동하는 소프트웨어를 본 뒤 마음을 바꿀 수 있었고, 개발자는 구현 중 발견한 사실을 다시 협상에 가져올 수 있었다.

유저스토리는 잘 쓴 요구사항 문서가 아니라 선택 가능한 범위였다. 이 작은 차이를 받아들이면 XP의 계획 방식 전체가 따라 나온다.