스크럼 메트릭

스크럼은 팀이 복잡한 문제를 해결하는 동시에 목표를 중심으로 솔루션을 반복적으로 개발하는 데 도움이 되는 애자일 프레임워크이자 작업 방식입니다. 스크럼 작업 방식은 스프린트로 특징지어지며, 스프린트란 스크럼 팀이 정해진 양의 작업을 완료하기 위해 작업하는 측정된 시간입니다.

적응성으로 인해, 스크럼과 같은 애자일 프레임워크는 기술 중심의 팀을 넘어 지원, 디자인, 마케팅 팀 등으로 확산되었습니다. 따라서 스크럼 메트릭은 팀 성과와 효율성을 측정하는 데 점점 더 중요해지고 있습니다.

스크럼 메트릭은 스크럼 팀이 효율성과 효과성을 개선하기 위해 추적하고 사용하는 특정한 데이터 포인트입니다. 스크럼 메트릭을 정의, 이해 및 구현하면 팀의 애자일 여정을 안내하고 개선하는 데 도움이 되는 인사이트가 될 수 있습니다.

스크럼 팀은 메트릭을 사용하여 의사 결정에 정보를 제공하고 계획 및 실행에서 더 효율적으로 진행합니다. 메트릭은 또한 현재 상태에 대한 기준선을 설정하고 목표 및 개선 계획을 세우는 데 사용할 수 있습니다. 그렇게 할 때 모두를 현재와 비교할 수 있는 업계 표준 척도는 없습니다. 컨텍스트가 없을 때 데이터 포인트를 비교하는 것은 마치 사과와 굴을 비교하는 것과 같기 때문입니다. 모든 팀은 각각 고유합니다. 따라서 규모, 사용하는 기술, 작업 유형 면에서 다를 수 있습니다.

추적하고 사용 방법을 정의할 일련의 메트릭에 대해 합의를 이루는 것은 각 팀의 몫입니다. 이것은 개인적인 노력으로 이루어지는 것도 아니며, 리더십이나 경영진이 팀을 대신하여 정의하고 시행할 수 있는 것이 아닙니다.

스크럼 메트릭은 팀이 벤치마크를 설정하고 작업 방향을 안내하는 데 도움이 될 수 있습니다. 이러한 이유로 스크럼 메트릭은 기존 팀과 신규 팀 모두에게 유용합니다.

스크럼 메트릭을 추적하면 팀의 속도, 작업 수용량, 제공 예측 가능성 또는 제품의 품질 등 팀 효율성의 다양한 차원에 대한 가시성을 확보할 수 있습니다. 주요 메트릭은 팀의 성과에 대한 인식을 높이고 변화와 개선을 위한 조치를 유도할 수 있습니다. 또한 시간이 지남에 따라 팀의 행복과 만족도를 측정하는 데 도움이 될 수도 있습니다.

많은 애자일 팀에서는 너무 쉽게 직감이나 직관에 의존하여 팀의 성과를 파악합니다. 이 습관 뒤에는 여러 실질적인 이유가 있을 수 있지만, 큰 기회를 놓친 것이나 다름없습니다.

사용할 수도, 사용하지 못할 수도 있습니다. 스크럼 메트릭은 핵심 성과 지표(KPI)를 설정하는 데 사용할 수 있지만 작업의 유형 및 범위에 따라 다릅니다. 스크럼 메트릭만으로는 고객 가치를 측정하거나 팀이 올바른 것을 제공했는지 여부를 보여줄 수 없습니다. 애자일 팀의 경우 KPI는 궁극적으로 팀이 회사 우선 순위를 얼마나 잘 지원하는지 보여줘야 합니다.

스크럼 팀의 성과를 측정할 때는 다음을 포함하여 스크럼 이외의 다른 메트릭을 고려해야 합니다.

• 비즈니스의 투자 대비 효과(ROI) — 기업은 매출 증가, 월간 사용 현황(MAU) 등 목표에 따라 다양한 방법으로 이를 측정합니다.
• 고객 만족도 — NPS(순 추천 고객 점수) 및 CSAT(고객 만족도 점수)와 같은 설문조사 메트릭은 프로젝트의 성공을 추적하는 데 도움이 될 수 있습니다. 모든 릴리스에 대해 일관적인 고객 만족도 메트릭은 스크럼 팀의 가치를 고객에게 보여주는 데 중요합니다.
• 팀 만족도 — 팀에게 프로젝트에 대한 동기 부여 수준과 팀과의 참여 수준을 물어보는 것만으로도 이직률, 이탈 및 개발자 불만족과 같은 문제를 파악할 수 있습니다.

While agile scrum defines several recurring events — sprint, sprint planning, daily scrum, sprint review, sprint retrospective — these don’t provide any guarantees of progress or success. However, each one allows team members to inspect and adapt how they work.

스프린트 계획 회의는 스프린트가 시작될 때 진행되며, 팀은 스토리 설명을 세부 작업으로 나눕니다. 그러면 스프린트 중에 만들어질 작업의 추정치가 제공됩니다. 스프린트 목표, 현재 팀 속도, 팀의 작업 수용량 및 작업 유형을 포함하여 팀의 스프린트 계획을 더 효율적으로 만들 수 있는 데이터 포인트가 몇 가지 있습니다. Atlassian에서는 스프린트 계획 회의 템플릿을 사용하여 스프린트 계획을 진행합니다.

스프린트 목표는 팀이 스프린트에서 달성해야 할 작업을 결정하고 항목에 응집력을 부여하며 우선 순위를 설정하는 데 도움이 됩니다. 스프린트 목표는 종종 여러 스프린트를 통해 달성할 수 있는 것보다 더 큰 결과에 기여합니다. 스프린트 목표의 우선 순위는 이 결과에 미치는 영향을 기반으로 해야 합니다. 진정으로 효과적인 팀은 목표와 우선 순위를 정기적으로 검토하여 엔지니어링 노력의 순서를 정하고 분할하는 방법을 전략화합니다.

팀이 스프린트에 쏟을 수 있는 노력의 양은 본질적으로 속도(주어진 시간 동안 할 수 있는 작업의 양), 그리고 작업 수용량(업무 가능 상태)에 달려 있습니다. Jira에서 사용하는 것과 같은 속도 차트는 스프린트 중에 제공되는 가치의 양을 보여줍니다. 이를 통해 팀이 향후 스프린트에서 수행할 수 있는 작업량을 예측할 수 있습니다. 팀의 속도는 하나의 팀으로서 몇 번의 스프린트를 함께 진행해야만 파악할 수 있습니다. 시간이 지남에 따라, 팀이 협력하면서 속도가 안정화됩니다. 여기에는 사용되는 기술을 강화하는 것뿐만 아니라 서로의 전문성을 파악하고 팀으로서 협력하는 방법을 배우는 것도 포함됩니다.

다음은 (1) 스토리 포인트를 기반으로 한 추정 통계, (2) 스프린트의 모든 이슈에 대한 추정치인 이행 약속, (3) 완료된 추정치 및 (4) 완료된 스프린트가 포함된 속도 차트의 예시입니다.

팀이 스프린트에서 완료할 수 있는 작업량이 작업 수용량과 업무 가능 상태에 따라 달라진다는 것은 놀라운 일이 아닙니다. 팀의 절반이 휴가를 떠난다면 안정적인 속도는 아무 의미가 없습니다. 작업 수용량을 계획하는 한 가지 방법은 몇 번의 스프린트에서 각 팀원의 업무 가능 상태를 수집하고 합계를 더하여 총 작업 수용량의 일정 비율을 얻는 것입니다. 마지막 순간의 변경 사항 또는 긴급 상황은 누구에게나 발생할 수 있으므로 과도한 이행 약속과 제공 미달을 방지하기 위해 스프린트 이행 약속에 10% 완충 구간을 두는 것도 좋은 생각입니다.

When your sprint backlog is a growing mix of feature work, bug fixes, and technical debt, it becomes tricky to see where your team is dedicating their time in the sprint. It’s easy for bugs or tech debts to sneak into your sprint, especially if the development team is passionate about quality. But if a team isn’t careful, it can end up after the sprint wondering why it didn’t ship enough customer values as planned.

스프린트 계획 중에 서로 다른 유형의 작업 분할을 검토하여 팀이 어떤 작업을 수행하고 있는지 의도적으로 생각해 보세요. 이 경우, 백로그에서 많은 기술적 부채와 양질의 작업을 발견하더라도 기술적 부채 스프린트를 예약하거나 QA에 대한 기준을 높여 전략적으로 해결할 수 있습니다.

스탠드업 회의 또는 매일 스크럼은 팀원들이 자신의 작업에 대해 체크인하도록 매일 열리는 짧은 회의입니다. 효과적인 스크럼 팀의 경우 스탠드업 회의는 해야 할 일 목록에서 개인의 업데이트 사항에 대해 업데이트를 제공하는 것 이상이어야 합니다. 팀의 스프린트 진행률을 검토하고 스프린트 결과에 중대한 영향을 미칠 수 있는 크고 작은 일상적인 의사 결정을 내리기 위한 우선 순위를 다시 정렬할 수 있는 기회입니다.

이 과정에서 다음과 같은 데이터와 메트릭이 유용할 수 있습니다.