사용자 스토리(User Story)는 사용되는 소프트웨어 기능(Feature) 혹은 요구사항(Requirements)을 의미하며 일반적으로 한 두 문장으로 짧게 표현되며, 상세한 명세보다 의사소통을 활성화시키려는 목적으로 사용되며, 사용자 스토리는 한두 명의 개발자가 2주일 안에 구현하고 테스트 할 수 있는 정도의 크기가 적당하고, INVEST 원칙(여섯 가지 특성)을 고려하여 충실하게 작성하는 것이 중요합니다.

사용자 스토리 작성 책임

개발자는 고객이 직접 스토리를 작성하는 것을 도울 책임이 있습니다.

기술과 관련되거나 시스템의 기반구조 개발에 관한 스토리가 필요하다고 생각한다면, 그것들을 직접 언급하는 대신 사용자와 고객에게 가치를 제공하는 측면에서 설명할 책임이 있습니다.

사용자 스토리의 여섯 가지 특성 (INVEST 원칙)

최근에 제가 프로젝트에서 수행했던 사용자 스토리 생성 사례를 보여드립니다. Agile 협업도구를 활용하여 사용자스토리를 생성했으며, 서브시스템을 컴포넌트로 정의하고, 사용자스토리 상위기능으로서 업무구분을 커스텀필드로 정의하여 활용하였습니다. 또한, 사용자 스토리에 대해 우선순위를 선정하고, 담당자를 Assign합니다.

고도의 협업체계 구성

Agile Task Board 활용

구현해야 할 사용자 스토리 카드를 할일, 진행 중, 완료로 구분하여 화이트보드에 붙여가며 이해관계자들과 공유합니다. 또는 아래의 사례와 같이 협업도구의 Agile Task Board를 활용하여 아래와 같이 전체 또는 담당자별로 사용자 스토리 현황을 일목요연하게 공유/관리 할 수 있습니다. 사용자 스토리 작업상태를 변경하려면, 해당 사용자스토리를 클릭하고 원하는 상태위치로 Drag&Drop하여 손쉽게 이동하면 됩니다.
 

사용자 스토리 규모추정

사용자 스토리마다 우선순위를 부여하여 릴리즈 계획, 이터레이션 계획에 반영합니다. 우선순위는 Blocker (긴급), Critical (심각), Major (높음), Minor (보통), Trivial (낮음) 등으로 정의하여 활용 될 수 있습니다. 각 스토리에 대한 가치와 추정치를 참고하여 조직에 전달하는 가치가 최대가 되도록 스토리를 정렬하는 것이 중요합니다.

Burn down Chart (소멸차트) 활용

시간이 지나감에 따라 남아 있는 사용자 스토리 작업량을 대쉬보드, Burn down Chart 등을 통하여 확인할 수 있습니다. 아래 초록색으로 표시된 선이 날짜에 따라 남아있는 작업량 or 이슈건수를 보여 주고 있습니다.

이번 글에서는 주로 사용자 스토리 정의 및 Agile 협업도구 활용 Practice 에 대해 소개하였으며, 다음 3편에서는 CTIP(Continuous Test & Integration Platform) 기반 빌드체계 및 테스트 강화 Practice를 소개합니다. 기대해 주세요!