스토리 포인트
From: 개발자에게 물어보세요
짐작하다시피 소프트웨어의 기능을 구현하는 데 필요한 작업량 을 정확히 예측하는 것은 하나의 기술art이며, 우리는 애자일 실천법을 이용해 이를 과학으로 바꾸고자 한다. 여기엔 팀의 노력이 필요하다. 처음 팀이 구성될 때는 자신들의 생산성을 정확히 예측하지 못하는 경우가 많다. 대개 코드베이스(기존 프로젝트인 경우)나 문제 영역(새 프로젝트인 경우)에 대한 지식이 부족해서 역량을 발휘하는 데 필요한 작업 추정치를 잘못 계산한다. 하지만 시간이 지나면서 코드베이스 관련 전문성과 문제 영역을 다루는 지식이 증가하고 더불어 정확도도 높아진다.
팀은 '스토리 포인트story points'와 같은 추정 지표를 이용해 스프린트의 예측 가능성과 생산성을 측정하고 지속적으로 개선하기도 한다. 이 지표는 특정 기능을 구현하는 데 드는 작업량뿐 아니라, 팀이 한 스프린트 내에서 성취할 수 있는 업무량을 설명해 준다. 스토리 포인트를 통해 작업 비용과 생산성을 점점 더 정확하게 예측 할 수 있게 되면 팀 작업에 대한 예측 가능성도 높아진다. 일단 기준선을 정하고 나면, 효율성과 생산성을 높이기 위해 한 스프린트 내에서 더 많은 스토리 포인트를 얻는 데 집중할 수 있다.
주의할 건 스토리 포인트는 추정치이므로(코드를 몇 줄 작성했는지와 같은 명백한 지표를 토대로 한 게 아니다) 다른 회사나 팀이 그대로 가져다 쓸 수 없다(여담으로 하는 말이지만, 코드 라인 수를 지표로 삼는 건 최악이니, 절대 관심 갖지 말길 바란다. 코드란 적을수록 좋은 것이다). 외부인으로서 리더인 당신은 스토리 포인트 지표가 팀에 예측 가능성과 생산성을 높여 주는지 그렇지 않은지만 신경 쓰면 된다.
왜 한 팀은 100 스토리 포인트를 달성했는데, 다른 팀은 50밖에 못 했는지 굳이 묻지 말라. 스토리 포인트의 점수 기준을 똑같이 정의하지 않은 이상(이런 일은 드물다) 둘은 비교가 불가하다. 하지만 시간이 지나면서 각 팀이 스토리 포인트를 기준으로 생산성이 향상되는지 살펴보아야 한다. 만약 팀이 1년 전에 스프린트당 평균 100 스토리 포인트를 달성했는데 지금은 평균 150이라면, 효율성이 50퍼센트 더 높아진 것이므로 팀으로서 좋은 징조다. 1
- 스토리 포인트는 팀 생산성 측정 지표 중 하나.
- 객관적인 지표라고 착각하지 말 것.
- 꾸준히 기록해가면서 과거에 비해 생산성이 향상되는지 살펴봐야 바람직하다.
- 주의: 스프린트를 지속하면서 회고도 하고 기록은 계속 남기는데, 과거 기록이랑 현재를 비교하지 않는 경우가 꽤 많다.
팀이 네다섯 개의 시간대에서 벗어나지 않도록 하는 게 좋다. 대부분의 팀이 스토리 포인트를 이용해 작업에 생산성 지표를 부여하고 시간이 흐를수록 생산성이 향상되는지 추적한다. 팀마다 스토리 포인트를 다르게 정의하지만 상관없다. 이 관행은 많은 애자일 팀의 작업 흐름 중 일부이며, 나는 그게 마음에 든다. 영업사원이 영업을 마치고 나서 생산성을 측정하는 것과 마찬가지로, 엔지니어링 팀의 건전성을 측정하는 것도 중요하다. 2
참고문헌
- 개발자에게 물어보세요 / 제프 로슨 저/박설영 역 / 인사이트(insight) / 초판 1쇄 발행 2023년 03월 27일 / 원제: Ask Your Developer