초간단 User Stories (사용자 스토리) 요약

‘User Stories Applied’로 유명한 Mike Cohn의 웹사이트에서 User Stories에 대해 잘 정리된 글을 발견하였다. (엄청 짧다)
이 정도로도 충분한데 대체 300페이지가 넘는 두꺼운 책은 왜 쓰셨는지.

아래는 그 짧은 글의 내 입맛대로 요약본.

User Story란?

실 사용자의 관점에서 작성된 해당 기능의 짧고, 간단한 설명.
아래와 같이 보통 작성한다.

As a _____, I want _____ so that _____.

예제를 보자

아래는 epics, 즉 아주 커다란 사용자 스토리의 예이다.

As a user, I can backup my entire hard drive.

당연히 이건 한 번의 iteration으로 끝낼 분량이 아니다. 따라서, 아래와 같이 여러 개로 쪼갠다.

As a power user, I can specify files or folders to backup based on file size, date created and date modified.

As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.

세부사항을 넣어야 한다면 어떻게?

일단 해당 사용자 스토리를 잘게 쪼개본다. 또는 “Conditions of satisfaction(CoS)” 항목을 추가한다.

CoS는 간단히 말해 high-level acceptance test로 볼 수 있는데, 아래 사용자 스토리 예를 보면 좀 더 명확해진다.

As a vice president of marketing, I want to select a holiday season to be used when reviewing the performance of past advertising campaigns so that I can identify profitable ones.

이렇게 작성하다보니 뭔가 추가적으로 적어주어야 할 것 같은 의무감 같은 것이 생겼다.
그래서 아래와 같이 CoS를 추가해서 세부사항을 언급해주었다.

  • Make sure it works with major retail holidays: Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.
    Support holidays that span two calendar years (none span three).
  • Holiday seasons can be set from one holiday to the next (such as Thanksgiving to Christmas).
  • Holiday seasons can be set to be a number of days prior to the holiday.

누가 사용자 스토리는 쓰나?

누구든 상관 없다. product backlog를 관리하는 것이 PO의 의무이긴 하지만, PO가 반드시 사용자 스토리를 쓰란 법은 없다.

언제 쓰나?

프로젝트 기간 내내. 적어도 3 ~ 6개월 주기로 product backlog의 (재)작성, 수정 등의 작업은 필요하다.

사용자 스토리는 요구사항 정의서를 대체하는 것인가?

적어도 애자일 프로젝트에서는 사용자 스토리가 가장 선호되는 product backlog 양식이다.

“As a user, I want …” 부분을 실 요구사항에 대한 포인터로 사용하는 것도 좋은 생각이다. 즉 사용자 스토리는 Workflow diagram이나, 계산방법을 보여주는 Spreadsheet, 또는 팀이나 PO가 필요로하는 어떤 형태의 artifact도 가리킬 수 있다.

 

추가적으로, 아래 링크에서 조금 더 세부적인 내용을 확인할 수 있다.
여전히 짧은 글이지만 조금 더 많은 예제와 ‘INVEST’ 등의 사용자 스토리 작성 원칙들이 기술되어 있다.

Writing User Stories, Examples and Templates In Agile Methodologies