프로젝트의 스토리 포인트를 추정하는 방법은 무엇입니까?

애자일 방법론을 사용하는 프로젝트에서 팀은 다음 스프린트의 작업 계획을 위해 사용자 스토리를 작성합니다. 사용자 스토리는 특정 기능 활동을 설명하고, 이에 대한 승인 기준을 포함합니다.

스프린트는 통상 2주에서 4주간 진행됩니다. 이 기간 동안 팀은 주어진 스프린트 내에서 완료할 수 있는 작업량을 파악해야 합니다. 이는 제한된 스프린트 시간 내에 지속적으로 개발을 진행하기 위한 필수적인 과정입니다.

애자일 방식이 아닌 기존 프로젝트에서는 작업 시간을 투입 인원수를 기준으로 추정합니다. 예를 들어, 특정 작업을 완료하는 데 몇 명의 정규 인력이 필요한지 계산합니다. 이러한 경우, 견적을 산정할 때 일정 기간과 투입 인원수를 고려하게 됩니다.

그러나 애자일 프로젝트에서는 상황이 다릅니다. 더 이상 최종 견적을 계산하기 위해 일정이나 투입 인원수를 고려하지 않습니다. 실제로, 우리는 작업량을 인시(man-days)와 같은 단위로 측정하는 것을 지양합니다. 대신, 팀이 전체적인 추정치를 나타내는 사용자 스토리에 대한 보편적으로 인정되는 값으로 변환하도록 합니다.

여기서 중요한 것은 값의 정확한 정의가 아닙니다. 사용자 스토리 추정에서 가장 일반적인 방법은 스토리 포인트를 사용하는 것입니다. 이는 일반적으로 0, 1, 2, 3, 5, 8, 13, 21 등의 피보나치 수열을 따릅니다. 각 숫자는 이전 두 숫자의 합으로 결정됩니다. 다음 숫자가 이전 숫자보다 훨씬 크기 때문에 스토리의 전반적인 복잡성을 구분하는 데 효과적입니다.

하지만 스토리 포인트에만 매달릴 필요는 없습니다. 티셔츠 사이즈(XXS, XS, S, M, L, XL, XXL)를 사용할 수도 있습니다. 좀 더 창의적인 접근을 원한다면 동물원 동물들을 도입하여 크기 추정에 활용할 수도 있습니다.

중요한 점은 어떤 숫자(또는 동물)를 사용하든, 이는 특정 스토리의 전체적인 복잡성에 대한 팀 전체의 느낌을 가장 잘 나타내야 한다는 것입니다. 이는 시간과는 관련이 없습니다. 궁극적으로 팀은 스프린트 내에서 스프린트에 포함된 각 스토리를 완료해야 하며, 시간은 이미 주어져 있고 고정되어 있습니다.

스토리 포인트 추정의 구성 요소

스토리 포인트 추정은 단순히 특정 스토리가 얼마나 어렵고 복잡한지를 나타내는 것이 아닙니다. 스토리를 추정할 때 팀은 여러 측면을 고려하고 이러한 요소들을 최종 추정값에 반영해야 합니다.

최종 추정값은 다양한 측면을 종합적으로 고려한 결과를 하나의 숫자로 표현한 것입니다. 다음은 스토리 추정에 고려해야 할 주요 요소들입니다.

#1. 기술적 난이도

개발팀을 위한 스토리 추정 시, 기술적 난이도는 팀이 가장 먼저 고려해야 할 핵심 요소 중 하나입니다.

이는 매우 합리적인 접근입니다. 기술 전문가로 구성된 팀은 이러한 영역을 평가하는 데 가장 적합한 지식을 가지고 있습니다. 팀은 다음과 같은 다양한 접근 방식과 힌트를 참고할 수 있습니다.

• 기술적 복잡성 측면에서 이 스토리는 이미 처리된 다른 스토리와 어떻게 비교되는가?
• 이 스토리를 완료하기 위해 팀이 생성하거나 업데이트해야 할 코드 파일은 몇 개인가?
• 이 스토리는 주변 시스템 프로세스에 얼마나 많은 추가 코드 변경을 야기하는가?
• 알고리즘 또는 프로세스 로직을 구현하는 데 얼마나 복잡한가?

#2. 외부 종속성 및 위험

놀랍게도, 팀 스프린트 내 스토리의 성공은 다른 팀이나 팀 외부 사람들의 기여에 영향을 받을 수 있습니다.

팀 자체적으로 처리할 수 있는 작업은 예측하기가 비교적 쉽습니다. 하지만 스토리에 외부 도움이 필요한 경우 상황은 복잡해집니다. 팀 외부 사람들에게는 해당 작업이 우선순위가 아닐 수 있기 때문입니다. 팀은 이러한 요소들을 고려하여 추정치에 반영해야 합니다.

이 요소가 총 추정치를 얼마나 높일지는 주로 팀의 이전 경험과 "외부 종속성의 수준"에 따라 달라집니다. 일반적으로 팀은 여러 스프린트 경험을 통해 외부 종속성이 스토리 완료를 얼마나 복잡하게 만들 수 있는지에 대한 직관적인 감각을 갖게 됩니다.

#3. 재사용성 요소

다음으로 고려해야 할 요소는 스토리를 완료하기 위해 팀이 재사용할 수 있는 기존 콘텐츠의 양입니다. 이미 존재하는 요소가 있다면 처음부터 새로 만들 필요가 없습니다. 팀은 이미 만들어진 솔루션을 재사용하여 새로운 솔루션을 훨씬 빠르게 구축할 수 있습니다.

이러한 재사용성은 일반적으로 스토리가 더 복잡해 보이더라도 전체 추정치를 낮출 수 있습니다. 이는 재사용 가능한 요소가 없는 경우를 기준으로 했을 때 복잡도가 높아지기 때문입니다.

#4. 팀 자체에 대한 이해

인건비 기반 추정 방식에서는 고려하기 어려운 중요한 요소는 팀의 경력과 역량에 대한 자기 인식입니다.

팀이 함께 일하고 여러 스프린트를 진행하면서 팀원들은 서로를 더 잘 알게 됩니다. 누가 무엇을 잘하고, 어떤 역량을 갖고 있는지 파악하게 됩니다. 팀 전체가 서로를 잘 알게 되면 추정 과정에서 이를 고려할 수 있습니다.

만약 스토리가 특정 기술에 크게 의존하고, 해당 기술이 팀 내부에 강하게 존재한다면, 스토리 구현은 상대적으로 수월할 것입니다. 반대로, 팀 내에 필요한 기술이 부족하다면, 팀은 해당 스토리를 이해하고 작업하는 데 더 많은 시간을 필요로 할 수 있으며, 이는 추정치에 반영되어야 합니다.

스토리 추정

각 스토리 추정은 팀 전체의 협력적인 노력이 되어야 합니다. 특정 개인의 의견이 스토리의 복잡성을 결정해서는 안 됩니다. 목표는 모든 팀원이 최종 추정치를 나타내는 단일 값에 동의할 때까지 팀 내에서 추정치에 대해 논의하는 것입니다.

팀은 스프린트 검토 회의(스토리가 논의되고 명확해지는 회의) 중에 직접 추정을 수행하거나, 이를 위한 별도의 시간을 할애할 수 있습니다.

추정 과정 예시

• 팀에서 사용할 추정 도구를 선택합니다. 예: Planning Poker, Miro 보드 등.
• 칠판이나 화면에 스토리를 표시합니다. 팀이 스토리에 대한 생각이나 질문을 자유롭게 논의하도록 합니다. 전체 팀이 스토리를 완전히 이해하고 평가할 준비가 되었는지 확인합니다.
• 추정을 시작합니다. 각 팀원은 피보나치 척도에서 숫자를 선택합니다.
• 모든 팀원의 추정이 완료되면 결과를 함께 검토합니다. 토론을 시작합니다. 일반적으로 팀은 2~3개의 숫자를 제시합니다. 추정치가 낮은 팀원에게는 왜 추정치가 낮아야 하는지 설명하도록 하고, 추정치가 높은 팀원에게는 왜 높은 추정치가 필요한지 설명하도록 합니다. 목표는 전체 팀이 스토리의 내용에 대해 동일한 이해를 갖도록 모든 주장, 고려 사항 및 사실을 논의하는 것입니다.
• 토론이 끝나면 팀이 다시 추정하도록 합니다. 대부분의 경우 팀은 이제 하나 또는 두 개의 숫자로 수렴합니다. 토론을 다시 반복합니다. 상황에 따라 팀이 두 가지 대안 중 하나에 합의하거나 추가 추정 단계를 진행할 수 있습니다.
• 최종 견적은 모든 팀원이 동의하는 경우에만 완료됩니다. 이는 소수의 의견이 아닌 팀 전체의 합의여야 합니다. 모든 스토리는 나중에 팀원에게 할당될 수 있으므로 모든 팀원이 스토리의 복잡성에 대해 동의하는 것이 중요합니다.

스프린트 계획 약정

이제 팀은 이미 평가 과정을 거친 스토리가 포함된 백로그를 확보하게 되었습니다. 이상적으로, 팀은 다음 스프린트에 어떤 스토리를 포함할지 알 수 있도록 스토리에 우선순위가 부여되어야 합니다(최종 추정 값은 별도로 고려합니다).

다음 스프린트에 포함할 스토리를 선택하는 계획 회의가 시작됩니다. 스토리를 선택하는 기준은 다음과 같습니다.

✅ 팀이 가장 먼저 고려해야 할 최우선 순위의 스토리.

✅ 스프린트 내에서 완료할 수 있는 스토리 포인트에 대한 팀의 경험. 이 지식은 팀의 시간과 경험을 통해 얻을 수 있습니다. 이 능력을 미세 조정하고 제대로 이해하는 데 몇 번의 스프린트가 필요할 수 있습니다.

✅ 총 스토리 포인트 수와 우선순위만 고려해서는 안 됩니다. 또한 팀 내부의 기술이 선택한 스토리에 어떻게 분산되는지도 고려해야 합니다. 예를 들어, 팀에 프런트엔드 개발자가 두 명뿐인 경우 프런트엔드 개발 작업만으로 구성된 스토리를 선택하지 않을 수 있습니다. 그렇게 되면 두 사람에게 과부하가 걸릴 수 있고 다른 팀원들은 충분히 활용되지 않을 수 있습니다. 따라서 팀의 기술 역량은 스프린트 콘텐츠 생성의 효율성과 밀접한 관련이 있습니다.

속도 계수

가장 중요한 요소 중 하나는 팀의 속도입니다. 이는 다가오는 스프린트의 작업량을 나타냅니다. 이 값은 스토리 포인트의 총량과 직접적인 관련은 없지만 팀이 스프린트 작업에 사용할 수 있는 역량을 나타냅니다.

스프린트 콘텐츠를 정확하게 계획하기 위해 다음 두 가지 측면을 고려합니다.

• 팀 속도 – 일 단위로 측정됩니다. 팀원 한 명이 하루 동안 사용할 수 있는 작업량은 팀 속도 1과 같습니다. 예를 들어, 2주 동안 진행되는 스프린트에 완전히 사용 가능한 10명의 팀은 100명과 같습니다.
• 스프린트 내에서 완료되는 일반적인 스토리 포인트 양 – 스토리 포인트로 측정됩니다. 이 숫자는 과거 경험에서 나온 것이며 팀 속도와 밀접한 관련이 있습니다.

최적의 지점을 찾으려면 시간과 연습이 필요합니다.

이점 및 일반적인 실수

애자일 팀으로 전환하는 과정에서 팀이 프로세스를 얼마나 복잡하게 만들려고 하는지는 놀랍습니다. 마치 해당 모드로 작업을 시작하기 전에 모든 것을 완벽히 이해해야 한다고 생각하는 것처럼 느껴집니다.

불행히도, 이 첫 번째 단계는 가장 어려운 단계이기도 합니다. 보수적인 기업 문화에서는 특히 몇 년이 걸릴 수 있습니다.

어쨌든 팀이 프로세스를 "이해"하게 되면 다음과 같은 긍정적인 변화가 일어납니다.

• 작업 완료 시점을 예측하기 위해 더 이상 투입 인원수나 날짜를 계산할 필요가 없습니다.
• 팀은 스토리를 스프린트에 맞게, 즉 복잡한 만큼만 만들 수 있습니다. 스토리가 너무 복잡하면 자동으로 더 작은 스토리로 분할됩니다.
• 팀은 각 작업에 대한 적절한 추정치를 가지게 되며, 스프린트 계획을 세우면 마감일을 정확히 알 수 있습니다.
• 팀의 신뢰성과 예측 가능성이 향상됩니다.
• 팀원들은 "같은 주파수"로 소통할 수 있게 됩니다. 스토리를 보면 비슷한 이해를 갖게 됩니다. 시간이 지나면 추정 과정 없이도 머릿속으로 스토리의 복잡도를 파악하고 스프린트에 포함할 수 있게 될 것입니다.

다음은 팀이 프로세스나 작업 방식을 이해하지 못할 때 흔히 발생하는 오류입니다.

• 여전히 구식 인건비 추정 방식에 매달립니다. 모든 것을 날짜나 관련된 인원수로 변환하려고 합니다. 스토리 포인트나 피보나치 수를 일수와 직간접적으로 연결시키려고 합니다.
• 리더십은 각 스프린트에서 완료한 스토리 포인트 수를 기준으로 팀을 비교합니다. 이는 매우 잘못된 접근입니다. 각 팀은 스토리 포인트를 다르게 추정한다는 점을 이해해야 합니다. 두 팀이 같은 방식으로 스토리를 추정하도록 동기화하려는 시도는 의미가 없습니다.
  • 한 팀의 스토리 포인트는 원을 그리는 것을 의미할 수 있지만, 다른 팀에게는 지붕이 평평하고, 창문 네 개, 문 두 개가 있는 집을 그리는 것을 의미할 수 있습니다. 이는 완전히 정상적인 일입니다.
• 때로는 팀이 2~4개의 숫자 사이에서 모든 것을 추정하려는 경향이 있습니다. 숫자 123이 등장하는 것을 두려워하여 일수를 떠올리기 때문입니다. 그러나 피보나치 수열에는 무한한 숫자가 있습니다. 3, 5, 8에만 국한할 필요는 없습니다. 더 복잡한 스토리에는 더 높은 숫자를 사용할 수 있습니다.
• 추정 과정은 팀 전체의 기대를 미리 설정하는 고위 관리자가 주도해서는 안 됩니다. 특정 팀원이 추정에 영향을 미치도록 해서는 안 됩니다. 모든 팀원은 자신의 의견을 개진하고 경청받을 동등한 권리가 있습니다.

마지막 말

전통적인 방식에서 애자일 추정 방식으로 전환하는 것은 팀과 경영진 모두에게 쉽지 않으며, 적응하는 데 시간이 걸립니다. 제대로 작동하려면 양측 모두 프로세스를 이해해야 합니다. 한쪽이라도 이해하지 못하면 전환 과정은 기대치가 충돌하는 혼란스러운 과정이 될 수 있습니다.

그러나 일단 모든 것이 제자리를 잡으면 놀라운 변화가 일어나기 시작합니다. 팀은 작업을 더 잘 예측하고 계획할 수 있게 되며, 경영진은 보다 예측 가능한 출시 일정과 로드맵을 활용할 수 있습니다.

다음으로 스프린트를 망칠 수 있는 비정상적인 프로세스를 확인해 보십시오.