애자일 Story point 의 의미

애자일 개발 방법론에 보면 Story Point 라는 것이 있다.
이 점수의 의미에 대해서 한번 생각해보자!

소프트웨어 개발을 하기 위해서는 요구사항을 분석하고 작업목록을 추출해야 한다.
그리고 그 작업내역 각각의 작업량을 추정해야하는데 이 작업량 추정에 Story Point 가 사용된다.

우리는 보통 작업량을 추정할 때 일(Day)을 단위로 사용하여 추정하게 된다.
즉, '이 작업은 몇 일 걸릴 일이다' 라고 추정하는 것이다. 근데 이것은 문제가 존재한다.
예를 들어보면 A라는 작업은 하루 8시간씩 2일동안 작업해야만 끝낼 수 있는 작업이다.
그리고 B라는 업무는 오전에 4시간 작업하고 나머지 4시간은 기다리는 식으로 2일동안 작업해야 한다고 했을 때 A 작업과 B 작업을 모두 2일로 추정한다면 문제가 있다.
왜냐하면 B 작업을 할 때는 오후에 다른 작업을 할 수 있기 때문이다.

즉, 일(Day) 단위로 작업량을 추정하게 되면 B작업의 경우는 오후의 남는 시간이 가려지는 문제가 발생하여 작업량이 과하게 추정되는 문제가 발생한다.
그래서 등장한 것이 Story Point 이다.

Story Point 는 노력(Effort)의 단위라고 생각하면 편할 것이다.
다시말하면 이 작업을 처리하는데 있어서 어떤 방해도 받지않고 한사람이 이 작업만 하루 8시간씩 할 경우 몇 일이 걸리는지 추정하는 것이 Story Point 라고 일단 생각하면 될 것이다.

그래서 위에 얘기했던 A 작업은 Story point 가 2 이고 B는 1이 되는 것이다.

이제 우리는 Story point 를 통해서 작업량을 정확히 추정할 수 있다.
A 작업과 B 작업을 마치는데는 Working day 3일이 필요하다고 추정할 수 있다.
그리고 일정계획을 세운다면 A 작업은 월화수 3일의 기간이 필요하고, B는 월화 2일의 기간이 필요한 것으로 계획을 세울 수 있다.

결국 A 작업은 Working day 3일이 필요하고, B 작업은 Working day 2일이 필요한 작업이 된 것이다. 물론 이 예는 한사람이 작업할 경우를 가정하여 세운 일정계획이다.

이렇게 Story point 는 노력(Effort)의 량이라는 개념으로 작업의 정확한 일정계획을 세울 수 있도록 도와준다.

그리고 또 한가지 Story point 가 가지고 있는 기능은 사람마다 또는 팀마다의 작업량 추정치의 차이를 극복하게 만들어 준다는 것이다.

예를들어서 작업이 A 작업 밖에는 존재하는 않는다는 가정에서 개똥이는 위의 예처럼 A라는 작업의 노력(Effort)를 2 Story point로 추정했다.
근데 소똥이는 A라는 작업의 노력(Effort)를 4 Story point 로 추정한 것이다.
그리고 둘은 모두 정직한 개발자이기 때문에 모두 Working day 2일만에 작업을 모두 끝냈다.

그렇다면 개똥이는 Story point 를 정확히 추정했으니 훌륭한 개발자이고, 소똥이는 2배나 잘못 추정했으니 나쁜 개발자일까?
그렇지않다. Story point 의 단위가 일(Day)이 아니라 노력(Effort)이기 때문에 둘다 훌륭한 개발자이다.
Story point 를 정할 때 우리는 익숙하기 때문에 일(Day)로 노력(Effort)의 단위를 추정한 것이지 엄밀히 따지면 일(Day) 과 노력(Effort)은 1:1 일 필요는 없다.
사람마다 경험이 다 다르기 때문에 당연히 작업량 추정도 다 다르게 할 수 밖에 없기 때문이다.
그래서 개똥이는 일(Day)과 노력(Effort)이 1:1 인 개발자이고, 소똥이는 일(Day)과 노력(Effort)이 1:2 인 개발자인 것이다. 누가 맞고 틀리고가 없는 것이다.
이것을 Story point 의 속도(Velocity)라고 한다.

그래서 애자일에서는 Sprint 를 진행하면서 그 팀의 Story point velocity 를 측정하여 다음번 Sprint 에는 그 Velocity 에 맞는 총점의 Story point 들을 선정하고 작업을 진행하는 것이다.
그러므로 어느 팀이 Velocity 가 높으냐 낮으냐는 아무런 의미가 없고,  매 Sprint 마다 Velocity 가 일정한 팀은 작업량 추정을 잘하고 있다고 할 수 있고, 매 Sprint 마다 Velocity 가 들쭉 날쭉한 팀은 작업량 추정을 잘못하고 있다고 볼 수 있는 것이다.

만약 자신의 팀이 Velocity 가 들쭉 날쭉하다면 작업량 추정방법에 대해서 좀 더 고민하는 팀장이 되어야 할 것이다.