지라(JIRA) 에픽(EPIC)과 KR(Key Results)

아틀라시안(Atlassian)의 이슈 및 프로젝트 소프트웨어인 JIRA

필자는 회사에서 업무를 스프린트 방식으로 진행을 했고, 목표관리는 OKR로 했다.

하지만 책에서 본 OKR 의 개념과 조직에서 사용하는 OKR을 바라봤을때 좀 이질감을 느끼고 있었다.

특히나 조직에서는 KR을 지라 에픽에 매핑해서 사용하고 있었는데, 몇년 동안은 아무생각이 없었기 때문에 이게 당연한줄 알았다.

하지만 막상 조직장이 되면서 애자일 추정(Estimation)에 대해서 공부를 하게 되었고, KR을 에픽으로 매핑하기에는 한계가 있다는 것을 깨달았다.

사실 구글링 해보면 비슷한 글들이 이미 많이 있다.

https://brunch.co.kr/@boi/9

OKR과 Jira Dashboard

 

보통 지라 에픽을 생성하면, 스프린트를 진행하면서 태스크 티켓을 만들면서 에픽을 매핑하게 된다.

https://learning.oreilly.com/library/view/agile-estimating-and/9780137126347/

Agile Estimating and Planning

애자일에서는 사이즈 추정이란 개념이 있다. 이는 어떤 일감(어떤 업무의 조그마한 단위)이 어느정도 걸릴지 추정하는 걸 말한다. 개발팀은 처음에는 어떤 일에 있어서 이 일이 얼마나 걸릴지 정확하게 하지 못한다. 하지만 어떻게 해도 정확할수 없다고 말한다. 처음에는 2~3개월 오차가 발생할 수 있지만, 시간이 지나고 개발팀이 업무에 익숙해지면서 자연스럽게 이 추정치도 점점 정확도가 올라간다고 한다(100%는 절대 안된다)

보통 우리는 어떤 에픽을 달성하기 위해서 태스크 티켓을 모두 만들어두지 않는다. 그렇기 때문에 이 에픽을 달성하려면 어느정도가 소요되는지 추정하기가 어렵다. 특히나 앞서 언급한대로 에픽이 KR이였다. 기본적으로 개발팀에서 추정이 가능하려면 어떤 목표나 결과가 아닌 구체적인 일감이어야 한다. 그렇기에 에픽이 된 KR을 가지고 추정이 어렵다. 다음의 예시를 보자.

반응형

---

목표(Objective)

• 소프트웨어 제품의 성능과 응답 속도를 획기적으로 개선한다

핵심 결과(Key Results)

1. 다음 분기 말까지 평균 응답 시간을 현재 200ms에서 100ms로 50% 감소시킨다.

---

KR을 보면 50% 감소시키기 위해서 개발팀 관점에서 어떤 일들을 해야하는지 알 수 없다. 단순히 목표/결과만 있을 뿐이다. 세부적으로 이 KR을 달성하기 위해서 어떤 일들을 해야하는지 사이즈 추정이 가능한 하위 무언가가 있어야 한다.

KR만을 보고 그때그때 태스크들을 발굴해서 할수도 있지만, 이렇게 해서는 업무 스케줄링이 어렵다. KR을 달성하기 위해서 어느정도의 시간과 노력이 투입되는지 개발팀 인원 전부가 이해하고 있어야 한다.

그러면 OKR로만 끝낼게 아니고 실질적인 일감을 리스트업해야한다. 다음과 같이 말이다.

1. 코드 최적화 및 리팩토링

2. 데이터베이스 쿼리 최적화

3. 캐싱 메커니즘 구현

이게 개발팀이 바라봐야할 실질적인 일감이다. 개발팀 모두는 이 일감들이 어느정도 걸릴지 추정을 해야한다. 그래야 1,2,3번을 모두 일정내에 할 수 있을지, 안된다면 어떤 부분을 간소화 할것인지, 남는다면 어떤 일감을 더 추가할 것인지 결정할 수 있다. 그리고 실제 구체적인 태스크들은 이 일감의 하위로 추가된다.

앞서 말한대로 KR이 에픽으로 매핑이 된다면, 저 일감을 지라에서 표현할 방법이 마땅치 않다. 스프린트에 해야하는 구체적인 업무는 태스크인데, 태스크에는 에픽만 넣도록 되어있다. 그렇기 때문에 KR을 에픽으로 매핑하는데 부적절하다는 것이다.

지라에는 에픽만 있는게 아니고, 스토리와 서브태스크도 있다. 이걸 활용해볼 수도 있다. 하지만 사용시나리오가 태스크와 다르고, 조직에서 이미 에픽과 태스크로만 통일해서 쓰고 있다면, 스토리와 서브태스크는 조직 프로세스 일관성 관점에서 많이 벗어나게 된다.

요약하자면, 일감이 바로 에픽이 된다. KR은 그냥 KR이다. 이를 따로 굳이 지라의 어떤 것에 매핑할 필요는 없다. 지라 플러그인으로 OKR이 있긴하지만 여기서도 KR은 KR이고 에픽이 일감이 된다.(간혹 KR 자체가 일감 1개로 나오는 경우도 있다. 그럴때 필자는 그냥 KR을 에픽으로 만들기도 한다. 헷갈릴수 있다 생각하겠지만 실제 적용했을 때 헷갈리지 않았다)

위에서 말한 세가지 일감이 바로 에픽이 되는 것이고, 이 일감으로 사이즈 추정을 하여 KR을 실질적으로 달성할 수 있는지 검토해야한다.

KR을 JIRA 의 어떤 다른 타입으로 생성해두고 해도 되지만, 상하위 조직 구조가 복잡할 때 상위 조직에서도 OKR을 작성해야하므로 꼬이는 상황이 발생할 수도 있다(예: 상위 조직에서 이니셔티브로 O를 생성했는고 KR을 에픽으로 만들어놔서 관리를 하는 경우)