Choosing between story points and ideal days

규모 추정에는 스토리 점수와 이상적 작업일이라는 두 수단이 있다. 각각 나름의 장단점이 있는데, 어떻게 활용하는 것이 좋은지에 대해 얘기해본다.

스토리 점수의 장점

• 스토리 점수는 팀원들로 하여금 기능간 경계를 뛰어 넘게 한다.
• 스토리 점수를 사용한 추정치는 시간이 지나도 유효성을 잃지 않는다.
• 스토리 점수는 규모를 측정하기 위한 순수 척도이다.
• 스토리 점수를 사용해 추정하는 편이 더 빠르다.
• 사람마다 이상적 작업일의 정의는 다를 수 있다.

스토리 점수는 팀원들로 하여금 기능 간 경계를 뛰어 넘게 한다.

• 구현을 신경쓰지 않고, 다른 스토리 점수에 비해 어느정도의 크기를 갖느냐에 대한 답을 하는 것이기 때문에
• 다양한 것들을 고려하여 추정치를 이야기 할 수 있다.
• 즉, 내 부분에 대한 구현을 고려하여 말하는 것이 아니고, 전체적으로 바라본 결과를 말한다는 것이다.

스토리 점수를 사용한 추정치는 시간이 지나도 유효성을 잃지 않는다.

• 이상적 작업일을 사용한 추정치보다 신선도가 오래간다.
• 이는 실제 구현을 기반으로 책정한 수치가 아닌, 상대적 수치로 매겼기 대문이다.
• 실제 구현에는 언어, 도메인, 기술, 이해도, 숙련도와 같은 다양한 변수가 존재한다.
• 그렇기 때문에 사람에 따라 다른 이상적 작업일을 내놓을 수 있다.
• 하지만 스토리 점수는 그러한 외적인 변수를 생각하지 않은 척도이기 때문에, 변동이 적다.
• 노력의 규모(외적 의존도가 있었던 특정 프레임워크의 구현 진행도)가 달라졌다면 스토리 점수건 이상적 작업일이건 추정치는 수정되어야 한다.
• 하지만, 이상적 작업일의 경우 팀의 능력 개선에도 영향을 받는다.

스토리 점수는 규모를 측정하기 위한 순서 척도이다.

• 구현 전에 가장 중요한 것은 일의 규모를 산정하는 것이다.
• 스토리 점수는 그 규모를 재는 순수 척도다.
• 이상적 작업일은 개발자의 숙련도에 따라 변경되는 단위이다.
• 스토리 포인트를 사용하면 실제 상황과 추정치를 비교해 보려는 충동을 잘 느끼지 못한다.
• 개발자들은 이걸 어떻게 구현할 지에 대해 생각하게 되는 습관이 있는데,
• 스토리 포인트를 사용하면 특정 스토리 포인트간의 상대적 비교를 하기 때문에 문제가 없다.

스토리 점수를 사용해 추정하는 편이 더 빠르다.

• 어떻게 보면 스토리 점수는 특정 구현의 정도를 대강? 살펴보는 개념에 가깝다.
• 하지만 이상적 작업일을 기준으로 살펴볼 경우, 조금더 구현에 대한 얘기를 많이 하게 되면서 오랜 시간이 걸리는 경향이 있다.

사람마다 이상적 작업일의 정의는 다를 수 있다.

• 앞에서도 말한 내용이다.
• 이상적 작업일은 특정 사람의 숙련도에 따라 달라진다.

이상적 작업일의 장점

• 이상적 작업일을 사용하면 개발팀 외부에 설명하기가 좋다.
• 맨 처음에 추정할 때에는 이상적 작업일 쪽이 더 쉽고 편하다.

이상적 작업일을 사용하면 개발팀 외부에 설명하기가 좋다.

• 일단 작업일이 때문에 굉장히 직관적이다.
• “내가 개발에 올인하면 이정도 걸린다” 라는 말이기 때문이다.

맨 처음에 추정할 때에는 이상적 작업일 쪽이 더 쉽고 편하다.

• 초기에는 그리고 이게 더 쉬울 수 있다.
• 구현쪽으로 아무래도 머리가 굴러가다보니, 이렇게 책정하는 것이 더 쉽다.
• 하지만 처음에는 스토리 포인트로 하는 게 어렵겠지만 하다보면 금방 적응된다.

요약

• 추정을 할 때는 스토리 점수를 사용할 것인지 이상적 작업일을 사용할 것인지 결정해야 한다.
• 스토리 점수는 탈 기능적인 자세를 가지도록 돕는다.
• 또 순수 척도이며, 숙련도 상승에 따라 추정치가 변화하지 않아 더 빨리 추정할 수 있다.
• 이상적 작업일은 팀 외부 사람에 설명하기 좋다.
• 그리고 초기에는 좀더 편하게 작업할 수 있다.
• 스토리 점수를 조금더 추천한다.

토론거리

• 스토리 점수와 이상적 작업일 중 어느쪽을 선호하는가?
  • 장기적으로 특정 일에 대한 추정치가 필요하다고 생각하면 스토리 점수,
  • 단기적으로 처리된다면 이상적 작업일을 선택할 것 같다.
• 이 내용을 조직에 적용하려면 어떻게 해야 할까?
  • 규모가 큰 팀일 수록 이런 모든 내용을 이해시키는 것은 쉽지 않을 것 같다.
  • 내부적으로 사용한 후 점점 넓혀가는 전략을 사용해야 할 것 같다.

Reference

• 불확실성과 화해하는 프로젝트 추정과 계획
• Agile Estimating and Planning