스프린트 계획, 리뷰 등 핵심 스크럼 세리머니 외에도, 팀은 GitLab을 사용해 한 공간에 모인 환경과 분산된 환경 모두에서 다음과 같은 일반적인 스크럼 세리머니를 진행할 수 있습니다.

• 데일리 스탠드업
• 회고
• 스토리 포인트
• 속도와 변동성

이 튜토리얼은 스크럼 입문 튜토리얼의 개념과 워크플로를 기반으로 합니다. 아직 해당 튜토리얼을 완료하지 않았다면, 계속 진행하기 전에 먼저 완료합니다.

데일리 스탠드업#

공통 가이드라인:

• 스탠드업은 15분을 넘기지 않도록 제한합니다.
• 상태 업데이트 범위를 넘어서는 추가 논의가 필요한 주제가 있다면, 논의를 미뤄 관련자들이 스탠드업이 끝난 뒤 별도로 모여 더 논의할 수 있도록 합니다.

동기 스탠드업#

한 공간에 모여 있다면, 같은 방에 모여 Current Sprint 보드를 살펴보며 각 이슈의 업데이트를 논의합니다.

분산되어 있다면, 화상 통화에 접속해 한 사람이 화면을 공유하며 현재 스프린트 보드를 검토하도록 합니다.

현재 스프린트 보드를 함께 검토하는 대신, 다음 형식을 사용할 수도 있습니다. 각 팀원은 다음 세 가지 질문에 답합니다.

• "어제 무엇을 완료했는가?"
• "오늘 무엇을 작업하는가?"
• "현재 또는 곧 어떤 것에 의해 막힐 예정인가?"

비동기 스탠드업#

GitLab에서 비동기 스탠드업을 진행하려면 몇 가지 방법을 사용할 수 있습니다.

• 팀의 채팅 도구에서: 자동화를 사용해 각 팀원의 스탠드업을 보고합니다. GitLab은 내부적으로 Geekbot을 사용합니다.

• GitLab에서:

  1. Stand-up이라는 제목의 이슈를 생성하고 현재 이터레이션에 추가합니다.
  2. 스프린트의 매일, 가장 먼저 스탠드업을 보고하는 사람이 날짜가 담긴 새 댓글을 생성한 다음, 자신의 업데이트 내용을 댓글로 추가합니다.
  3. 각 팀원은 자신의 업데이트를 스레드 형태로 논의에 추가합니다. 데모 프로젝트의 예시를 참고합니다.

스프린트 회고#

회고는 팀이 프로세스 개선점을 찾고 진행 상황을 축하할 수 있는, 비난 없는 기회입니다. 다양한 회고 형식 중에서 선택할 수 있습니다.

James Shore는 자신의 저서 "The Art of Agile"에서 회고 진행 방법에 대한 훌륭한 개요를 제공합니다.

동기 회고#

회고 중에는 이터레이션 리포트를 검토하면 도움이 됩니다.

완료된 이터레이션의 리포트를 검토하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Plan > Iterations를 선택합니다.
3. 상단에서 Done을 선택하고 이터레이션 주기를 선택합니다.
4. 가장 최근에 완료된 이터레이션을 선택합니다.

비동기 회고#

비동기 회고에는 GitLab 이슈를 사용할 수 있습니다.

1. 현재 이터레이션에서 Retrospective라는 제목의 새 이슈를 생성합니다.

   동기 회고와 동일한 형식을 대부분 적용할 수 있습니다. James Shore가 제안한 회고 개요를 적용한 예시 이슈를 참고합니다.

2. 액션 아이템이 많다면, 회고와는 별도로 추적할 수 있도록 별도의 이슈를 생성하는 것을 고려합니다.

3. 팀이 액션 아이템 분류를 마쳤다면, 회고 이슈를 닫습니다.

스토리 포인트#

스토리를 완료하는 데 필요한 상대적 복잡도와 노력을 파악하려면 스토리 포인트를 사용할 수 있습니다. 스토리 포인트는 계획 과정에서 범위와 구현의 트레이드오프를 파악하고 논의하는 데도 도움이 됩니다.

GitLab에서 팀은 이슈나 태스크의 Weight 텍스트 상자를 사용해 스토리 포인트를 기록합니다. 추정 전략에 따라 스토리(이슈)나 태스크에 가중치를 설정할 수 있습니다.

스토리 포인트 값 결정하기#

스토리 포인트 척도로는 0, 1, 2, 3, 5, 8, 13, 20, 40으로 이루어진 변형 피보나치수열을 사용해야 합니다. Mike Cohn이 Weber의 법칙을 설명하며 지적했듯, "서로 너무 가까운 숫자는 추정치로서 구분이 불가능합니다."

스토리 포인트 하나의 값을 결정할 때는, 스토리 포인트 하나를 개발자의 "이상적인" 하루와 동일하게 설정하는 것이 기준 정의로서 도움이 됩니다. 이런 날에 개발자는 생산성이 매우 높고, 어떤 것에도 막히지 않으며, 하루 내내 몰입 상태를 유지합니다.

팀과 함께 스토리 포인트 하나의 값을 다르게 합의할 수도 있습니다. 정의를 결정한 후에는 이를 변경하지 않는 것이 중요합니다. 만약 변경한다면, 이후 몇 차례의 스프린트 동안 속도와 변동성이 부정확해질 가능성이 있다는 점에 유의합니다.

예를 들어 이터레이션당 4~10개의 사용자 스토리를 전달하는 것을 목표로 설정했다면, 포인트 값이 3을 초과하는 스토리는 두 개 이상의 더 작은 스토리로 분할합니다. 이상적으로는, 스토리의 가중치가 1이나 2가 될 때까지 분할하거나 결합하는 방향으로 팀이 작업해야 합니다.

속도와 변동성#

시간이 지나면서 팀은 스토리 포인트를 사용해 자신들의 속도를 파악할 수 있습니다. 속도를 이해하면 스프린트 범위의 크기를 조정하고, 팀 외부 이해관계자와 더 신뢰할 수 있는 기대치를 설정하는 데 도움이 됩니다.

속도는 이전 여러 스프린트에서 전달된 스토리 포인트 수의 평균을 구해 계산할 수 있습니다.

변동성은 이전 스프린트에서 전달된 스토리 포인트 수의 표준편차를 현재 속도로 나눈 값을 나타냅니다.

팀의 변동성을 파악하는 것은 이터레이션마다 스토리를 완료하는 예측 가능성이 얼마나 되는지 이해하는 데 중요합니다. 개선에 집중해야 할 가장 중요한 영역 중 하나는 팀의 변동성을 낮추는 것입니다.

다음 섹션에서는 9번의 이터레이션 동안 동일한 수의 스토리 포인트를 완료한 두 팀을 살펴봅니다. 낮은 변동성이 향후 팀 성과를 예측하는 데 어떻게 더 높은 예측 가능성을 제공하는지, 그리고 이것이 궁극적으로 팀이 이해관계자와 더 나은 기대치를 설정할 수 있도록 하는지 확인할 수 있습니다.

속도와 변동성 트래커 스프레드시트 만들기#

속도와 변동성이 GitLab에 네이티브로 통합되기 전까지 (에픽 435 참고), 다음과 같은 스프레드시트로 팀의 속도와 변동성을 추적할 수 있습니다.

이 예시는 Google Sheets를 사용합니다. 선호하는 스프레드시트 소프트웨어에 맞게 수식을 조정해야 할 수도 있습니다.

이런 스프레드시트를 만들려면, 다음 열을 생성하고 값을 채웁니다.

현재 속도와 변동성을 계산하려면:

• Iteration: 지난 이터레이션의 번호 또는 제목입니다.
• Story Points Completed
• Velocity:
  • 첫 번째 셀의 숫자는 Story Points Completed 열과 동일합니다.
  • 나머지 모든 셀은 이전 여러 스프린트에서 전달된 스토리 포인트 수의 평균을 표시합니다. 이 예시는 최대 4개 스프린트를 사용합니다.
  • 예를 들어 C10 셀에는 다음 수식이 들어갑니다: =AVERAGE(B7:B10).
• Volatility:
  • 이전 스프린트에서 전달된 스토리 포인트 수의 표준편차를 현재 속도로 나눈 값을 계산합니다.
  • 예를 들어 D10 셀에는 다음 수식이 들어갑니다: =(STDEV(B7:B10)/C10).

향후 완료할 스토리 포인트 수를 예측하려면:

• 남은 백로그 포인트를 위한 셀입니다. 이 예시에서는 F4입니다.
• Future Iteration: 향후 이터레이션의 번호 또는 제목입니다.
• Worst Case: 각 이터레이션 이후 남은 스토리 포인트에 대한 최악의 경우 예측입니다.
  • 계산은 가장 최근에 완료된 이터레이션의 속도와 변동성을 참조합니다. 여기서는 다음과 같습니다.
    • Volatility: C10
    • Velocity: D10
  • 첫 번째 셀의 수식은 F4 셀의 숫자에서 빼는 방식입니다. 예를 들면: =F4-(C10*(1-D10)).
  • 나머지 모든 셀은 바로 위 셀에서 뺍니다. 예를 들어 H10 셀에는 다음 수식이 들어갑니다: =H9-($C$10*(1-$D$10)).
• Expected: 남은 스토리 포인트에서 가장 최근에 계산된 속도를 뺀, 각 이터레이션 이후 남은 스토리 포인트에 대한 현실적인 예측입니다.
  • 첫 번째 셀의 수식은 F4 셀의 숫자에서 빼는 방식입니다. 예를 들면: =F4-$C$10.
  • 나머지 모든 셀은 바로 위 셀에서 뺍니다. 예를 들어 I10 셀에는 다음 수식이 들어갑니다: =I9-$C$10.
• Best Case: 각 이터레이션 이후 남은 스토리 포인트에 대한 최선의 경우 예측입니다.
  • Worst Case와 마찬가지로, 계산은 가장 최근에 완료된 이터레이션의 속도와 변동성을 참조합니다.
  • 첫 번째 셀의 수식은 F4 셀의 숫자에서 빼는 방식입니다. 예를 들면: =F4-(C10*(1+D10)).
  • 나머지 모든 셀은 바로 위 셀에서 뺍니다. 예를 들어 J10 셀에는 다음 수식이 들어갑니다: =J9-($C$10*(1+$D$10)).
• 예측을 보여주는 선 차트:
  • 차트 제목을 Worst Case, Expected and Best Case로 지정합니다.
  • 범위를 위의 네 개 열로 설정합니다.
  • Future Iteration 열을 X축으로 설정합니다.
  • 나머지 각 열에 대해 시리즈를 추가합니다.
  • 다음 체크박스를 선택합니다: Use row 1 as headers, Use column G as labels, Treat labels as text.

트래커를 유지 관리하려면, 각 스프린트가 끝날 때마다 팀이 완료한 스토리 포인트 수로 업데이트합니다.

높은 변동성으로 인한 예측 가능성 저하#

첫 번째 예시는 지난 9번의 스프린트 동안 변동성이 높았던 팀입니다.

팀의 백로그에 200 포인트가 남아 있다고 가정하면, 현재 속도와 변동성을 사용해 백로그를 완료하기까지 남은 스프린트 수에 대한 최악, 예상, 최선의 시나리오를 예측할 수 있습니다.

팀은 다음과 같이 백로그를 전달하게 됩니다.

• 최선의 경우, 24번의 스프린트 후입니다.
• 예상 시나리오에서는, 30번의 스프린트 후입니다.
• 최악의 경우, 43번의 스프린트 후입니다.

각 스프린트가 2주씩이고, 다른 비즈니스 부서가 업무 조율을 위해 예상 전달일에 의존한다면, 최선·예상·최악의 경우 사이 38주라는 차이는 그다지 실행 가능하지 않습니다. 이런 큰 변동성은 스크럼 팀과 조직 내 다른 구성원 사이의 신뢰를 저해합니다.

낮은 변동성으로 인한 예측 가능성 향상#

두 번째 예시는 지난 9번의 스프린트 동안 변동성이 낮았던 팀을 살펴봅니다.

이전 팀과 마찬가지로 이 팀도 최종 속도는 같았지만 변동성 지표는 훨씬 낮았습니다. 동일한 200 스토리 포인트 규모의 백로그를 기준으로, 이 팀은 백로그 완료까지의 더 현실적이고 예측 가능한 일정을 훨씬 더 자신 있게 전달할 수 있습니다.

두 팀 모두 동일한 수의 스토리 포인트를 완료했습니다. 하지만 변동성이 낮은 팀은 2832번의 스프린트(2443번과 비교)라는 전달 범위를 전달할 수 있으며, 이는 일정상 단 8주의 변동에 불과합니다. 이 정도의 예측 가능성은 스크럼 팀과 조직 내 다른 구성원 사이의 신뢰를 높입니다.

변동성 줄이기#

높은 변동성을 겪고 있다면, 다음을 검토해볼 수 있습니다.

1. 안정적이고 집중된 프로덕트 팀을 유지합니다.

   팀원이 여러 작업 스트림에 시간을 나눠 쓰고, 스프린트마다 동일한 팀과 작업 스트림에 일관되게 배정되지 않는다고 가정해봅니다. 이런 경우 속도에 변동이 생길 수 있습니다.

2. 스토리를 더 작은 수직 슬라이스로 나눕니다.

   최근 완료한 스토리를 살펴보고 스토리 포인트의 범위를 평가합니다. 포인트가 5인 스토리는 포인트가 1인 스토리에 비해 복잡도와 불확실성이 훨씬 더 큽니다. 팀 차원에서 가중치가 1이나 2인 스토리만 이터레이션에 가져오도록 의도적으로 노력합니다. 큰 스토리의 크기를 줄이는 방법을 찾기 어렵다면, 엔지니어링 스파이크를 진행하는 것을 고려합니다. 구현 경로를 파악하고, 팀이 해당 스토리에 더 점진적이고 반복적으로 접근할 수 있는 방법을 찾습니다.

3. 프로세스 병목이 어디에 있는지 파악합니다.

   스프린트 동안 스토리가 진행하는 워크플로 단계를 그대로 반영하는 커스텀 밸류 스트림 분석 리포트를 생성할 수 있습니다. 이 리포트는 스프린트 주기에서 가장 오래 걸리는 특정 워크플로 단계에 회고 논의를 집중하는 데 도움이 됩니다.

관련 주제#

• 튜토리얼: 팀 스탠드업을 위한 이슈 보드 설정하기