우수한 제품 백로그 만들기
팀에서는 일반적으로 사용자 스토리가 포함된 제품 백로그를 만들어 고객이 필요로 하며 중요하게 생각하는 사항을 나타냅니다. 또한 프로젝트를 진행하는 동안 사용자 스토리에 대한 세부적인 정보를 추가하고, 사용자 스토리를 보다 작은 스토리로 세분하고, 사용자 스토리에 대해 우선 순위를 지정하고 평가한 다음, 최종적으로 사용자 스토리를 구현하고 해당 결과를 고객에게 전달합니다. 올바른 사용자 스토리를 작성하고 제품 백로그를 지속적으로 업데이트하면 팀에서는 고객이 중요하게 생각하는 사항을 고객에게 보다 효율적으로 전달할 수 있습니다.
Bill Wake는 Independent(독립적), Negotiable(협상 가능), Valuable(가치 있는), Estimable(예측 가능), Small(소규모) 및 Testable(테스트 가능)의 첫 글자를 딴 INVEST라는 용어로 유용한 사용자 스토리를 이루는 요소를 요약하고 있습니다. 자세한 내용은 XPlorations 웹 사이트를 참조하십시오. 또한 Mike Cohn은 그의 저서에서 사용자 스토리를 작성하는 방법에 대해 논의하고 있습니다. 관련 내용은 User Stories Applied for Agile Software Development에서 다운로드할 수 있습니다.
팀에서 사용자 스토리를 만들 때는 다음과 같은 사항을 확인하여 사용자 스토리가 고객이 중요하게 평가하는 요소를 나타내고 있는지 확인해야 합니다.
사용자
사용자가 수행해야 하는 작업
사용자가 해당 작업을 수행해야 하는 이유
대부분의 경우 팀에서는 이를 위해 효과적인 제목을 만듭니다. Mike Cohn이 제안하는 제목은 "<user>는 <reason>을 목적으로 <action>을 수행해야 함" 형태입니다. 예를 들어 "고객 지원 담당자는 고객의 문의에 보다 빠르게 대응할 수 있도록 고객 정보에 액세스해야 함"이 이러한 형태의 제목입니다. 대개 <reason> 부분은 분명해야 합니다. 예를 들어 "채식주의자는 채식 식단만 표시되도록 뷰를 필터링할 수 있음"과 같은 형태입니다.
또한 사용자 스토리는 임의의 순서로 구현할 수 있도록 정의해야 합니다. 그러나 사용자 스토리를 완전히 독립적으로 작성하는 것이 실용적이지 않은 경우도 있습니다. Bill Wake와 Mike Cohn은 모두 사용자 스토리를 독립적으로 만들기가 어려울 때 팀에서 사용할 수 있는 기술에 대해 설명하고 있습니다.
앞에서 설명한 것과 같이 가치 있고 독립적인 사용자 스토리는 제품 백로그를 보완합니다. 팀에서는 사용자 스토리를 평가하고 우선 순위를 지정한 다음 가장 높은 순위의 사용자 스토리에서부터 작업을 시작합니다. 팀에서 사용자 스토리를 구현하려면 먼저 사용자 스토리의 특성이 다음 목록에 설명된 것과 같은지 확인해야 합니다. 제품 소유자는 가장 높은 순위가 매겨진 사용자 스토리가 이러한 조건을 충족하는지 확인한 후에 스프린트 계획 회의로 진행하게 됩니다.
스프린트에서 구현할 수 있을 만큼 크기가 작아야 합니다.
구현하려는 사용자 스토리는 스프린트 내에서 완료할 수 있을 만큼 크기가 작아야 합니다. 제품 소유자는 팀과 협력하여 사용자 스토리가 너무 크기 않도록 세분합니다. 예를 들어 "고객 지원 담당자는 고객의 문의에 보다 빠르게 대응할 수 있도록 고객 정보에 액세스해야 함"이라는 사용자 스토리는 스프린트 내에서 완료하기에는 너무 큽니다. 이 사용자 스토리는 "고객 지원 담당자는 고객의 전화 번호를 사용하여 고객의 이름 및 최근 통화 요약에 액세스해야 함"과 "고객 지원 담당자는 현재 문제를 보다 세부적으로 조사할 수 있도록 고객의 전체 통화 내역에 액세스해야 함"이라는 스토리로 세분할 수 있습니다.
스토리를 구현하는 데 필요한 작업을 기술하고 평가할 수 있을 정도로만 세부적이어야 합니다.
사용자 스토리를 스프린트에 포함하기 전에 이를 스토리 점수로 평가합니다. 스토리 점수는 대략적인 예상 값으로, 주로 백로그를 관리하고 스프린트의 준비 과정을 돕는 데 사용됩니다. 스프린트가 시작되면 팀에서는 사용자 스토리를 구현에 필요한 작업으로 세분합니다. 또한 팀에서는 사용자 스토리를 작업으로 세분하여 작업 시간을 평가하기 전에 제품 백로그 정리 회의에서 제품 소유자와 협의하여 추가 정보가 필요한 스토리를 결정합니다. 제품 소유자는 이러한 정보를 수집하여 사용자 스토리의 설명에 기록할 수 있습니다.
사용자 스토리에 필요 이상으로 많은 정보를 추가하지 않도록 주의해야 합니다. 사용자 스토리는 사용자 스토리가 완료되어 수락될 때까지 지속되는 제품 소유자 및 고객과의 대화와 협상에 기초로 사용되어야 합니다. 지나치게 세부적인 사용자 스토리는 정보가 정확하지 않다는 인상을 주어 협상에 불리하게 작용할 수 있습니다.
승인 기준을 정의해야 합니다.
스프린트가 끝날 때 고객이나 제품 소유자는 사용자 스토리를 완료된 것으로 승인하거나 거부하게 됩니다. 스프린트가 시작되기 전에 고객 승인의 기준을 가능한 한 명확하게 기술해야 합니다. 물론 예상하지 못한 이유로 사용자 스토리가 승인되지 않는 경우도 있습니다. 하지만 팀에서 승인 기준을 쉽게 정의할 수 있도록 고객과의 대화를 가지면 고객이 원하는 바를 파악하는 데 도움이 됩니다. 사용자 스토리를 사용한 작업의 완료 여부를 보다 효율적으로 평가할 수 있도록 이 승인 기준을 승인 테스트의 기초로 사용할 수 있습니다.
에픽 및 테마
사용자 스토리가 작아야 한다는 것은 자주 강조되는 사항입니다. 구현하려는 사용자 스토리의 경우에는 이를 특히 주의해야 합니다. 하지만 순위가 낮은 스토리는 크기가 커도 됩니다. 실제로 스토리 크기가 크면 제품 백로그가 너무 커져서 관리하기 어려워지는 것을 방지할 수 있습니다. 사용자 스토리는 보다 작은 여러 개의 사용자 스토리로 세분할 수 있으며 세분된 사용자 스토리는 우선 순위가 지정된 제품 백로그의 맨 위에 나타납니다. 크기가 큰 사용자 스토리를 에픽 및 테마로 생각하면 쉽게 이해할 수 있습니다.
에픽은 상당한 양의 작업을 나타내는 매우 큰 사용자 스토리입니다. 에픽을 세분하면 여러 개의 테마와 보다 작은 다른 사용자 스토리를 만들 수 있습니다.
테마는 매우 큰 사용자 스토리로, 일반적으로 스프린트에서 구현할 수 있는 것보다 더 큽니다. 팀에서는 테마를 구현하기 전에 이를 보다 작은 사용자 스토리로 세분해야 합니다.
제품 백로그의 우선 순위를 지정할 때는 상위에 있는 에픽과 테마를 세분하고, 보다 작은 새 사용자 스토리의 우선 순위를 지정합니다. 이 작업을 마쳤으면 우선 순위가 가장 높은 사용자 스토리는 구현할 수 있을 만큼 작아야 합니다. 우선 순위가 지정된 백로그의 하위에 있는 대부분의 사용자 스토리는 일반적으로 이보다 큽니다.
스파이크
팀에서 사용자 스토리의 직접 구현이 아닌 작업을 수행해야 하는 경우가 종종 있습니다. 이 작업을 스파이크라고 합니다. 일반적인 스파이크 유형으로는 조사, 수정해야 할 버그, 프로세스 또는 엔지니어링 개선의 세 가지가 있습니다. Team Foundation에서 스파이크를 만들려면 사용자 스토리 작업 항목을 만들고 해당 형식을 스파이크로 설정한 다음 제품 백로그에서 다른 사용자 스토리와 함께 우선 순위를 지정합니다.
조사
사용자 스토리를 작업으로 완전히 세분하고 평가하기 전에 사용자 스토리와 관련하여 답변해야 하는 미해결 질문이 있으면 조사가 수행됩니다. 예를 들어 스프린트 계획 회의 중 팀에서 "단골 승객이므로 보너스 탑승권을 예약할 수 있습니다."라는 스토리가 나타날 수 있습니다. 논의 후 답변된 사항보다 질문 사항이 더 많으면 팀에서는 사용자 스토리를 만들어 이 스파이크를 나타냅니다. 이때 예를 들어 "팀 멤버는 이후 스프린트에 포함할 스토리를 작성할 수 있도록 '보너스 탑승권 예약'의 의미를 이해할 수 있음"이라는 사용자 스토리를 만들 수 있습니다. 그런 다음 팀에서는 해당 조사에 전담할 시간을 결정하고 해당 값을 스파이크의 기간으로 작성합니다. 스파이크 중에 작성되는 어떤 스토리로 해당 반복 중에는 수행할 수 없습니다. 제품 백로그를 사용하여 이후 반복에서 수행하도록 작업 일정을 지정해야 합니다.
수정해야 할 버그
버그는 발견되었을 때 수정하는 것이 가장 좋습니다. 버그를 발견한 당일에 이를 수정할 수 없으면 이 버그를 추적할 수 있도록 버그 작업 항목을 만들어야 합니다. 버그가 누적되지 않도록 주의해야 합니다. 팀에서는 버그가 누적되면 사용자 스토리를 만들고, 다른 사용자 스토리 및 스파이크와 함께 평가하고 우선 순위를 지정할 수 있도록 해당 버그를 스파이크에 연결합니다.
프로세스 또는 엔지니어링 개선
팀에서는 프로젝트 성공에 도움이 되는 프로세스 또는 엔지니어링 개선 작업을 수행합니다. 이러한 개선 작업은 종종 스프린트 회고 및 매일의 Scrum 회의 도중에 확인됩니다. 예를 들어 단위 테스트를 통해 코드 검사를 개선하거나 연속 통합 서버에서의 빌드 시간을 줄여야 할 수 있습니다.