[u] Story 의 naming convention 을 Story 방식으로 변경함.

팀 내 Rational Team Concert 적용을 위한 가이드 제작 중 유용한 팁이 있어 공유한다.

RTC 에서 Scrum 템플릿을 사용할 경우, 플래닝에 사용되는 work item 타입은 기본적으로 (범위가 큰 것부터 차례로) Epic, Story, Task, 이렇게 세 가지이다. Scrum에 문외한인 사람들뿐 아니라, Scrum 에 나름 익숙한 사람들도 계획을 잡기에 익숙해지기까지는 제법 많은 난관에 부딪힌다. 이에 내 경험을 바탕으로 나름의 노하우를 정리해보았다. 이 방식을 잘 익히고 따른다면 계획을 잡는데 많은 도움이 되리라 확신한다.

Work Item Hierarchy vs. Iteration Hierarchy

• Epic 은 Release Backlog 이상 레벨에만 존재한다. Product Backlog 는 당연히 이에 해당되며, Sprint(Iteration) Backlog 에 나타나면 안된다.
• Story 는 Sprint Backlog 에 할당된다.
• Story 가 한 Sprint 에 끝낼 수 없을만큼 크다면 타입을 Epic 으로 변경한다.
• 반대로, Epic 이 한 Sprint 에 끝날 수 있을만큼 작다면 Story 로 변경한다.
• Task 는 당연히 Sprint Backlog 에 할당된다.

덤으로..

• Epic/Story 에는 owner 를 할당하지 않는다. (Task 에만 owner 를 할당하라.)
• Task 의 크기는 4시간 이내가 적당하다. (이를 초과하면 두 개 이상의 더 작은 Task 로 분할하라.)
• Task 밑에 하위 Task 가 존재할 수 없다.

Work Item Hierarchy and Progress

• Backlog 진척도 = Backlog 안의 모든 Story 들의 Story Point 총합.
• Epic 진척도 = 모든 하위 Story 들의 Story Point 총합.
• Story 진척도 = 모든 하위 Task 들의 작업 시간 총합.

추가로..

• Story Point 는 Release Burndown 차트 생성의 기초 자료가 된다.
• 작업 시간은 Sprint Burndown 차트 생성의 기초 자료가 된다.

Work Item Naming Conventions

• Epic: 고수준 요구사항 – ‘명사’ 혹은 ‘명사구’.
• Story: 저수준 요구사항 – ‘주어 + { MUST | SHOULD | MAY } + be able to..’.
• Task: 명령문 – ‘동사 + 목적어’.

스크럼이나 유사 Agile 방식에 익숙하지 않다면 Story 의 naming 이 생소할 수 있다. 생각해보면 간단하다. ‘고객/사용자가 이 제품(Product)으로 무엇을 할 수 있다.’ 의 형태이다. Story 를 이렇게 작성할 때 얻게되는 대표적인 이점은 아래와 같다.

1. 사용자와 고객의 관점에서 요구사항이 정리되므로, 커뮤니케이션 로드와 오해를 최소화시킨다.
2. 개발자에게는 구현 목적을 명확히 해준다. (이 기능이 고객에게 어떤 가치를 제공하는지 쉽게 알 수 있다.)
3. 고객에게 불필요한 요구사항이 포함되는 것을 최소화시킨다. (주로 엔지니어의 흥미나 욕심이 반영될 경우 발생한다.)
4. Story 그대로 사용자 테스트 항목이 되고 데모 시나리오가 된다.

혹 스크럼 형태의 Story 네이밍에 익숙하지 않다면 아래와 같은 방식도 시도해볼 수 있다. 하지만 처음 러닝 커브는 작을 지라도, 경험상 정통 스토리 방식이 더욱 효과적이다.

• Story: 저수준 요구사항 – ‘주어 + { MUST | SHOULD | MAY } + 동사 + 목적어’.