Jira로 스크럼 & 스프린트 운영하기

2018년도에 서비스 기획자라는 포지션으로 첫 커리어를 시작했습니다. 당시에는 프로덕트 매니저(PM) & 프로덕트 오너(PO)라는 개념이 이제 막 실리콘밸리에서 들어오고 있었던 시기라 해외 블로그를 뒤져보면서 PM, PO라는 Role에 대해 공부하고 이런 역할로 일하는 것을 꿈꿨던 기억이 납니다.

 

그때 새로운 프로젝트/프로덕트 관리 툴에 대해 많이 알게 되었는데 그중 하나가 Atlassian사의 Jira였습니다. 트렐로와 노션을 메인으로 사용하고 있던 저는 Jira가 궁금했지만 당장은 기존에 사용하던 툴을 계속 사용할 수밖에 없었죠.

 

그러다 이직을 하게 되면서 프로덕트 매니저라는 Role의 수행과 스크럼과 스프린트 그리고 이를 운영하기 위한 툴(Jira)을 본격적으로 활용하기 시작했습니다. 이 시기에 공부했던 내용 중 오늘은 Jira로 스크럼과 스프린트를 어떻게 운영하면 좋을지 적어보려 합니다.

 

스크럼과 스프린트에 관해서는 별도의 글을 작성했으니 참고해 주세요.

 

출처: atlassian 공식 웹사이트

 

지금부터 제가 적는 글은 Product 별로 Jira Project를 운영하는 데 있어 초기 참고 가이드 정도의 내용만을 다룰 예정입니다. 실제로 Product별로 개발 방법론이 다를 수 있고, 그에 따른 Product life/release cycle이 당연히 달라질 수 있기 때문에 반드시 이 글의 내용대로 운영할 필요는 없으며 각자의 Product 특성에 맞게 테일러링해서 운영하면 되겠습니다.

 

Jira 프로젝트

• Product 별로 Jira project를 생성해서 Sprint를 운영함을 원칙으로 합니다.
• Product의 특성에 따라 Project의 템플릿은 달라질 수 있으나, 기본적으로 스크럼 형태의 보드 운영을 기본으로 합니다.

출처: atlassian 공식 웹사이트

 

Issue Type

• Epic(에픽)
  • Product의 로드맵으로 관리되는 단위를 Epic으로 생성하도록 권장합니다.
  • Product 자체 로드맵인 경우, 구체적인 마일스톤과 그에 대한 일정이 담긴 요소로 지정하면 됩니다.
    • 외부 협업 프로젝트의 경우, 협업 일정 로드맵의 구성요소들이 하나의 Epic이 될 수 있습니다.
  • Epic은 큰 틀에서의 Goal과 달성하고자 하는 일정으로 구성되며, 이 일정에 수반되는 작업들을 Story 또는 Task로 관리합니다.
    • Epic은 시작과 종료일이 명시되는 것을 원칙으로 합니다.
    • 즉, Epic은 작은 Story와 Task들의 모음과 같습니다.

출처: atlassian 공식 웹사이트

• Story(스토리)
  • Story는 Product를 이용하는 사용자에게 제공하는 기능을 서술하는 단위를 의미합니다.
    • Sprint 1회 안에서 개발 완료 및 사용 가능한 기능의 최소 단위로 Story를 생성하도록 권장합니다.
  • 보통 하나의 Story는 프론트엔드 개발을 통해 사용자에게 Delivery되는 기능으로 여러 개발/디자인/UX 작업들로 구성됩니다.
    • Story를 구성하는 여러 작업들은 Story의 sub-task로 만들어서 관리하는 것을 원칙으로 합니다.
  • 일반적으로 Story는 Product Manager(혹은 Product Owner)가 작성하며, 해당 기능의 요구사항과 목표를 명시해야 합니다.
    • Story를 사용자에게 Delivery하기 위한 Sub-task들은 각 기능 개발/디자인 담당자이 작성하는 것을 원칙으로 합니다.
  • 각 Story는 구현을 위한 개발규모의 추정치인 Story Point를 반드시 명시해야 합니다.
    • Story Point는 요구사항의 규모를 측정하는 단위로, 복잡도를 감안한 업무량을 의미하며, 투입되는 공수나 담당자의 능력치와는 상관없이 Story에 대한 업무 규모로 산정합니다.
    • 이전에 완료한 Story를 기준으로 업무 규모에 대한 비교를 통해 상대적인 점수를 부여할 수 있으며, 팀원들이 부여된 점수가 합리적임을 동의해야 합니다.
      • 이전 스프린트에서 수행 경험이 있는 'A' Story의 Story Point가 3점이었으면, 이 proof를 바탕으로 다른 Story들의 업무량을 추정합니다. (Story point 템플릿)
      • 동일한 규모의 작업이라 할지라도 처음에는 3 Story point가 소요되었지만, 이후에는 경험과 효율의 증가로 2 Story point만 소요될 수도 있습니다. 즉, Sprint를 거듭할수록 동일 Story Point에 대한 효율이 증가하여 팀의 생산성 증가로 연결되게 되어, 한 팀이 Sprint 내 수행할 수 있는 Story Point가 증가하는 효과를 기대할 수 있습니다.
        • 스크럼 팀의 Product Manager와 Tech Lead는 번다운(burndown) 차트, 속도(velocity) 리포트 등의 Jira 보고서를 이용해 팀의 속도를 체크하고 향상시킬 수 있도록 노력해야 합니다.

출처: atlassian 공식 웹사이트

• Task(작업)
  • Story가 Product를 이용하는 사용자에게 제공하는 기능 단위를 의미했다면, Task는 Story를 지원하는 기술/관리적인 업무 또는 엔지니어링의 로드맵을 수행하기 위한 개발 작업 단위를 의미합니다.
    • Task는 PM, 엔지니어, 디자이너 모든 팀원들이 작성할 수 있습니다.
  • 보통 Task는 1명이 수행하는 기능 단위로 구성하며, 이 수행을 위한 세부 작업 분리가 필요한 경우 Story와 마찬가지로 Sub-task로 구성해서 관리하는 것을 원칙으로 합니다.
  • Task 역시 Story와 마찬가지로 Story Point가 반드시 부여되어야 합니다.
    • Task의 Story Point 산정은 Story의 Story Point 산정방식과 동일합니다.
• Sub-task(하위 작업)
  • Story 또는 Task를 구성하기 위한 세부 단위로서 여러 기술/운영/기획적인 업무들이 정의될 수 있습니다.
• Bug(버그)
  • Product의 Bug가 리포팅 되었거나 발견된 경우, 해당 내용이 정의되어 전달되는 단위입니다.
  • 이번 스프린트 내에 해결해야 하는 Bug의 경우, Priority(우선순위)를 Highest로 지정하고 먼저 처리하는 것이 원칙입니다.

Product는 응당 제품/사업적인 목표가 있을 것이고, 이를 달성하기 위한 Intiatives를 정의한 뒤, 기능 개발의 레벨로 구체화 단계를 거치면 아래의 그림과 같은 Issue Type 위계가 만들어지게 됩니다.

출처: atlassian 공식 웹사이트

 

스프린트를 운영할 때 주의할 점으로는 Story Point는 일종의 성과 지표가 아니라는 것입니다. 한 Sprint 내 많은 Story Point를 수행했다고 그렇지 않은 팀보다 성과가 좋은 것은 절대로 아니기 때문에 속도에 너무 큰 압박을 받을 필요는 없다고 생각합니다.

 

Backlog(백로그)

• 향후 Sprint에 진행할 Story, Task들은 Backlog에 쌓아놓습니다.
  • 스프린트 플래닝 회의에서 해당 Sprint에 진행할 과제를 Backlog에서 선택합니다.
• 모든 Backlog들은 Priority(우선순위)가 명시되어야 합니다.
  • 스프린트 플래닝 회의에서 Priority가 높은 Backlog 들부터 검토를 진행할 수 있도록 하기 위함입니다.
    • Jira는 Priority를 결정하는 방법으로 MoSCow 프레임워크를 차용하고 있습니다.
    • MoSCoW
      • Mo(Must have) = Highest
      • S(Should have) = High
      • Co(Could have) = Medium
      • W(Won't have) = Low(est)
  • 비즈니스/기술적으로 다음 스프린트에 반드시 진행되어야 하는 내용은 Highest로 책정합니다.
    • 예시: 외부 Client와의 일정에 연결된 과제 또는 반드시 해결해야 하는 기술 부채
  • 바로 다음 스프린트는 아니지만, 프로젝트 로드맵상 이후 스프린트에 진행이 필요한 내용은 High로 책정합니다.
  • 시장이나 로드맵상 요구되는 내용은 아니지만 추후 제공해야 하는 과제인 경우는 Low로 책정합니다.

출처: atlassian 공식 웹사이트

 

Sprint Board

• Board의 Column 구성은 아래를 기본으로 합니다.
  • To Do: 착수 전 상태
  • Doing: 진행 상태
  • Done: 진행 완료 상태
    • 테스트 등 Production 배포를 위한 모든 준비가 완료된 상태
• Product 환경에 따라 Doing 이후 단계를 아래 예시와 같이 커스터마이징 할 수 있습니다.
  
  • Doing → Test Deployed → Done: 테스트 배포 완료 및 테스트 단계 추가
  • Review → Pending → Done: 코드리뷰 대기 상태 및 기타 이유로 작업을 일시 중단한 상태 추가

출처: atlassian 공식 웹사이트

 

Sprint Schedule

1. Sprint 첫날 시작에 앞서 이번 Sprint에 대한 Planning을 합니다.(스프린트 플래닝 미팅)
   1. 우선순위가 높은 Story/Task를 뽑고, 이를 위한 Sub-Task를 생성하고 각각의 Story Point를 산정합니다.
      1. Story Point 산정과 팀원의 합의 과정에서 Planning Poker라는 방식을 사용하기도 합니다.
         * Planning Poker: 소프트웨어 개발에 있어서 개발 목표를 위한 공수 산정이나 상대적 규모 산정에 사용하는 프레임워크
      2. 기존 히스토리가 없는 초기의 스크럼 팀인 경우 1 Story point를 1명의 담당자가 하루동안 수행할 수 있는 작업의 양으로 정의하고 상대적인 속도를 측정 가능할 때까지 운영하는 방법을 사용하기도 합니다.
   2. Sprint 기간 내 수행 가능한 수준의 Story/Task 선정을 해야 하며, 이는 과거 수행한 Story Point 값을 참고하면 되겠습니다.
      1. Sprint 기간 중에 버그 등의 이슈 상황 대응 및 스프린트 플래닝과 스프린트 회고, 데일리 미팅에 소요되는 시간 등을 감안하여 가용가능한 시간을 산정해야 합니다.
         1. 스프린트 플래닝과 회고, 데일리 미팅 등을 모두 더하면 반나절에서 하루 정도는 실제 작업 시간에서 빼야 할 수 도 있기 때문입니다.
2. Sprint 기간 동안 스프린트 플래닝에서 선정한 Story와 Task에 대한 실제 개발 및 Test(QA)를 진행합니다.
   1. Sprint 기간 중 스프린트 플래닝에서 결정한 Story나 Task를 삭제하거나, 다른 Story와 Task는 가능한 추가하지 않습니다.
      1. Sub-task 및 Bug 타입의 작업만 추가할 수 있습니다.
         1. Sub-task의 경우 Sprint 기간 중 삭제, 수정 모두 가능합니다.
      2. 예외적으로 Client Project가 있는 경우, Client에 의해 요청된 급한 내용의 Task만 추가를 허용하도록 하며, 이 경우 Story Point 산정의 작업을 다시 거쳐서 추가하도록 합니다.
   2. Product Manager와 Tech Lead는 Sprint 기간 중 다음 Sprint에 진행해야 하는 Backlog들의 작성도 함께 진행해야 합니다.
   3. Story의 경우 요구사항이 반영된 UX/Design 작업 결과에 대한 Tech Lead의 Feasibility 리뷰가 스프린트 중에 이루어져야 합니다.
   4. 이번 Sprint 내 포함된 Story와 Task가 Test(QA)가 필요한 경우, Sprint일정에 Test(QA) 일정을 고려해서 Planning을 해야 합니다.
      1. QA 필요시, QA에 대한 Task를 생성해서 관리합니다.
3. Sprint를 진행하는 동안 매일 Scrum 미팅을 진행합니다.
   
   1. Daily Scrum Meeting에서는 스크럼 팀 구성원 모두 각자의 한일/할 일/이슈를 공유합니다.
   2. 참석자들이 모두 이해할 수 있는 수준의 내용만 짧게 공유하도록 하며, 이슈가 있는 경우 Scrum 미팅 이후 별도 미팅이나 자리에서 논의하도록 합니다.
4. Sprint 종료날에 스프린트 리뷰 & 회고(Retrospective) 미팅을 반드시 진행합니다.
   1. 리뷰 미팅에서는 이번 스프린트에서 개발한 Story(Product를 이용하는 사용자에게 제공하는 기능)의 실제 동작을 볼 수 있는 데모를 스크럼 팀과 함께 진행하고 제품 개선에 반영합니다.
      1. 필요하다면 스크럼 팀만이 아니라 이해관계자들을 초청하여 데모를 진행하도록 합니다.
   2. 회고 미팅을 통해 잘한 점(Keep), 문제점(Problem), 문제 해결을 위해 노력할 점(Try)들에 대한 논의를 합니다.
      1. 수행하지 못한 Story/Task에 대한 원인 분석, 완료한 Story Point에 대한 확인 및 생산성 분석 등도 진행합니다.
      2. 이때, 번다운 차트, 속도 리포트와 같은 데이터를 이용한 분석을 함께 하는 것을 권장합니다.
5. Sprint 별 개발 사항 또는 Release 내용을 모아 데모를 주기적으로 진행합니다.
   1. 개발 내용에 대한 주기적인 데모를 통해 피드백을 받아보고 제품 개선에 반영하도록 합니다.
   2. 최대한 한 달에 한번 스크럼 팀 내 데모, 분기에 한번 사내 데모를 하는 것을 목표로 합니다.

출처: https://www.wrike.com/scrum-guide/scrum-sprints/

 

마무리

Jira를 이용해 스크럼 & 스프린트를 운영하는 다양한 방법 중 초기 가이드로 삼을만한 내용을 적어보았습니다. 주니어 시절에 Jira나 스프린트 운영에 관해 속 시원하게 알 수 있는 정보를 찾기 어려웠다 보니 애를 먹었던 기억이 있습니다. 이 글이 비슷하게 애를 먹고 있는 분들이 있다면 도움이 되었으면 좋겠습니다.