Story Point 정리

참고 사이트 : LINE Pay에서 앱 개발과 서버 개발을 진행하면서 스토리 포인트를 적용하고 활용한 사례

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

서울과 부산까지의 직선거리는 약 325.5km입니다. 이 거리가 매우 길다는 것을 쉽게 인지하실 겁니다. 그 이유는 '1km'라는 기준이 얼마나 되는지 우리 모두 이미 알고 있기 때문입니다. 1km를 가는 데 얼마나 소요되는지 인식하고 있기 때문에 325.5km가 매우 멀다는 것을 쉽게 인지할 수 있습니다. 이처럼 스토리 포인트도 거리에서의 1km와 같은 기준을 잡은 뒤 그 기준과 비교해 스토리 포인트를 결정해서 각 사용자 스토리 구현의 어려움을 측정합니다.

기존 MD(Man/Day) 방식은 사람과 시간이라는 척도를 이용합니다. 브라운이 가입 사용자 스토리를 구현하기 위해 1MD가 필요하다고 추정했을 때, 코니는 기존 시스템을 잘 모르고 구현 언어도 익숙하지 않기 때문에 3MD가 필요할 수도 있습니다. 이처럼 MD는 같은 사용자 스토리라도 사람에 따라 다른 값이 도출됩니다. 프로젝트에 참여하는 사람에 따라 다른 값이 도출되기 때문에 프로젝트의 규모를 객관적인 값으로 도출하기 어렵고, 개개인에 따라 달리 스케줄링되기 때문에 예측 및 계획이 불안정합니다. 하지만 스토리 포인트에선 사용자 스토리를 구현하는 담당자가 누구든 상관없이 무조건 동일한 값으로 관리됩니다. 가입 사용자 스토리가 3 스토리 포인트라고 가정한다면, 브라운이 구현하든 코니가 구현하든 가입 사용자 스토리는 3 스토리 포인트입니다. 이런 특성 때문에 사용자 스토리와 스토리 포인트에 기반해 계획을 전략적으로 수립할 수 있습니다.

• 진정한 Story Point의 의미대로 사용하자면, 일단 Story Point를 임의로 정해두고, 스프린트 일자 기준도 정할 수 있다.

  • 가벼운 계산으로 첫 스프린트의 예상 Story Point 합을 구한다. ex) 180
  • 스프린트가 끝났을 때 회고(결과 보며 피드백) 진행하면서 획득(실제 구현)한 Story Point를 알게 된다.
    • 첫 Sprint에서 실제 구현한 Story Point의 합 : Team Velocity ex) 150
  • 이후 스프린트는 Team velocity를 기준으로 잡고 진행
    1. 이번 스프린트에서 Team Velocity보다 덜 얻었다면? ex) 120
       • Team Velocity보다 Story Point를 덜 얻은 이유는 무엇인가?
       • Team Velocity가 너무 높게 측정된 것은 아닐까, Team Velocity를 낮춰보자. ex) (150 +120) / 2 = 135
       • 135라는 값을 다음 목표 Story Points 값으로 잡고 스프린트를 진행한다.
    2. 이번 스프린트에서 Team Velocity보다 더 얻었다면? ex) 180
       • Team Velocity보다 Story Point를 더 얻은 이유는 무엇인가?
       • Team Velocity가 너무 작게 측정된 것은 아닐까, Team Velocity를 높혀보자. ex) (150+180) / 2 = 165
       • 165라는 값을 다음 목표 Story Points 값으로 잡고 스프린트를 진행한다.
    • 1과 2를 반복한다. 반복하다보면 우리 팀의 정확한 Team Velocity를 알게 되고, 향후 프로젝트 진행을 전략적으로 수행할 수 있다.

• 결론 : BurnDown Chart에서 우하향으로 모인다는 것은, **의도적으로 프로젝트를 규칙적으로 하는 것(결과론적)**이 아니라, 스프린트를 수행해 가면서 정확한 Team Velocity에 점근해가는 개념이다.

• Story Point는 팀마다 단위가 다르다. but 우리는 처음 활용하므로 개인 40개(8H * 5일)/1주의 단위로 간다.

  • 따라서 스프린트를 1주(팀 규약)로 잡으면(주말제외 5일 - jira에서 주말 포함하도록 custom 가능) 총 240개의 Story Point를 사용할 수 있게 된다.
  • Story Point보다 크거나 작은 것과 상관 없이 스프린트를 진행해가며 우리팀의 정확한 Team Velocity를 찾는 것이 목표!

• Sprint 방법

  • Backlog에서 EPICS를 누른다.

    

  • epic-name을 누르면, 그와 관련된 Story들이 올라온다.

    

  • Create sprint를 눌러 스프린트를 생성한다.

    

  • Story를 드래그하여 위로 끌어올린다.

    

  • 스토리의 링크를 누르면 오른쪽에서 내용을 바로 확인할 수 있다.

    

  • Sub-Tasks의 링크로 들어가서 Edit을 누르면 Story Points를 설정할 수 있다.

    

  • 이런식으로 Story Points를 모두 부여한다.

    • Sub-Task : 각 Sub-Task
    • Story : Story 아래 Sub-Task의 합
    • Epic : Epic 아래 Story의 합
    • Sprint를 진행하기 위해선 Sub-Task / Story의 Story Points는 무조건 작성되어야 한다.(이후 작성해도 되나, 임의로 부여하고 나중에 Team Velocity를 조정해나가는 것이 더 낫다.)

  • Start sprint를 누른다.

    

  • Sprint 이름(필수), Goal, Duration(기한, 1week, 2week, 3week, custom)을 정할 수 있다. Duration을 드롭다운 메뉴에서 적용하면 Start Date / End Date가 자동 작성된다. Start한다.

    

  • TO DO / IN PROGRESS / DONE 의 3 파트로 나뉜다. 현재 Sprint 내의 Story 1개의 Sub-Task가 To Do에 있다.

    

  • Sub-Task를 완료했다고 생각하여 Done으로 드래그하여 옮기면, Update Parent Issue가 뜬다.(Story 아래 Sub-Task가 모두 완료됐는데, Story 또한 Done으로 바꾸겠느냐?) Update한다.

    

  • Story에 취소선이 생기고 Done으로 바뀌었다. (시간이 다 되었거나, 미리 끝나거나 하였을 때)Complte sprint를 누른다.

    

  • Complete sprint 알림창이 뜬다. [Sprint 이름]이 포함하는 것 : 1개의 완료된 이슈(Sub-Task)가 있다. Complete로 완료한다.

    

  • 결과창으로 넘어가게 된다. 이번 스프린트에 대한 내용이다.

    

  • 오른쪽 아래의 표 항목에서 우리가 설정한 Story Point 총량이 나오고, 표 내용에서는 획득량(To Do → Done으로 처리한 Story의 Story Point의 합)이 나오게 된다.

  • 같은 내용을 Reports 탭에서도 확인할 수 있다.