[데이터] 우리 팀은 일을 어떻게 하고 있는가? - 엑셀을 활용한 JIRA 데이터 분석하기

Let's go

작년 연말, 2022년을 마무리하는 팀 회고를 준비하고 있었습니다. (저희 팀은 각 스프린트마다 회고 담당자가 정해져있고 돌아가며 회고를 준비합니다.) 어떤 내용을 준비할지 고민을 하다가 2022년 저희 팀은 어떤 일을, 어떻게 해왔는지가 궁금해졌습니다. 과연 데이터에는 저희 팀의 업무 방식이 어떻게 기록되어 있을지 JIRA 데이터를 기반으로 분석해보고 팀에게 공유했던 과정을 정리하려고 합니다.

Note
JIRA 는 Atlassian 에서 제공하는 프로젝트 관리 및 업무 협업 툴로써 애자일 기반의 업무 방식을 지향하는 회사에서 주로 사용하는 서비스입니다. 아래 내용은 JIRA 가 어떤 서비스인지 알고 있다는 전제 하에 작성되었습니다.

---

분석 목적

아래 분석 목적을 이뤄보고자 데이터를 분석했다.

• 2022년도에 어떤 프로젝트를 수행했고, 핵심 프로젝트는 어떤 것이 있었는지?
• 개발자별 업무 스타일은 어떤지?
• 팀 내부 협업(프론트엔드-백엔드, PO-개발자 등)은 어떻게 이뤄졌는지?

데이터를 분석하기 전에는 항상 그 목적이 뚜렷해야 한다고 생각한다. 이 분석을 왜 해야 하는지? 찾아내고자 하는 정보는 무엇인지? 등에 대한 고민을 해야 한다. 데이터가 충분하지 않아서 분석하지 못할지라도..

데이터 분석 과정

대부분의 데이터 분석의 과정이 비슷하듯, 아래 흐름으로 데이터를 분석했다.

데이터 추출 > 데이터에 대한 이해 > 전처리 (파생 변수 생성) > 분석 > 리포팅 (시각화)

• 데이터 추출: JIRA 에서 제공하는 데이터를 엑셀 형태로 추출
• 데이터에 대한 이해: 어떤 필드가 존재하는지 파악하고, 분석을 위한 주요 필드를 설정
• 전처리: 분석에 사용하지 않거나 필요없는 데이터 삭제, 분석을 위한 파생 변수 생성
• 분석: 엑셀을 활용하여 데이터를 분석
• 리포팅: 결과를 알맞은 시각화 형태로 변경하여 팀에게 리포팅

데이터 추출하기

JIRA 에 등록되어 있는 모든 티켓은 "이슈" 탭에서 확인이 가능하다. 이 데이터를 파일 형태로 만들어야 분석을 할 수 있는데, JIRA 에서는 다행히도 "이슈 내보내기" 기능을 제공하고 있었다. "Excel CSV 내보내기(모든 필드)" 기능을 활용해서 엑셀 파일을 다운받았다.

JIRA 이슈 탭 > 이슈 내보내기 > Excel CSV 내보내기(모든 필드)

2022년 1월 1일부터 2022년 12월 31일 사이에 생성된 티켓을 기준으로 모두 추출했다.

데이터를 추출해보니 이슈가 1,000개까지 밖에 추출이 안되어 한번에 전체 데이터를 추출할 수 없었다. 그래서 1년 데이터를 한번에 추출하지 않고, 데이터를 분기로 나눠 추출한 뒤 4번에 걸쳐 추출했다.

데이터에 대한 특성 이해하기

업무를 위해 매번 JIRA 를 활용하긴 하지만 엑셀 형식으로 데이터를 추출해본 적은 없다. 그래서 어떤 필드가 포함되어 있는지 먼저 확인을 했고, 추출한 엑셀 파일 기준 154개의 필드가 존재했다.

1. 동일한 의미를 가지고 있는 필드

JIRA 티켓에 이렇게 많은 데이터가 포함되어 있었나? 하며 어떤 필드가 있는지 확인을 해보았다. 동일한 의미를 가지고 있는 필드가 2개 이상 존재하는 경우가 있었다. JIRA 는 여러 명의 "지켜보는 사람"을 표현하기 위해 복수 개의 필드를 만들어 엑셀 형태로 제공하는 듯 했다. (확인해보니 추출된 티켓 중 "지켜보는 사람"이 5명이나 되는 티켓이 존재했다.)

2. 의미 없는 필드

첨부 파일, 이슈 링크 등 분석에 필요없는 필드가 존재한다는 것을 알게 되었다.

전처리하기

동일한 의미를 가지고 있는 복수 개의 필드를 하나의 필드로 통합하여 필드를 정리하고, 분석용 필드만을 따로 분리해냈다. 처음에는 총 154개의 필드가 존재했는데, 분석용 필드는 총 17개가 되었다.

분석용 필드

분석용 필드는 의미있는 필드로 최대한 많이 뽑아내려고 했고, 그 기준은 다음과 같다.

• 유의미한 정보를 제공하는 필드는 선택 (예: 이슈키, 이슈유형, 보고자, 작성자, 설명 등)
• 결측치 (null) 의 비율이 적은 필드는 선택
• 날짜와 관련된 필드 선택 (데이터의 흐름/프로세스를 볼 수 있기 때문)
• 동일한 데이터로만 구성되어 있는 필드는 제거

파생 변수 생성

파생 변수는 JIRA 에서 제공하지 못하는 정보로 팀원의 업무 포지션에 대한 필드를 만들었다. 우리 팀은 백엔드, 프론트엔드 개발자와 QA, PO 등 함께 일하는 직군이 다양하여 직군별 업무 스타일을 파악하기 위해 작업자에 따라 업무 포지션 정보를 추가했다.

데이터 통합

그리고 분기로 나눠서 데이터를 추출했었는데, 이 과정에서 하나의 데이터로 통합했다.

데이터 분석하기

정확한 데이터를 노출하기 어렵기 때문에 가짜 데이터를 활용했습니다.
데이터를 분석하는 방법, 방향만 봐주세요 :)

분석 1. 2022년도에 어떤 프로젝트를 수행했고, 핵심 프로젝트는 어떤 것이 있었는지?

스프린트 기초 통계

2022년도에 우리 팀은 약 30개 정도 스프린트를 수행했고 약 1,700여개의 티켓을 등록했다 (완료 유무와는 무관). 우리 팀은 1 스프린트를 2주 단위로 설정하고 있기 때문에 1년 52주에 데이터가 얼추 맞다는 것을 확인할 수 있었다. 스프린트 (2주) 기간동안 평균적으로 약 60개의 티켓이 등록되었고 최대 100개, 최소 20개가 등록되는 스프린트도 있었다.
특이 패턴으로는 티켓이 많이 등록되는 스프린트가 있으면 그 뒤로 2-3주 정도는 티켓이 점점 적게 등록된다는 점이었다. 이를 통해 우리 팀은 큰 프로젝트를 시작하기에 앞서 플래닝된 모든 티켓을 등록해두고 작업하는 경향이 있다는 것을 데이터를 통해 알 수 있었다.

스프린트별 티켓 상태

등록된 30개의 스프린트 중 KTLO, Bug 를 관리하기 위한 스프린트를 제외하고 일반적인 스프린트에 등록된 티켓은 90% 이상 종료처리 되었다. 이를 통해 JIRA 를 활용한 스프린트 관리가 잘 되고 있음을 확인할 수 있었다.

종료 처리: 작업이 완료되어 배포되거나, 취소된 작업에 대한 처리

에픽

30-40개 사이의 에픽이 등록되었고 각 에픽은 팀에서 진행했던 각 프로젝트를 대표했다. 100개 가까이 되는 에픽도 존재했으며 10개 내외의 작은 규모의 에픽도 존재했다. 큰 규모의 에픽은 역시나 여러 팀이 모여 함께 진행했던 대규모 프로젝트였고 대표적으로 NFT, 스타일 탭 등이 있다.

회고를 진행하며 우리 팀이 수행했던 에픽들에 대해 다시금 살펴보니 기록이 새록새록 나며 "그땐 그랬지.." 와 같이 회상할 수 있는 시간이어서 뜻깊었다.

스프린트에 따른 에픽별 등록 티켓 개수

다음과 같이 테이블을 구성해두고 데이터를 바라봤다. 세로축에는 스프린트, 가로축에는 에픽, 그리고 각 cell 에는 스프린트에 그 에픽과 관련된 티켓이 생성된 개수를 표현했다.

	에픽 1	에픽 2	에픽 3
스프린트 1	10	10
스프린트 2		15	25
스프린트 3			20
...	...	...	...

이 테이블은 크게 스프린트 관점과 에픽 관점에서 데이터를 바라볼 수 있는데, 스프린트 관점에서 데이터를 바라보면 하나의 스프린트에 얼마나 많은 에픽이 함께 진행되는지를 알 수 있다. 우리 팀은 인원도 많고 해야할 작업도 많은 팀이어서 한 스프린트에 3-5개 정도의 에픽을 평균적으로 처리했다. 특정 스프린트에는 티켓이 거의 등록되지 않은 적이 있었는데, 그 땐 내부 회의를 통해 쉬어가는 스프린트로 정하고 대부분 KTLO 에 리소스를 할당했던 적이었다.
에픽 관점에서도 데이터를 바라볼 수 있는데, 하나의 에픽이 완료되려면 얼마나 많은 스프린트가 필요한지를 파악할 수 있다. 프로젝트 규모에 따라 다르겠지만 보통 3개의 스프린트 (즉 6주)가 필요했고 스프린트가 지나감에 따라 에픽이 잘 마무리되며 넘어가는 형태를 보였다. 에픽이 마무리되지 않고 질질 끌리는 형태라면 여러 스프린트에 걸쳐 데이터가 산발되었을텐데, 그런 패턴은 보이지 않았다. 거의 하반기 스프린트 내내 티켓이 등록된 특이 패턴의 에픽이 있었는데, 확인해보니 실제로 하반기 내내 진행한 QA 프로젝트였다.

분석 2. 개발자별 업무 스타일은 어떤지?

우리 팀은 총 15명의 작업자가 있으며 프론트엔드 개발자, 백엔드 개발자, QA 엔지니어로 구성되어 있다. 평균적으로만 보면 작업자별 1년동안 약 100개 가까운 티켓을 처리했다.

프론트엔드 개발자

연차가 높을 수록 더 많은 티켓을 처리하는 패턴을 보였다. 이런 패턴이 보이는 이유로는 프론트엔드 특성상 KTLO 관련 티켓이 많다는 점, 연차에 따른 업무 수행 능력이 있었다. (그리고 가장 많은 티켓을 수행한 프론트엔드 개발자 분은 원래 일을 많이 하시는 분으로 소문난..)

백엔드 개발자

백엔드에서는 특이하게 연차가 가장 낮은 개발자가 가장 많은 티켓을 처리했는데, 평소에 KTLO 와 Bug 관련 티켓을 많이 처리한 분이긴 했다. 또한, 백엔드 개발자들은 연초부터 계속 같은 팀에서 업무를 수행한 것이 아니어서 정확한 원인을 파악하기는 어려웠다.

프론트엔드, 백엔드 개발자의 작업 시간

보통 플래닝을 할 때, 각 Task 별 Estimation 을 하게 되는데 그 데이터를 분석해보고자 했다. 프론트엔드 개발자는 평균 하나의 Task 를 수행하기 위해 약 1.2일의 Estimation 을 예상하는 반면 백엔드 개발자는 평균 1.6일의 Estimation 을 예상했다. 이에 대한 이유로는 프론트엔드와 백엔드 개발자 간 성향 차이로 분석을 했는데, 프론트엔드는 업무 대비 개발 리소스가 부족해 Estimation 을 타이트하게 설정하는 경향이 있었고 백엔드는 시간이 좀 더 걸려도 버퍼를 잡고 Estimation 하는 개발자들로 구성되어 있다.
평소에 생각했던 각 개발자의 성격이 데이터로 표현되는 것이 재미있었다. 평소에도 어떤 개발자분은 여유가 있어 보였는데 데이터에서 가장 넉넉한 Estimation 을 잡는 분이었다 (1.8일). 개인적으로 백엔드 개발자임에도 난 1.2일이어서 좀 더 천천히 일해도 되지 않을까 생각했다.

분석 3. 팀 내부 협업(프론트엔드-백엔드, PO-개발자 등)은 어떻게 이뤄졌는지?

데이터 중 "보고자"와 "작업자" 필드가 있었는데, 이를 활용하여 소셜 네트워크 분석을 할 수 있다. 어떤 작업자가 주로 티켓을 생성하는지, 주로 작업하는지, 누가 누구에게 티켓을 생성하여 전달하는지 등을 파악할 수 있다.
데이터는 아래와 같은 테이블 형태로 만든다. 세로 축은 보고자, 가로 축은 작업자로 두고 각 cell 에는 그 빈도를 입력한다. 예를 들어, 보고자 A 는 티켓을 만들어 자기 자신에게 티켓을 할당한 개수가 55개에 달한다.

	작업자 A (백엔드)	작업자 B (프론트엔드)	작업자 C (PO)	...
보고자 A (백엔드)	60	50	0
보고자 B (프론트엔드)	1	30	0
보고자 C (PO)	20	20	0
...

이 데이터를 분석하는 방법은 다음과 같다.

• 한 명의 보고자가 여러 명의 작업자에게 티켓을 할당한다 -> 주로 매니저, PO 의 역할을 수행하는 작업자임을 나타냄 (업무 지시)
• 한 명의 작업자가 여러 명의 보고자에게 티켓을 할당 받는다 -> 타 작업자와 협업을 많이 하는 작업자에게서 나타남 (KTLO 와 버그 티켓을 처리)

우리 팀에서는 다음과 같은 특성을 파악할 수 있었다.

• 주로 본인이 티켓을 생성하고 본인에게 할당하는 경우가 대부분임
• 프론트엔드-백엔드 개발자가 협업을 하는 프로젝트의 경우에는 주로 백엔드 개발자가 티켓을 생성하고 프론트엔드 개발자에게 할당을 함 (실제로도 이렇게 업무를 했다)
• 프론트엔드 개발자들은 KTLO 티켓 처리를 위해 다양한 보고자에게서 티켓을 할당받음

마무리하며

"데이터 분석" 이라는 것이 어려운 분석 개념을 활용하고, 복잡한 전용 분석 툴을 사용해야 하고, 멋진 시각화 툴을 꼭 사용해야 하는 것은 아니다. 평균, 표준편차 등 기초 통계에 대한 이해가 있고, 엑셀만 잘 활용해도 충분히 분석 목적을 달성하며 시작해볼 수 있다.
일단 시작하자!