스탠드업, 회고 및 속도

추가로 스프린트 계획 및 리뷰와 같은 핵심 스크럼 의식과 함께, 팀은 협업하거나 분산된 환경에서 다음과 같은 일반적인 스크럼 의식을 촉진하는 데 GitLab을 사용할 수 있습니다:

매일 스탠드업
회고
스토리 포인트
속도 및 변동성

이 페이지는 입문적인 스크럼 튜토리얼의 개념 및 워크플로우에 기반을 두고 있습니다. 그 튜토리얼을 완료하지 않았다면 먼저 완료해야 합니다.

매일 스탠드업

일반적인 지침:

스탠드업 시간을 15분 이내로 제한합니다.
어떤 주제가 상태 업데이트 이상의 토론을 요구할 경우 관련된 당사자가 스탠드업 후에 추가 토론을 진행할 수 있도록 토론을 연기합니다.

동기식 스탠드업

동일한 장소에서 협업하는 경우 현재 스프린트 보드를 확인하여 해당 이슈에 대한 업데이트를 논의합니다.

분산되어 있는 경우, 비디오 통화를 하고 한 명이 화면 공유를 진행하여 현재 스프린트 보드를 검토합니다.

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

“어제 어떤 일을 수행했나요?”
“오늘 어떤 일을 할 예정인가요?”
“현재 또는 곧 무엇인가에 의해 막히게 되거나 막히게 될 예정인가요?”

비동기식 스탠드업

GitLab에서 비동기식 스탠드업을 촉진하기 위해서 몇 가지 다양한 옵션이 있습니다:

팀의 채팅 도구 사용: 각 팀원의 스탠드업을 보고하기 위해 자동화를 사용합니다. 저희는 GitLab 내부적으로 Geekbot을 사용합니다.
GitLab 내에서:
1. 현재 반복에 스탠드업이라고 제목이 붙은 이슈를 생성하고 현재 반복에 추가합니다.
2. 스프린트의 각 날에, 처음으로 스탠드업을 보고하는 사람은 해당 날짜를 갖는 새 댓글을 작성하고, 그런 다음 그들의 업데이트를 댓글로 추가합니다.
3. 각 팀원은 쓰레드로 자신의 업데이트를 토론에 추가합니다. 예시 보기 (데모 프로젝트에서)

스프린트 회고

회고는 팀이 과정 개선을 식별하고 진행상황을 축하하는 비난 없는 기회입니다. 다양한 ‘회고’ 형식 중에서 선택할 수 있습니다.

동기식 회고

회고 때 반복 보고서 검토는 도움이 될 수 있습니다.

완료된 반복에 대한 반복 보고서를 검토하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
계획 > 반복을 선택합니다.
상단에서 완료를 선택하고 여러분의 반복 주기를 선택합니다.
가장 최근에 완료된 반복을 선택합니다.

비동기식 회고

비동기식 회고를 위해 GitLab 이슈를 사용할 수 있습니다.

현재 반복에서 회고라고 제목이 붙은 새 이슈를 생성합니다.

동기식 회고와 같은 형식을 적용할 수 있습니다. 예시 이슈 보기 (James Shore가 제안한 회고 개요를 적용한 데모 이슈)
행동 항목이 많은 경우, 회고와 별도로 추적하는 데 개별 이슈를 생성하는 것을 고려합니다.
팀이 행동 항목을 처리한 후에 회고 이슈를 닫습니다.

스토리 포인트

이야기를 완료하기 위해 상대적인 복잡성과 노력을 식별하기 위해 스토리 포인트를 사용할 수 있습니다. 스토리 포인트는 기획 프로세스 중에 범위와 구현에서의 트레이드 오프를 식별하고 논의하는 데도 도움이 될 수 있습니다.

GitLab에서 팀은 이슈나 작업의 가중치 필드를 사용하여 스토리 포인트를 캡처할 수 있습니다. 측정 전략에 따라 스토리(이슈)나 작업에 가중치를 할당할 수 있습니다.

스토리 포인트 가치 결정

스토리 포인트 척도로 0, 1, 2, 3, 5, 8, 13, 20, 그리고 40의 수정된 피보나치 수열을 사용해야 합니다. Mike Cohn은 피보나치 수열이 추정에 잘 작동하는 이유를 강조하면서, “너무 가까운 숫자는 추정으로 구분하기 어렵다”고 Weber의 법칙을 설명합니다.

단일 스토리 포인트의 가치를 결정할 때, 단일 스토리 포인트의 기준 정의가 개발자의 “이상적인” 하루와 동일하다는 것이 도움이 됩니다. 그 날에는 개발자가 매우 생산적이며, 어떤 것에도 막히지 않고 하루 내내 흐름을 유지합니다.

팀원들과 함께 단일 스토리 포인트의 다른 가치에 대해 합의할 수 있습니다. 합의한 정의를 결정한 후에 그것을 변경하지 않는 것이 중요합니다. 변경하게 된다면 여러 번의 스프린트 후에 속도와 변동성이 정확하지 않을 가능성을 인지해야 합니다.

예를 들어, 반복당 4에서 10개의 사용자 이야기를 전달하는 것을 목표로 한다면, 3보다 큰 포인트 값을 가지는 모든 이야기를 두 개 이상의 더 작은 이야기로 나눌 수 있습니다. 이상적으로 팀은 하나 또는 두 개까지 척도를 조정하거나 결합하는 방향으로 일할 필요가 있습니다.

참고: 이해관계자는 스토리 포인트를 사용하여 팀의 성과를 측정하거나 한 팀을 다른 팀과 비교해서는 안 됩니다.

속도 및 변동성

시간이 지남에 따라 팀은 스토리 포인트를 사용하여 그들의 속도를 이해할 수 있습니다. 속도를 이해하는 것은 스프린트 범위의 크기를 조정하고 팀 외부 이해관계자들과 보다 믿을 수 있는 기대치를 설정할 때 도움이 됩니다.

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

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

팀의 변동성을 알면 한 반복에서 다음 반복으로 이야기를 완료하는 데 얼마나 예측 가능한지를 이해하는 데 도움이 됩니다. 개선해야 하는 가장 중요한 영역 중 하나는 팀의 변동성을 낮추는 데 초점을 맞추는 것입니다.

다음 섹션에서는 아홉 번의 반복 동안 동일한 스토리 포인트를 완료한 두 팀을 살펴보게 됩니다. 더 낮은 변동성이 향후 팀의 성능을 예측할 때 더 많은 신뢰성을 제공할 수 있으며, 궁극적으로 팀이 이해관계자들에게 더 나은 기대치를 설정할 수 있게 합니다.

속도 및 변동성 추적 스프레드시트 만들기

속도 및 변동성이 GitLab에 기본적으로 통합될 때까지(자세한 내용은 epic 435 참조) 다음과 같은 스프레드시트에서 팀의 속도와 변동성을 추적할 수 있습니다.

이 예에서는 Google 스프레드시트를 사용합니다. 선호하는 스프레드시트 소프트웨어에 공식을 적용해야 할 수 있습니다.

이러한 스프레드시트를 작성하려면 다음 열을 작성하고 채워 넣어야 합니다.

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

이터레이션: 지난 이터레이션의 숫자 또는 제목.
완료된 스토리 포인트
속도:
- 첫 번째 셀의 숫자는 완료된 스토리 포인트 열과 동일합니다.
- 다른 모든 셀은 이전 몇 번의 스프린트에서 제공된 스토리 포인트의 평균 수를 보여줍니다. 이 예에서는 최대 4개까지 사용합니다.
- 예를 들어, C10 셀에는 다음 공식이 있습니다: =AVERAGE(B7:B10).
변동성:
- 이전 스프린트에서 제공된 스토리 포인트 수 사이의 표준 편차를 현재 속도로 나눈 값을 계산합니다.
- 예를 들어, D10 셀에는 다음 공식이 있습니다: =(STDEV(B7:B10)/C10).

미래의 완료된 스토리 포인트 수를 예측하려면:

남은 백로그 포인트를 위한 셀. 이 예에서는 F4입니다.
미래 이터레이션: 미래 이터레이션의 번호 또는 제목.
최악의 경우: 각 이터레이션 후 남은 스토리 포인트에 대한 최악의 경우 예측.
- 최신 완료된 이터레이션의 변동성 및 속도를 참조합니다. 여기서:
  - 변동성: C10
  - 속도: D10
- 첫 번째 셀의 공식은 F4 셀의 숫자에서 뺍니다. 예를 들어: =F4-(C10*(1-D10)).
- 다른 모든 셀은 위의 셀에서 뺍니다. 예를 들어, H10 셀에는 다음과 같은 공식이 있습니다: =H9-($C$10*(1-$D$10)).
예상: 나머지 스토리 포인트 후 최신 계산된 속도를 빼고 예측합니다.
- 첫 번째 셀의 공식은 F4 셀의 숫자에서 뺍니다. 예를 들어: =F4-$C$10.
- 다른 모든 셀은 위의 셀에서 뺍니다. 예를 들어, I10 셀에는 다음과 같은 공식이 있습니다: =I9-$C$10.
최상의 경우: 각 이터레이션 후 남은 스토리 포인트에 대한 최상의 경우 예측.
- 최악의 경우와 마찬가지로, 최신 완료된 이터레이션의 변동성 및 속도를 참조합니다.
- 첫 번째 셀의 공식은 F4 셀의 숫자에서 뺍니다. 예를 들어: =F4-(C10*(1+D10)).
- 다른 모든 셀은 위의 셀에서 뺍니다. 예를 들어, J10 셀에는 다음과 같은 공식이 있습니다: =J9-($C$10*(1+$D$10)).
예측을 설명하는 선 그래프:
- 차트의 제목을 최악의 경우, 예상 및 최상의 경우로 지정합니다.
- 범위를 위의 네 열로 설정합니다.
- 미래 이터레이션 열을 X축으로 설정합니다.
- 나머지 열 각각에 대한 시리즈를 추가합니다.
- 다음 확인란을 선택합니다: 행 1을 헤더로 사용, 열 G를 레이블로 사용, 레이블을 텍스트로 취급.

추적을 유지하려면 매 스프린트가 끝날 때 팀이 완료한 스토리 포인트 수를 업데이트합니다.

높은 변동성이 예측 가능성을 줄입니다

첫 번째 예는 최근 9개 스프린트에서 변동성이 높은 팀입니다:

이터레이션	완료된 스토리 포인트	속도	변동성
1	8	8	0%
2	15	11.5	43%
3	11	11.33	40%
4	7	10.25	35%
5	6	9.75	42%
6	15	9.75	42%
7	10	9.5	43%
8	6	9.25	46%
9	8	9.75	40%

이 팀이 백로그에 200점이 남아있다고 가정하면, 현재 속도와 변동성을 사용하여 백로그를 완료할 때까지 몇 번의 스프린트가 필요한지에 대한 최악의 경우, 예상 및 최상의 경우를 예측할 수 있습니다.

팀은 다음과 같이 백로그를 완료할 것입니다:

최상의 경우, 24개의 스프린트에서.
예상 시나리오에서는 총 30개의 스프린트에서.
최악의 경우, 43개의 스프린트에서.

각 스프린트가 두 주씩 지속되고 다른 비즈니스 기능이 추정된 납품일을 조정할 때, 최선의 경우, 예상 및 최악의 경우 간에 38주라는 차이는 실제로 실행 가능하지 않습니다. 이러한 넓은 변별성은 스크럼 팀과 조직의 나머지 간의 신뢰를 떨어뜨립니다.

낮은 변동성이 예측 가능성을 증가시킵니다

두 번째 예는 최근 9개의 스프린트에서 변동성이 낮은 팀을 살펴봅니다:

이터레이션	완료된 스토리 포인트	속도	변동성
1	9	9	0%
2	10	9.5	8%
3	11	10	10%
4	9	9.75	10%
5	8	9.5	14%
6	10	9.5	14%
7	9	9	9%
8	11	9.5	14%
9	9	9.75	10%

이전 팀과 마찬가지로, 이 팀은 동일한 마지막 속도를 달성했지만 변동성 지표가 훨씬 낮았습니다. 이 팀도 200개의 스토리 포인트 백로그 크기를 가지고 있으며, 이 팀은 백로그를 완료하는 보다 현실적이며 예측 가능한 타임라인을 전달하는 데 더 큰 자신감을 가지고 있습니다.

두 팀 모두 동일한 수의 스토리 포인트를 완료했습니다. 그러나 변동성이 더 낮은 팀은 24에서 43까지 하는 것과는 달리 백로그를 완료할 수 있는 28에서 32개의 스프린트에 걸쳐 전달 창을 전달할 수 있습니다. 이는 타임라인에 8주의 변동성만 가집니다. 이러한 예측 가능성 수준은 스크럼 팀과 조직의 나머지 간의 신뢰를 유지하는 데 도움이 됩니다.

변동성 감소

만약 높은 변동성을 경험 중이라면, 다음을 살펴볼 수 있습니다:

안정적이고 집중된 제품 팀 유지하기.

팀 구성원들이 많은 작업 스트림에 시간을 분산하고 한 번의 스프린트에서 다음으로 일관되게 할당되지 않는 경우, 속도의 변동을 일으킬 수 있습니다.
스토리를 작은 수직 조각으로 나누기.

최근 완료한 이야기를 살펴보고 이야기 점수의 범위를 평가하세요. 5점짜리 이야기는 1점짜리 이야기보다 훨씬 복잡하고 미지의 요소가 많습니다. 팀원으로서 의도적으로 이터레이션에 1점 또는 2점의 무게를 가진 스토리만 끌어당기기로 하세요. 큰 이야기의 크기를 줄이는 방법을 알 수 없다면 공학 스파이크를 진행하는 것을 고려해 보세요. 구현 경로를 이해하고 팀이 접근하여 이야기를 점진적, 순환적으로 다룰 수 있는 방법을 확인하세요.
프로세스 병목 현상이 있는 곳을 이해하기.

스프린트에서 이야기가 진행하는 워크플로 단계를 반영하는 사용자 정의 가치 스트림 분석 보고서를 작성할 수 있습니다. 이 보고서는 스프린트 주기 동안 가장 오랜 시간이 걸리는 워크플로 단계에 대한 토론에 집중하는 데 도움이 될 수 있습니다.