사용자 스토리를 너무 자세하게 쓰는 것은 놀랍도록 위험

(mountaingoatsoftware news letter 5/30 참고)

사용자 스토리를 작성하는 것의 주간 팁 시리즈를 진행하면서, 저는 2가지 진실을 공유하고 싶습니다. 하나는 잘 알려진 것이고 다른 하나는 덜 직관적인 것이죠.

진실 1: 스토리가 구현으로부터 멀면 멀수록, 디테일이 적다.

진실2: 곧 다가올 스토리 조차도 생각만큼 디테일이 필요하지 않다.

디테일의 사이렌 송

 

많은 사람들은 디테일에 이끌립니다. 프러덕트 개발의 어지러움 속에서, 우리는 명확성을 갈망합니다. 그래서 우리는 스토리에다가 구체적인 사항들을 얹습니다. 너무 일찍 얹죠. 그것이 생산적인 것 같지만, 종종 그것은 그냥 낭비입니다.

여행 예약 사이트를 개발한다고 생각해 보죠. 여러분은 기초적인 것 부터 시작할 것입니다: 항공, 호텔, 렌터카죠. 언젠가 여러분은 우주여행을 하고 싶을 것입니다. 그러나 그건 한참동안 없을 것입니다.

만약 여러분이 오늘 우주 여행 예약에 대한 세부적인 백로그 아이템을 작성한다면, 그것들은 여러분이 개발할 쯤엔 틀린 것들이기 쉽습니다. 그것들을 지금 작성하는 것은 낭비죠.
 

정확성의 덫

 

그것은 너무 많은 디테일로 고생하는 것은 미래로부터 멀리 떨어진 스토리만이 아닙니다.

팀들은 그렇게 하고 싶은 유혹을 느낍니다. 특히 스프린트 플래닝 동안 준비되었음의 정의를 사용하고, 보드위에 스토리에 디테일을 추가하는 팀들에게 그렇습니다. 이런 팀들은 그들이 스토리에 대해 알 필요가 있는 모든 것들에 대해 생각하려고 하면서 방해를 받습니다. 

이런 수준의 정확성은 종종 필요하지 않으며 어떤 경우에는 더 많은 재작업을 하게 만듭니다.
 

기억할 점

팀원이 "우리는 모든 디테일을 알기 전까지 시작할 수 없어요"라고 말하면 어떻게 해야 할까요?

그들에게 동의하지만 약간 다르게 동의합니다.

"네, 우리는 그 디테일들을 알아야 합니다. 그러나 우리는 일을 시작하기 전에 그 답이 정말 있어야 할까요?"라고 이야기 합시다.

시작하기 전에 어떤 디테일들이 필요한지 묻는 것은 팀이 애자일로 성공하게 합니다.

Mike