🎒 잘 작성된 유저 스토리의 6가지 특징

애자일팀이 일하는 방식의 중심에 사용자 스토리가 있습니다. 잘 작성된 사용자 스토리는 서로 협력하는 팀, 고성과팀, 고객에게 가치를 전달하는 팀을 리딩할 수 있습니다.

2022.10.12 | 조회 1.31K |

구독자님, '에디'🦊 입니다.
'에디의 만능배낭'은 성장을 갈망하는 일잘러들을 위한 뉴스레터입니다. 인상깊었던 비즈니스, 리더십, 매니지먼트, 조직문화' 관련 아티클을 요약 정리해서 정성껏 담아 보내드립니다:D
(마음에 드는 아티클에 '👍도움이 되었어요'도 눌러주세요)

- 지속 가능함을 위해, 정해진 주기 없이 1개의 아티클이 정리되면 바로 보내드립니다.

➿잘 작성된 유저스토리의 6가지 특징

"애자일팀이 일하는 방식의 중심에 유저스토리가 있습니다. 잘 작성된 사용자 스토리는 서로 협력하는 팀, 고성과팀, 고객에게 가치를 전달하는 팀을 리딩할 수 있습니다. 그러나 유저스토리를 '잘 작성'하는 것이 사실 그리 쉽지만은 않습니다. 유저 스토리를 '잘 작성'하는 것, 여기서부터 출발하시면 좋습니다."

2003년, [Extreme Programming Explored]와 [Refactoring Workbook]의 저자, 윌리엄 웨이크는 '좋은 스토리의 여섯 가지 특성'의 영문 첫 글자를 따서 'INVEST'라는 이름을 제안하였다.
'독립적이다(Independent)' 가능하면 스토리 간에 의존성을 배제하도록 신경 써야 한다. 의존성이 있으면 우선순위 결정과 계획 수립에 문제를 야기한다.
'협상 가능하다(Negotiable)' 스토리는 협상 가능해야 한다. 스토리는 계약서나 요구사항 명세서처럼 꼭 구현해야 한다고 기록된 것이 아니다. 스토리는 기능에 대한 짧은 설명 일 뿐, 세부사항은 고객과 개발 팀이 대화를 통해 협상해야 한다.
'사용자 및 고객에게 가치가 있다(Valuable)' 스토리는 고객이나 사용자에게 제공하는 이점이 드러나도록 작성해야 한다. 스토리가 고객이나 사용자에게 가치 있도록 하는 가장 좋은 방법은 고객이 직접 스토리를 작성하게 하는 것이다. 처음에는 고객이 불편해 할 수도 있다. 스토리 카드가 정식 협약이나 상세 기능 설명이 아니라 나중에 대화를 재개할 수단으로 사용된다는 개념에 익숙해지면 고객들이 스토리를 자발적으로 작성하기 시작한다.
'추정 가능하다(Estimatable)' 개발자들이 각 스토리의 크기 혹은 작업 소요 시간을 추정(적어도 추측)할 수 있어야 한다. 추정이 쉽지 않은 경우는 보통 다음의 세 가지 원인 때문이다. 1)해당 분야의 지식(도메인 지식)이 부족하다. 2)기술적인 지식이 부족하다. 3)스토리가 너무 크다.
'작다(Small)' 스토리 크기가 너무 크면 계획 단계에서 사용할 수 없다. 어떤 스토리가 적절한 크기인가 그렇지 않은가 하는 문제는 개발 팀의 역량이나 사용하는 기술에 따라 결정된다. 또한, 복잡한 스토리는 크기가 크면서도 작은 스토리들로 나누기가 쉽지 않다. 대개 스토리 자체에 대한 불확실성 때문에 복잡해지는 경우가 많은데, 이런 경우에는 문제를 조사하는 스토리와 기능을 개발하는 스토리로 나눌 수 있다.
'테스트 가능하다(Testable)' 스토리는 테스트 가능하도록 작성해야 한다. 테스트를 성공적으로 통과해야 그 스토리가 성공적으로 개발되었다고 말할 수 있다. 스토리가 테스트할 수 없게 작성되었다면, 개발자가 언제 코딩을 그만 두어야 할지 알 수 없다.
개발자는 고객이 직접 스토리를 작성하는 것을 도울 책임이 있다. 스토리는 고객과 의견을 주고 받기 위한 약속이지 상세한 명세서가 아니다. 기술과 관련되거나 시스템의 기반 구조 개발에 관한 스토리가 필요하다고 생각한다면, 그것들을 직접 언급하는 대신 사용자와 고객에게 가치를 제공하는 측면에서 설명할 책임이 있다.
고객은 스토리를 작성할 책임이 있다. 스토리는 의견을 주고 받기 위한 약속이지 상세한 명세서가 아니다.

'👍도움이 되었어요' 누르고, 도서 정보 보러가기