기획자Sean

Jira에서 최선의 결과를 만들어내는 데 중요한 에픽, 스토리, 서브태스크 작성법

이전에 스크럼 리딩 경험이 없던 프로덕트 매니저(오너), 프로덕트 디자이너 혹은 테크 리더(개발자)가 스크럼을 책임지고 운영해야 하는 상황이 발생했을 때, 당황하는 경우 중 하나는 직접 에픽(Epic), 스토리(Story), 서브태스크(Sub-task)를 작성해야 하는 때에 발생합니다. (경험담입니다.)

모든 스크럼 팀원들이 움직이기 위해 보는 하나의 지도가 Epic, Story, Sub-task 라는 요소들이기 때문에 이를 어떻게 작성해야 논리적이고 직관적일 지 고민이 많이 되는 부분입니다.

물론 정해진 정답은 없습니다. 주어진 상황과 환경에 따라 잘 적응하는 것이 최선이지만 적응에 앞서 참고할만한 표준이 있다면 더 쉽게 적응할 수 있다고 생각하여 Epic, Story, Sub-task를 작성하는 방법에 대해 공부한 글을 정리해봅니다.

📌 에픽의 제목은 프로덕트 로드맵에 해당하는 내용으로 기술합니다. 이 때, '000으로서'라는 주체를 명시하는 것을 권장합니다. 그 이유는 해당 에픽의 출처와 목적, 맥락을 알 수 있도록 하기 위함입니다.

📌 에픽의 하위인 스토리의 제목을 작성할 때는 'UUU는(User/Who), PPP 할 수 있도록(Purpose/Why), AAA 하길 원한다(Action/What)'의 방식으로 기술하는 것을 권장합니다. 그 이유 역시 해당 스토리의 출처와 목적, 맥락을 알 수 있도록 하기 위함입니다.

📌 어떤 상황에서도 통하는 완벽한 방법은 없으며, 스크럼 팀이 스프린트를 진행하면서 비즈니스 목표를 잊지 않고 일이 되는 방향(방법)으로 꾸준히 나아가고 개선하는 것이 가장 중요합니다.

본 글 보러가기 :

Jira로 스크럼 & 스프린트 운영하기

인생 첫 스크럼 & 스프린트를 앞두고 잘하고 싶은 마음에 부담감이 컸던 예전 기억이 있습니다. 특히, 스크럼과 스프린트라는 방법론에 대한 명확한 가이드가 없는 상태로 진행했던 터라 더욱 막막한 기분이 들었던 거 같아요.

결국 첫 스프린트는 좌충우돌로 종료하면서 지식이나 경험이 부족한 주니어라도 보고 따라갈 수 있는 좋은 가이드가 있으면 좋겠다고 생각했습니다. 그래서 공부하고 정리한 내용 중 오늘은 Jira로 스크럼과 스프린트를 어떻게 운영하면 좋을지 적어보려 합니다.

Index
1️⃣ Jira 프로젝트 운영 원칙
2️⃣ Issue Type은 어떻게 설정하고 어떤 내용을 적어야 하는 지
3️⃣ Backlog 관리 방법
4️⃣ Sprint Board 구성하기
5️⃣ Sprint Schedule짜는 방법

📌 Product 별로 Jira project를 생성해서 Sprint를 운영함을 원칙으로 합니다. Product의 특성에 따라 Project의 템플릿은 달라질 수 있으나, 기본적으로 스크럼 형태의 보드 운영을 기본으로 합니다.

📌 Epic(에픽)은 Product의 로드맵으로 관리되는 단위를 Epic으로 생성하고 구체적인 마일스톤과 그에 대한 일정이 담긴 요소로 지정하면 됩니다.

📌 Story(스토리)는 Product를 이용하는 사용자에게 제공하는 기능을 서술하는 단위를 의미합니다. Sprint 1회 안에서 개발 완료 및 사용 가능한 기능의 최소 단위로 Story를 생성하도록 권장합니다.

본 글의 링크는 아래 링크드인 업데이트의 댓글에 추가했습니다!

어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 2

이전 업데이트에서 제가 스크럼을 탄탄하게 운영하기 위해 이론부터 공부하기 시작한 과정과 스크럼의 정의, 스크럼 팀이 어떻게 구성되는지 그리고 각 구성원들의 역할에 대해서 쓴 '어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1'을 공유했었습니다.

Part 2에서는 스크럼을 실질적으로 운영하는 방식과 스크럼의 산출물(=개선된 제품)에 대해 적어보았습니다.

📌 스크럼이 자동차라면 스프린트는 엔진이라고 비유할 수 있을 것 같습니다. 스프린트에서는 2주~4주 정도의 기간으로 고정된 길이의 이벤트로, 스프린트 기간 동안 스프린트 플래닝, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고를 포함하여 제품의 목표를 달성하기 위한 모든 작업을 수행하게 됩니다.

📌 스프린트 플래닝은 스프린트 동안 수행할 작업을 선정하는 이벤트로 스크럼 팀 전체가 참여하여 플래닝합니다. 이때, 프로덕트 오너는 프로덕트 목표를 달성하기 위해 가장 중요하면서 우선순위가 높은 아이템들을 나열하고 해당 아이템들이 프로덕트 목표에 어떻게 연결되는 지를 논의할 수 있도록 준비해야 합니다.

📌가치의 증가분(산출물)
가치의 증가분은 최종적인 프로덕트 목표를 달성하기 위한 디딤돌입니다. 매 스프린트마다 스크럼 팀이 만들어낸 가치의 증가분은 누적되어 증가하여 전체 가치의 총량을 크게 만듭니다.

📌 2주 스프린트 예시
1️⃣ 스프린트 플래닝을 통해 이번 스프린트에 진행할 백로그를 선정하고, 백로그를 완료하기 위한 작업 목록을 쪼개어 배분합니다.
2️⃣ 백로그가 바로 기능 개발이 가능할 정도로 구체화되었다면 백엔드부터 설계 및 개발을 시작합니다. 프론트엔드는 디자인 작업물이 나온 뒤 작업이 가능하기 때문에 상대적으로 작업 시작 시점이 늦을 수 있습니다.
3️⃣ 스프린트 기간 동안 데일리 스크럼을 통해 지속적인 커뮤니케이션으로 목표 달성을 위한 최적화 작업을 진행합니다.
4️⃣ 백엔드와 프론트엔드 모두 개발이 완료되면 QA를 진행합니다.
5️⃣ 스프린트 리뷰를 통해 스크럼 팀원과 이해관계자가 실제 동작하는 백로그를 확인하고 다음 스프린트에 대해 논의합니다.
6️⃣ 스프린트 회고를 통해 이번 스프린트에서의 KPT를 논의하고 스프린트를 종료합니다.

본 글 링크는 아래 첨부합니다.

어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1

안녕하세요, 기획자Sean 입니다.

스크럼을 직관으로 운영하면서 발생하는 비효율을 개선하기 위해 이론 공부를 하고 이를 적용시켜 배운 점들을 이론과 함께 정리하고 있는 글을 링크드인에 발행했습니다.

많은 관심 부탁드려요 :)

어깨 너머로 배운 스크럼(Scrum), 제대로 알아보기 Part 1

저는 서비스 기획자로 시작해서 현재는 Product Manager로 총 6년동안 일을 하면서 6개의 프로덕트를 런칭하고 운영해오고 있습니다.(사이드 프로젝트는 제외했습니다.) 프로덕트를 개발하면서 워터폴과 애자일 환경을 모두 경험해보았고, 스크럼 팀 역시 다회 운영하고 있습니다.

하지만 고백컨데 주니어 시절의 저는 경험 기반의 직관에 의존하는 Product Manager이자 기획자였습니다. 고객에게 제품의 핵심 가치를 잘 전달하기 위해 필요한 개선점들을 백로그화하고 스프린트를 운영하긴 했지만, 이 제품 개발 프레임워크를 이론적으로 공부한 적은 없었죠.

이런 상황에서 실제 스프린트를 운영하다보니 프로세스적으로 비효율이 발생했고 심지어 비효율이 누적되는 것이 체감되기 시작했습니다. 그리고 몇 번의 이직을 하면서 느낀 점은 스크럼(Scrum)이라는 프레임워크를 제대로 교육하고 정착시켜 스크럼 방식을 통해 얻고자 하는 효과를 얻고있는 회사는 극히 드물다는 것이었습니다.

이 글은 제가 앞서 체감하기 시작한 문제를 해결하기 위해 스크럼(Scrum)을 이론적으로 공부하고 실제 적용해 보면서 배운 점들을 정리하는 동시에 팀에게 스크럼의 목적과 효과, 프로세스를 가이드하기 위해 쓰는 글입니다.

📌 스크럼을 풀어서 설명하면 '팀을 중심으로 문제에 대한 해결 방법을 고객 가치 관점의 솔루션으로 만들어내는 프로세스 프레임워크'라고 할 수 있습니다. 이 프로세스를 날씬하고 날렵한 사고와 이터레이션을 통한 지식 습득(린 씽킹), 이를 통한 반복적인 개선하는 방식(경험주의)으로 운영하면 이상적인 스크럼에 가깝지 않을까 생각합니다.

📌 저는 5명, 10명, 15명 규모의 스크럼 팀을 운영하면서 10명 내외의 크기가 스크럼의 이상적인 팀 크기라고 확신하게 되었습니다. 10명의 크기일 때, 상대적으로 소통이 원활하여 의사결정이 민첩하면서 규모가 있는 가치의 증가분도 만들어 낼 수 있었기 때문입니다.

📌 스크럼 프로세스
1️⃣ 프로덕트 오너는 복잡한 문제를 해결하기 위한 업무를 우선순위에 따라 프로덕트 백로그에 정렬한다.
2️⃣ 스크럼 팀은 선택한 업무를 스프린트 동안 가치의 증가분 Increment of value 으로 만들어 낸다. (*증가분은 스크럼팀이 스프린트 동안 완료한 업무로서 기존 프로덕트에 새로 더해지는 프로덕트의 새로운 부분을 의미)
3️⃣ 스크럼 팀과 이해관계자들은 결과물을 점검하고 다음 스프린트를 위하여 조정을 한다.
4️⃣ 반복한다.

본 글의 링크는 아래 첨부합니다.