ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 스토리 포인트, 어떤가요?
    함께 일하기/애자일 스크럼 2024. 1. 25. 22:56

    이 글은 팀에 스토리 포인트를 도입하기 위해 제가 쓰고 공유했던 내용입니다.
    전반적인 내용은 제가 스토리 포인트를 왜 사용해보고 싶은지에 대한 것입니다. (제가 있는 팀 상황에 대한 내용이 조금 있습니다.)

     

    저는 프론트엔드 개발자로 약 2년 정도 근무한 아직은 늅늅 개발자입니다.

     

    저희 조직은 애자일 방법론의 대표적인 스크럼을 이용해 업무를 진행합니다.
    새로운 팀에서 어떻게 하면 더 나은 프로세스로 일할 수 있을지를 고민 하던 중 아래의 문서를 읽게 되었습니다.

     

    👉👉 사용자 스토리 포인트로 스마트하게 프로젝트 진행하기(feat. LINE Pay 개발 팀)

     

    스토리 포인트에 대해 알기 쉽게 쓰여 있습니다. 스토리 포인트에 대해서 잘 모르시는 분들은 꼭 읽어주세요. 매우 좋은 글이었습니다.😊

     

    또한 애자일, 스크럼, 스프린트 등에 대해서 알고 있어야 합니다. 해당 개념에 대해서는 아래 문서를 읽어주세요.
    👉 스크럼_(애자일_개발_프로세스)


    우리팀은 어떻게 일하고 있는가?

    우리팀의 플래닝 방식

    우리팀은 2주의 스프린트 동안 워킹데이 10일 기준 80시간에 맞춰 일을 계획합니다. 개발 요구사항 스토리에 대해서 기획분들이 리뷰 해주시고, 개발자들은 기획을 토대로 2주 간 해야할 일을 모두 태스크(task)로 만들어 시간을 매깁니다. 계획이 끝나고 80시간이 넘는 사람의 업무는 80시간이 넘지 않는 사람에게 재분배 됩니다.

     

    스토리 포인트?

    내가 가졌던 의문

    제가 신입 시절에 처음으로 스프린트 플래닝에 참여 했을 때 들었던 생각은 ‘이 일이 정말 이 시간 안에 끝나는 일이 맞아?’ 였습니다. 뉴비에게 기능 완료일을 가늠하는 것은 쉬운 일이 아니었습니다.😭😭 일에 대한 사전 지식이 없었고(특히 제품 도메인), 아직 코드도 많이 이해하지 못했을 때라 그 때를 생각하면 정말 플래닝 시간은 좌불안석이었던 것 같습니다.

    스프린트라는 프로세스에 익숙해졌을 때에도 태스크를 모두 만들고 시간을 매기는 플래닝에 항상 의문이 들었습니다.

    • 일을 진행하다보면 태스크가 도출되는 경우가 많이 있는데, 하루만에 추가할 일이 모두 만드는게 가능한건가..?
    • 나는 여전히 태스크 완료 시간을 가늠하는게 힘든데 경험이 부족해서 일까? 아니면 일을 완수 하지 못할 것 같다는 두려움 때문인가?
    • 스크럼에서 이야기하고 있는 “놀고 있는 일”이 아닌 “놀고 있는 사람”에게 집중해 플래닝 하고 있는 것이 아닌가?

     

    그래서 저는 팀원들에게 질문해보았습니다.

    여러분들이 계획한 80시간(이상/이하로)의 태스크를 모두 지켰던 스프린트는 얼마나 있었나요?

     

    부끄럽게도 저는 많은 스프린트에서 계획한 일을 끝내지 못했던 적이 많습니다.
    그렇다면 저는 왜 계획을 달성하지 못했을까요? 능력이 없어서? 게을러서? 외부 업무가 많아서?


    저는 이렇게 생각했습니다.

    불확실성을 너무 상세하게 계획했기 때문에

     

    우리의 스프린트는 불확실합니다.

    A님은 VoC(Voice of Customer) 업무로 계획했던 일을 하지 못하고, B님은 갑자기 생겨난 회의로 인해 계획했던 업무를 진행하지 못했습니다. C님은 기획, 디자인 변경으로 인해 개발을 새로 시작해야 합니다. 하루를 온전히 본인의 계획에 쓸 수 있는 사람은 그리 많지 않습니다.

     

    아침에 몸이 아파 출근을 못할 수도, 점심 식사가 체해서 오후 업무에 집중하지 못할 수도, 동료가 커피 타임을 요청해 잠깐 휴식을 취하러 갈 수도 있습니다. 신이 아닌 이상 오늘 일어날 모든 일을 예측할 수 없습니다.

     

    그래서 저는 불확실성에서 모든 태스크를 뽑고 모든 태스크의 시간을 산정하는 것은 지키기 어려운 계획이라고 생각합니다. 스프린트의 목표를 달성하기 어려운 것은 불확실성을 고려하지 못했기 때문이라 생각했습니다.

     

    작년에 다른 팀에서 진행한 애자일 스크럼 스터디에 참여했었습니다. 타임박스스토리 포인트 에서 많은 인사이트를 얻을 수 있었는데요. 제가 팀에 스토리 포인트를 제안한 이유는 우리는 애자일 스크럼을 하고 있다고 말할 수 있는지, 초심을 되돌아보는 계기를 삼고 싶었기 때문입니다. 스토리 포인트를 사용해보면서 우리의 플래닝 프로세스를 조금이라도 개선할 수 있을 것이라 생각한 점도 있고요.

    👉 프로젝트 관리 기법 - 타임박싱(Timeboxing) 관리 기법

     

    내 생각의 핵심

    시간이 아닌 일의 크기에 집중하며,
    불확실성에 대비하기 위해 너무 상세하게 추정하지 않고 대략적으로 추정한다.

     

    가장 처음에 언급했던 스토리 포인트 문서에는 아래와 같은 예시가 적혀있습니다. 저는 스토리 포인트를 가장 쉽게 이해할 수 있는 핵심이라고 생각합니다.

    서울과 부산까지의 직선거리는 약 325.5km입니다. 서울에서 부산까지 이동하는 데 걸리는 시간은 이동 수단에 따라 다릅니다. 자동차로는 약 5시간, 기차로는 약 2시간 40분, 비행기로는 약 1시간 걸립니다.(MD) 이동 수단에 따라 걸리는 시간은 다르지만 서울에서 부산까지의 직선거리는 여전히 변하지 않는 325.5km입니다.(스토리포인트)

     

    일의 본질에만 집중해 일의 크기로 측정하는 것이 핵심입니다.

    제가 생각하는 스토리 포인트를 써서 얻는 이점은 다음과 같습니다.

    • 속도를 측정할 수 있다.
      • 이번 달에 100의 일을 해결했고 다음달에 120의 일을 해결했다면, 일을 해결하는 속도가 증가하고 있는 것
    • 우리가 얼마만큼의 일을 해결할 수 있는 팀인지 측정이 가능하다.
      • 이번 달 150의 일을 계획했는데, 100의 일만 완료했다. -> 우리 팀이 한 스프린트에 해결하기엔 너무 큰, 많은 요구사항이었다.
    • 불확실한 태스크들에 대해서 어느정도 대비할 수 있다.
      • 모든 태스크에 시간을 쓰지 않아도 되니, 갑자기 생기는 회의로 인해 다른 태스크 업무 시간을 뺏긴다는 강박관념이 줄어든다(?) 유연한 대처가 가능해진다.

     

    하지만, 현실적으로

    스토리 포인트를 사용하기엔 우리 팀이 처한 상황은 그렇게 좋은 편이 아니었습니다.

    • 데드라인이 촉박함
    • 긴급한 VoC 가 많음
    • 회사 적으로도 조직이 자주 바뀜 (저희 팀도 일단 TF 라는 이름을 달고 있어 언제 사라질지 모름..)
    • 이미 기존 분들이 스토리 포인트에 대해서 목소리를 내보았지만, 다른 사람들의 공감을 잘 얻지 못함

     

    그래서 내놓은 절충안

    이미 시간 기반 플래닝이 완료된 상황이니, 플래닝 완료된 작업에 스토리 포인트를 한번 매겨보기
    이번 스프린트가 끝날 때, 얼마나 스토리 포인트를 완료했는지 속도 측정의 용도로 삼아보기

    • 다음 스프린트에서도 기존 방식처럼 시간으로 계획하고, 스토리 포인트도 사용해 일의 크기를 추정해본다. 그리고 플래닝 한 태스크들이 이전 스프린트에서 완료한 스토리 포인트와 비교해서 적절하게 계획이 되었는지 확인해 보는 방식으로 시간과 스토리포인트를 당분간 병행해서 사용해본다.
    • 2~3 스프린트 정도 진행해보며 스토리 포인트가 우리에게 정말 효율성을 줄 수 있다면 채택을 고려해본다. 스토리 포인트가 적절하지 않다고 느낀다면, 스토리에 MD(Man - Day) 개념으로 대략적인 추정하는 방식을 제안했다.

     

    여러 설득 끝에 팀의 속도를 추정하기 위한 지표로써 스토리 포인트를 사용해보기로 했습니다🎉

    앞서 내놓은 절충안대로 시간으로 하는 플래닝도 함께 할 것 같습니다. 후에 스토리 포인트를 사용해서 팀이 어떤 인사이트를 얻었는지 공유하는 기회를 가져보도록 하겠습니다.

     

    결론

    팀원 한 분이 자기도 프로세스 개선을 위해 저와 같은 의견을 내보았지만, 번번히 묻히게 되어 더 이상 의견 내지 않았다고 하셨습니다.
    그렇다면 제가 이렇게 목소리를 꺼내는 것도 의미가 없는 일일까요? 아니요. 그렇지 않습니다.
    저는 제 의견이 받아들여지지 않더라도, 스스로 의의를 부여했습니다. 우리가 애자일하게 일하고 있는지를 되돌아보는 계기를 가져보고 팀원들에게 환기했다고 생각했습니다.

    좋은 프로세스라고 무조건 좋은 것은 아닙니다.

     

    스토리 포인트를 이용한 플래닝이 어울리는 팀이 있으면 그렇지 않은 팀도 존재합니다. 본인의 팀의 성향과 어울리는 방법을 찾아야 합니다.

    찾아낸 프로세스를 도입하기 위해서 가장 필요한 것은 공감입니다. 일단 제안해보세요. 필요성에 대한 공감을 얻기 위해 글을 써보아도 좋고, 발표를 해 보아도 좋습니다.
    받아들여지지 않더라도 좌절할 필요 없습니다. 스스로 의의를 부여해보는 것도 좋고 팀에 목소리를 내보았다는 것만으로도 충분한 경험이 될 것입니다. 좋은 팀을 만들기 위해 노력할 여러분들을 응원합니다.😘

     

     

    참고한 글들

    협업에 관한 수다: 스크럼과 스프린트

    “솔직히 우리가 하는 것은 스크럼이 아닙니다!” | 요즘IT

Designed by Tistory.