스프린트 계획 및 검토와 같은 핵심 스크럼 행사 외에도, 팀은 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: 각 이터레이션 후 나머지 스토리 포인트의 최악 사례 예측.
  • 계산은 가장 최근에 완료된 이터레이션의 속도와 변동성을 참조합니다. 여기에서:
    • 변동성: C10
    • 속도: 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 또는 2인 스토리만 이터레이션으로 가져오도록 의도적으로 합니다. 대형 스토리의 크기를 어떻게 줄일지 파악할 수 없다면 엔지니어링 스파이크를 수행하는 것을 고려합니다. 구현 경로를 이해하고 팀이 더 점진적이고 반복적으로 스토리에 접근하는 방법을 파악합니다.

3. 프로세스 병목 현상이 있는 곳을 이해합니다.

   스프린트에서 스토리가 진행하는 워크플로 단계를 반영하는 사용자 정의 가치 흐름 분석 보고서를 만들 수 있습니다. 이 보고서는 스프린트 주기에서 가장 오래 걸리는 특정 워크플로 단계에 대한 회고의 논의를 집중시키는 데 도움이 됩니다.

관련 주제#

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