스크럼 가이드 | 34. 스크럼의 속도 – 개발 팀의 속도

게시 됨: 2022-07-06

Velocity in Scrum은 Scrum 팀이 작업을 완료하는 속도를 결정하는 데 도움이 됩니다. 한 스프린트에서 완료된 스토리 포인트의 평균 수로 정의할 수 있습니다. Velocity는 이미 완료된 작업 진행 상황을 기반으로 프로젝트 기간을 추정할 수도 있습니다. 그러나 이것은 균일하고 꾸준한 속도로 일하는 성숙한 팀에게만 의미가 있습니다. Velocity가 무엇이며 어떻게 하면 가장 잘 작동하는지 살펴보십시오!

스크럼의 속도 – 목차:

  1. 스크럼의 속도 – 소개
  2. 실제 및 계획된 속도
  3. 스크럼의 속도와 관련된 어려움 및 위험
  4. 요약

스크럼의 속도 – 소개

Velocity는 선택 사항이지만 스크럼 팀의 속도를 측정하는 인기 있는 방법입니다. 정확하게 추정된 Velocity를 통해 프로젝트를 완료하는 데 필요한 시간을 합리적으로 예측할 수 있기 때문입니다. 그러나 이는 스토리 포인트와 같은 친숙한 단위를 사용하여 자체적으로 "가치 있는" 작업을 수행하는 특정 개발 팀에만 적용할 수 있는 조치입니다.

개발팀의 Velocity는 Velocity Chart의 형태로 가장 자주 표시됩니다. X축에는 연속 스프린트가 표시됩니다. 반면 Y축에서는 주어진 스프린트에서 완료된 스토리 포인트 또는 기타 해당 단위의 수를 찾을 수 있습니다. Velocity Chart를 통해 스크럼 팀은 작업 속도의 변화를 명확하게 파악할 수 있습니다. 차트에 표시된 선이 상승하면 팀이 효율성을 최적화하거나 스토리 포인트의 가치를 낮추고 있음을 의미합니다. 따라서 스크럼 마스터와 제품 소유자는 팀의 속도를 표시하는 라인을 주의 깊게 따라야 합니다.

velocity in scrum - speed of the development team

실제 및 계획된 속도

개발 팀 의 실제 속도 는 완료된 스프린트의 작업 속도를 설명하고 각 스프린트가 끝날 때 계산됩니다. 완료된 모든 사용자 스토리의 스토리 포인트 합계 값을 취합니다. 개발 팀의 실제 속도를 통해 미래 작업의 속도를 어느 정도 확률로 계획하고 추정할 수 있습니다.

반면에 계획된 Velocity 는 실제 Velocity의 평균값을 기반으로 추정됩니다. 개발팀에 변화가 없다는 가정이 필요합니다. 개발팀의 중요한 내부 도구로서 이를 기반으로 팀 내 협업이 잘 진행되고 있는지, 작업 속도가 유지되고 있는지 평가할 수 있습니다.

Planned Velocity는 또한 제품 소유자가 후속 스프린트에서 실행하도록 예약된 잘 정의된 사용자 스토리의 실행 시간을 예측할 수 있도록 합니다. 이를 통해 이 기사에서 설명한 제품 백로그를 보다 효율적으로 육성 할 수 있습니다. 그러나 프로젝트 기간을 추정하기 위해 계획된 속도를 적용하는 방법은 그리 간단하지 않습니다.

스크럼의 속도와 관련된 어려움 및 위험

스크럼의 속도는 종종 다음 요소를 고려하지 않고 너무 많은 중요성을 부여받습니다.

  • 더 큰 전체 또는 전체 프로젝트 추정 – 개발 팀은 특정 작업에 할당할 스토리 포인트 수를 정확하게 추정할 수 있지만 이러한 단위에서 향후 구현을 위해 더 큰 전체를 설명하는 것은 매우 어렵거나 불가능합니다.
  • 프로젝트 변경 – 프로젝트 변경은 잠재적으로 제품 목표를 달성하는 데 필요한 스토리 포인트 수의 변경을 의미합니다. 또한 이미 완료된 작업을 수정해야 하거나 제품의 최종 버전에서 사용하지 않을 수도 있습니다.
  • 예측하지 못한 이벤트 - 이미 완료된 프로젝트를 기반으로 미래 프로젝트의 속도를 예측하는 것, 즉 실제 속도를 계획된 속도로 변환하면 정확한 추정 결과를 얻을 수 있습니다. 그러나 각 프로젝트에는 고유한 특성이 있으며 일반적으로 이력을 기반으로 정확한 예측이 불가능합니다.
Velocity in Scrum

요약

Velocity를 개발 팀의 효율성을 평가하는 메트릭으로 사용 하면 신뢰성이 떨어질 수 있습니다. 또한 이 기사에서 자세히 설명한 추정치의 품질을 저하 시킬 수 있습니다. 결국, 메트릭에서 최상의 결과를 얻기 위해 개발 팀은 Velocity를 높이기 위해 작업의 노동 강도를 과대 평가할 수 있습니다. 이는 팀 자체가 개선을 수행하고 작업을 보다 정확하게 계획하기 위해 귀중한 정보를 잃어버리기 때문에 해롭습니다.

스크럼의 속도는 주로 개발 팀 이 작업 속도를 평가하는 데 사용하는 내부 측정으로 유용합니다. 단일 스프린트 동안 완료할 수 있는 작업의 수를 결정할 수 있기 때문입니다.

제품 소유자의 손에 있는 속도는 더 큰 작업의 기한을 추정하는 데 유용한 도구가 됩니다.

그러나 가장 큰 위험은 Velocity를 개발 팀을 평가하기 위한 지표로 사용하는 것과 관련이 있습니다. 이는 스크럼팀의 업무에 대한 외부 평가를 개선하기 위해 신뢰도를 떨어뜨리고 고의적으로 가치를 과대평가할 수 있기 때문이다.

콘텐츠가 마음에 들면 Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest에서 바쁜 꿀벌 커뮤니티에 가입하세요.

Scrum Guide | 34. Velocity in Scrum - Speed of the Development Team caroline becker avatar 1background

저자: 캐롤라인 베커

프로젝트 관리자인 Caroline은 최고의 워크플로를 설계하고 프로세스를 최적화하기 위한 새로운 방법을 찾는 데 전문가입니다. 그녀의 조직적 기술과 시간 압박 속에서 일하는 능력은 그녀를 복잡한 프로젝트를 현실로 만드는 최고의 사람으로 만듭니다.

스크럼 가이드:

  1. 기본 용어, 역할 및 개념의 용어집
  2. 스크럼이란?
  3. 스크럼 값
  4. 회사에서 스크럼을 구현하는 방법은 무엇입니까?
  5. 스크럼 팀 - 무엇이며 어떻게 작동합니까?
  6. 제품 소유자는 누구입니까?
  7. 제품 소유자의 가장 일반적인 실수
  8. 스크럼 마스터는 누구인가?
  9. 좋은 스크럼 마스터의 특징
  10. 스크럼 마스터의 가장 흔한 실수
  11. 스크럼 마스터가 추적해야 하는 통계 및 메트릭은 무엇입니까?
  12. 제품 소유자와 스크럼 마스터 간의 협력
  13. 스크럼 개발팀
  14. 개발자의 가장 흔한 실수
  15. 스크럼 아티팩트
  16. 스케일링 스크럼
  17. 스프린트 백로그
  18. 제품 백로그란 무엇입니까?
  19. 사용자 스토리란 무엇입니까?
  20. INVEST로 최고의 사용자 스토리 만들기
  21. 가장 흔한 사용자 스토리 실수
  22. 사용자 스토리 수락 기준
  23. 스크럼의 추정 및 스토리 포인트
  24. 계획 포커
  25. 팀 평가 게임
  26. 증분 정의
  27. 스크럼 이벤트
  28. 스크럼에서 스프린트란?
  29. 스크럼 팀 약속 - 제품 목표, 스프린트 목표 및 완료의 정의
  30. 번다운 차트란 무엇입니까?
  31. 번다운 차트를 만들고 해석하는 방법은 무엇입니까?
  32. 번다운 차트의 장점과 단점
  33. 스크럼과 스크럼반의 칸반 보드
  34. 스크럼의 속도 - 개발 팀의 속도
  35. 일일 스크럼
  36. 스프린트 계획
  37. 스프린트 리뷰
  38. 스프린트 회고란 무엇입니까?
  39. 스프린트 회고 중 일반적인 실수
  40. 제품 백로그 육성