기획자의 작업대

Jira 스프린트 계획, 기획자가 준비할 것 Jira 스프린트 계획, 기획자가 준비할 것 스토리 포인트 추정을 끝내고 개발을 시작했는데, “이메일 확인에 실패하면 어떻게 처리하나요?”라는 질문이 나옵니다. 화면은 준비됐지만 예외 정책이 비어 있어 작업이 멈추는 상황입니다. 저는 기획 관점에서 스프린트 계획을 볼 때, 티켓의 개수보다 팀이 같은 완료 모습을 떠올릴 수 있는지를 먼저 살펴보겠습니다. 이번 글에서는 가상의 회원가입 개선 사례로 회의 전에 준비할 정보와 회의에서 합의할 범위를 정리합니다. 이 글은 2026.10 기준으로 작성되었으며, 최신 내용은 공식 문서를 확인하시기 바랍니다. Jira Cloud의 Scrum 운영을 기준으로 설명하며, 메뉴와 필드는 관리 방식·권한·팀 설정에 따라 달라질 수 있습니다. 📌 목차 스프린트 계획에서 기획자의 역할 작업 목록보다 목표 먼저 정하기 요구사항 준비 상태 확인하기 우선순위와 의존 관계 살펴보기 팀과 이번 개발 범위 합의하기 합의 내용을 Jira에 기록하기 실무 팁 3가지 자주 묻는 질문 다음 회의 전에 할 일 1. 스프린트 계획에서 기획자는 무엇을 준비할까요? 기획자는 팀이 판단할 수 있도록 사용자 목적과 요구사항을 명확히 합니다. 무엇을 만들고 왜 필요한지, 어떤 제약이 있는지를 설명할 수 있어야 합니다. Scrum Guide는 스프린트 계획에서 가치, 이번에 완료할 작업, 수행 방법을 논의하도록 설명합니다. 목표는 팀이 함께 정하고, 선택할 작업과 구현 계획에는 개발자의 판단이 필요합니다. 기획자가 일정과 작업량을 혼자 확정하는 방식은 피해야 합니다. [1] 또한 ‘기획자’라는 직함이 곧 Product Owner를 의미하지는 않습니다. 우선순위 결정 권한이 누구에게 있는지 먼저 확인하고, 기획자는 맡은 범위에서 요구사항 설명과 의사결정을 지원합니다. 누구의 어떤 문제를 해결하는지 설명합니다. 우선순위의...

Jira 스토리 포인트, 기획자가 참여하는 법 Jira 스토리 포인트, 기획자가 참여하는 법 📌 목차 2점과 5점 사이에서 아무 말도 못 했던 순간 스토리 포인트는 시간이 아니라 상대적 난이도다 이메일 인증 스토리, 2점과 5점이 갈린 이유 추정 회의에서 기획자가 하는 3단계 실무 팁 3가지 마무리 FAQ 1. 2점과 5점 사이에서 아무 말도 못 했던 순간 회원가입 이메일 인증 스토리를 추정하는 회의였습니다. 개발자 한 분은 2점을 불렀고, 다른 한 분은 5점을 불렀습니다. 저는 개발 얘기라 제가 낄 자리가 아니라고 생각해서 그냥 지켜보기만 했습니다. 나중에 돌아보니 그 순간이 가장 중요한 순간이었습니다. 두 사람의 점수가 왜 달랐는지 물어봤다면, 스토리 설명에 빠져 있던 정보를 그 자리에서 채울 수 있었을 겁니다. 이번 글에서는 기획자가 추정 회의에서 할 수 있는 역할을 정리해보겠습니다. 2. 스토리 포인트는 시간이 아니라 상대적 난이도다 등산 코스 난이도에 비유하면 이해가 쉽습니다. "초급, 중급, 고급"은 실제 거리가 몇 km인지를 뜻하지 않습니다. 오르면서 체감하는 난이도를 나타냅니다. 스토리 포인트도 마찬가지입니다. "2점, 5점"은 몇 시간이 걸리는지가 아니라 팀이 느끼는 상대적인 복잡도입니다. 그래서 점수 자체보다 "왜 그 점수를 골랐는지"에 더 많은 정보가 담겨 있습니다. 기획자가 참여할 자리는 점수를 매기는 곳이 아니라, 그 이유를 듣고 놓친 부분을 찾는 곳입니다. 3. 이메일 인증 스토리, 2점과 5점이 갈린 이유 다시 이메일 인증 스토리로 돌아가 보겠습니다. 2점을 부른 개발자는 "이전 프로젝트에서 비슷한 인증 기능을 만들어본 적이 있다"고 했습니다. 5점을 부른 개발자는 ...

Jira 워크플로우, Done 기준 맞추는 법 Jira 워크플로우, Done 기준 맞추는 법 기획자의 작업대 · Jira 실무 가이드 📌 목차 회원가입 스토리가 Done인데 QA는 몰랐던 순간 상태값은 정의가 아니라 합의다 Done을 둘러싼 동상이몽, 회원가입 사례 우리 팀 상태값 맞추는 3단계 실무 팁 3가지 마무리 FAQ 1. 회원가입 스토리가 Done인데 QA는 몰랐던 순간 에픽 쪼개기 글에서 다뤘던 회원가입 이메일 인증 스토리가 있었습니다. 개발자가 코드를 배포하고 상태를 Done으로 바꿨는데, QA 담당자는 그 스토리를 아직 테스트해본 적도 없었습니다. "이거 Done 아니었어요?"라는 제 질문에 QA는 "저는 아직 시작도 안 했는데요"라고 답했습니다. 같은 상태값을 두고 서로 다른 걸 완료라고 생각하고 있었던 겁니다. 이번 글에서는 이런 상황을 막기 위해 상태값 기준을 팀이 어떻게 맞추면 되는지 정리해보겠습니다. 2. 상태값은 정의가 아니라 합의다 To Do, In Progress, Done 같은 상태 이름은 Jira가 기본으로 제공하다 보니 이미 정해진 뜻이 있는 것처럼 보입니다. 하지만 그 이름이 정확히 어느 시점을 가리키는지는 Jira가 정해주지 않습니다. 팀이 합의해야 하는 약속입니다. 릴레이 경주에 비유하면 이해가 쉽습니다. 바통을 넘기는 지점이 팀마다 다르면, 다음 주자는 언제 뛰기 시작해야 할지 알 수 없습니다. Done이라는 상태도 마찬가지입니다. 누군가에게는 배포가 끝난 시점이고, 누군가에게는 검증까지 끝난 시점입니다. 이 지점을 맞추지 않으면 계속 같은 오해가 반복됩니다. 3. Done을 둘러싼 동상이몽, 회원가입 사례 앞서 겪은 상황을 역할별로 풀어보면 아래처럼 서로 다른 기준으로 Done을 이해...

AI 시대 기획자, 대체되지 않는 법 3가지 AI 시대 기획자, 대체되지 않는 법 3가지 📌 목차 "이거 AI가 다 하지 않아?"라는 말을 들었을 때 AI가 대체하는 영역 vs 대체 못 하는 영역 실제 사례로 보는 경계선 실무 팁 3가지 마무리 FAQ 1. "이거 AI가 다 하지 않아?"라는 말을 들었을 때 얼마 전 회의에서 개발자 한 분이 "이 정도 기획 문서는 이제 AI가 초안 정도는 다 뽑아주지 않냐"고 농담 반 진담 반으로 말한 적이 있습니다. 그 자리에서는 웃으며 넘겼지만, 집에 오는 길 내내 그 말이 계속 걸렸습니다. 실제로 요구사항 몇 줄만 넣어도 PRD 뼈대 정도는 순식간에 나오는 시대이니, 완전히 틀린 말도 아니었기 때문입니다. 그날 이후로 "그럼 나는 뭘 해야 하지"라는 질문을 스스로에게 계속 던지게 됐고, 그 정리 과정을 이번 글에 담아봤습니다. 2. AI가 대체하는 영역 vs 대체 못 하는 영역 AI가 잘하는 일과 못하는 일을 나눠보면 생각보다 경계가 뚜렷합니다. AI는 정리, 요약, 초안 생성, 유사 사례 리서치처럼 패턴이 있는 반복 작업에 강합니다. 요구사항 문서의 형식을 갖추거나, 회의록을 정리하거나, 비슷한 기능의 화면 구성을 나열하는 일은 이미 상당 부분 대신할 수 있습니다. 반면 AI가 대신하기 어려운 영역도 분명합니다. 이번 분기에 어떤 기능을 먼저 개발할지 트레이드오프를 판단하는 일, 개발팀과 디자인팀 사이에서 서로 다른 이해관계를 조율하는 일, 그리고 그 결정에 대해 책임을 지는 일입니다. 이 세 가지는 우리 조직의 맥락과 정치적 지형, 과거의 실패 경험까지 알아야 판단할 수 있는데, AI는 이런 맥락을 갖고 있지 않습니다. 결국 AI는 "무엇을 만들지"에 대한 ...

Jira 에픽 쪼개기, 스토리 나누는 기준 Jira 에픽 쪼개기, 스토리 나누는 기준 📌 목차 회원가입 스토리 하나가 계속 늘어났던 순간 크기가 아니라 완결성으로 나눈다 실제 사례로 보는 회원가입 에픽 쪼개기 우리 팀 에픽에 적용하는 3단계 실무 팁 3가지 마무리 FAQ 1. 회원가입 스토리 하나가 계속 늘어났던 순간 회원가입 기획서를 쓸 때 화면 하나, 스토리 하나면 충분하다고 생각했습니다. 그런데 개발 단계에 들어가니 인증 방식, 오류 처리, 약관 동의 같은 조건들이 하나씩 튀어나오면서 스토리가 계속 늘어났습니다. 처음 잡은 스토리 하나로는 감당이 안 됐고, 그제야 에픽을 어떻게 쪼개야 하는지 제대로 고민하게 됐습니다. 돌아보면 문제는 쪼개는 타이밍이 아니라 쪼개는 기준이 없었다는 것이었습니다. 이번 글에서는 에픽을 스토리로 나눌 때 크기가 아니라 어떤 기준으로 잘라야 하는지, 그 기준을 실제 사례에 적용하는 과정까지 정리해보겠습니다. 2. 크기가 아니라 완결성으로 나눈다 에픽을 스토리로 쪼개라는 말을 들으면 흔히 "더 작게 나누면 된다"고 생각합니다. 하지만 작게 나누는 것과 제대로 나누는 것은 다른 문제입니다. 작게만 나누면 서로 의존하는 조각들이 생기고, 하나가 늦어지면 나머지도 같이 멈춥니다. 레고에 비유하면 이해가 쉽습니다. 에픽은 완성된 세트 전체이고, 스토리는 그 세트 안에서 조립을 멈춰도 그 자체로 서 있는 하나의 구조물입니다. 바퀴 하나, 창문 하나 같은 낱개 블록은 태스크에 가깝습니다. 스토리를 나눌 때 기준으로 삼아야 할 것은 크기가 아니라 "혼자서도 서 있을 수 있는가"입니다. 2일차 용어 정리 글 에서 "회원가입 개선"을 에픽의 예시로 든 적이 있습니다. 그 글이 에픽과 스토리가 무엇인지 정의하는 ...

Jira 기획자 가이드, 8편을 순서대로 읽는 법 Jira 기획자 가이드, 8편을 순서대로 읽는 법 기획자의 작업대 · Jira 시리즈 허브 📌 목차 다시 Jira로 돌아와서 헷갈렸던 이야기 8편을 5단계로 나눈 지도 내 상황에서 어느 글부터 볼까 개정 현황과 알아둘 점 실무 팁 3가지 마무리 FAQ 1. 다시 Jira로 돌아와서 헷갈렸던 이야기 예전에 Jira를 쓰면서 관련 글을 정리해 둔 적이 있습니다. 한동안 Jira를 쓰지 않는 프로젝트에 있다가 다시 Jira를 쓰는 프로젝트로 돌아오니, 아는 도구였는데도 또 헷갈렸습니다. 그래서 예전 글을 지금의 Jira Cloud 웹 버전 기준으로 다시 점검하고, 8편을 한 번에 볼 수 있는 지도로 묶었습니다. 이 글은 8편을 처음부터 끝까지 읽으라고 만든 목차가 아닙니다. 지금 막힌 지점에서 필요한 글로 바로 들어가도록 길을 안내하는 글입니다. 2. 8편을 5단계로 나눈 지도 지하철 노선도를 떠올려 보시면 쉽습니다. 모든 역을 외우는 사람은 없고, 지금 있는 역과 가야 할 역만 찾으면 됩니다. 7일 시리즈가 한 개의 노선이라면, Confluence 연동 글은 다른 노선으로 갈아타는 환승역에 해당합니다. 단계 글 한 줄 요약 ① 이해 Jira 입문 Jira가 어떤 일을 하는 도구인지, 상태와 우선순위 같은 기본 구조를 기획자 눈높이로 정리했습니다. 2일차 용어 정리 Issue, Epic, Story, Task가 각각 무엇을 가리키는지 구분합니다. ② 운영 3일차 스프린트·백로그 "요청이 있다"와 "개발이 시작됐다"가 왜 다른지, 두 개념의 차이로 설명합니다. ...

피그마 학습, 기획자는 어디까지 배울까 피그마 학습, 기획자는 어디까지 배울까 기획자의 작업대 · 실무 가이드 처음 피그마를 켰을 때, 왼쪽 사이드바에 늘어선 아이콘들을 보고 뭐부터 눌러야 할지 몰라 한참을 멍하니 있었던 기억이 있습니다. 그 주 주말에 유튜브 강의를 몇 개나 정주행했는데, 막상 실무에 들어가 보니 배운 내용을 모두 사용하지는 않았습니다. 반대로 어떤 동료는 딱 필요한 기능 몇 가지만 익히고도 개발자, 디자이너와의 커뮤니케이션에서 전혀 막힘이 없었습니다. 그 차이를 겪고 나서, "얼마나 배워야 충분한가"에 대한 기준이 사람마다 다르다는 걸 알게 됐습니다. 이번 글에서는 기획자 입장에서 피그마를 어디까지 배워야 실무에 지장이 없는지, 단계별로 정리해보겠습니다. 📌 목차 피그마 학습이 끝없이 느껴지는 이유 기획자를 위한 3단계 학습 로드맵 실무 팁 3가지 마무리 FAQ 1. 피그마 학습이 끝없이 느껴지는 이유 피그마 강의나 공식 문서를 펼쳐보면 배울 게 끝이 없어 보입니다. 컴포넌트, 오토레이아웃, Variables, 플러그인, 디자인 시스템 구축까지 목록이 계속 이어지기 때문입니다. 이건 피그마가 하나의 툴이 아니라 성격이 다른 두 가지 역할을 한 앱 안에 담고 있기 때문입니다. 하나는 화면을 그리고 다듬는 "디자인 제작" 기능이고, 다른 하나는 그 결과물을 팀과 주고받는 "협업" 기능입니다. 자동차에 비유하면 운전면허와 레이싱 기술의 차이와 비슷합니다. 도로에서 안전하게 이동하는 데 필요한 건 면허 수준의 지식이지, 트랙에서 최고 속도로 코너를 도는 레이싱 기술이 아닙니다. 둘 다 같은 차를 다루지만, 훈련 목적과 범위가 완전히 다릅니다. 기획자에게 피그마가 끝없이 느껴지는 이유는, 이 둘을 구분하지 않고...

PPT 기획자가 피그마에서 자주 하는 실수 7가지 PPT 기획자가 피그마에서 자주 하는 실수 7가지 기획자의 작업대 · 실무 가이드 📌 목차 슬라이드 감각 그대로 피그마를 켰던 날 PPT와 피그마는 애초에 만들어진 목적이 다르다 PPT 기획자가 자주 하는 실수 7가지 실무 팁 3가지 마무리 FAQ 1. 슬라이드 감각 그대로 피그마를 켰던 날 처음 피그마로 화면 기획서를 만들던 날, 저는 습관대로 화면을 한 장씩 새로 그렸습니다. PPT에서 슬라이드를 복제하고 텍스트만 바꾸던 방식 그대로, 피그마에서도 프레임을 복사해서 문구만 고쳐나갔습니다. 문제는 열 번째 화면쯤에서 터졌습니다. 버튼 색을 하나 바꿔야 하는데, 그 버튼이 들어간 화면이 몇 개인지조차 파악이 안 됐습니다. 결국 화면을 하나하나 열어서 같은 버튼을 스무 번 넘게 고쳐야 했습니다. 디자이너가 그 모습을 보고 "컴포넌트로 만들어두지 그러셨어요"라고 했을 때, 저는 그게 정확히 뭘 의미하는지도 몰랐습니다. 이번 글에서는 저처럼 PPT 감각으로 피그마를 시작한 기획자가 자주 걸리는 실수 7가지를 정리해보겠습니다. 2. PPT와 피그마는 애초에 만들어진 목적이 다르다 PPT는 한 장 한 장이 독립된 결과물입니다. 슬라이드끼리 데이터를 공유하지 않아도 발표라는 목적은 그대로 달성됩니다. 반면 피그마는 화면끼리 서로 연결되고 재사용되는 것을 전제로 설계된 도구입니다. 비유하자면 PPT는 낱장으로 인쇄하는 전단지에 가깝고, 피그마는 부품을 조립해서 완성하는 가구 설계도에 가깝습니다. 전단지는 한 장씩 새로 디자인해도 상관없지만, 가구는 같은 나사와 경첩을 여러 군데서 재사용해야 조립도 수리도 쉬워집니다. 이 차이를 모르고 PPT 하던 방식 그대로 피그마를 쓰면, 화면은 늘어나는데 관리는 점점 힘들어지는 상황을...

피그마·Jira 연동, 기획 협업흐름 잡는 법 피그마·Jira 연동, 기획 협업흐름 잡는 법 📌 목차 화면, 이슈, 근거가 각자 따로 노는 순간 세 도구는 원래 역할이 다르다 실제로 겪은 어긋남 참조 구조로 연결하는 법 실무 팁 3가지 마무리 FAQ 1. 화면, 이슈, 근거가 각자 따로 노는 순간 피그마에 화면을 올리고, Jira에 이슈를 만들고, Confluence에 정책을 적어두면 협업이 저절로 될 거라 생각한 적이 있습니다. 막상 스프린트가 돌아가기 시작하니 세 곳의 내용이 서로 다른 이야기를 하고 있었습니다. 개발자는 Jira 이슈만 보고 작업했는데, 그 이슈에는 이틀 전 수정된 피그마 화면이 링크되어 있지 않았습니다. 결국 QA 단계에서 "이 버튼 위치가 왜 이렇게 됐냐"는 질문이 나왔고, 저는 세 곳을 오가며 어디서부터 어긋났는지 확인해야 했습니다. 이번 글에서는 피그마, Jira, Confluence가 각각 어떤 역할을 맡아야 하는지, 그리고 세 곳을 어떻게 연결해야 이런 어긋남이 줄어드는지 정리해보겠습니다. 2. 세 도구는 원래 역할이 다르다 세 도구를 연동한다고 하면 흔히 자동화 플러그인부터 떠올리지만, 그 전에 각 도구가 무엇을 담당하는지부터 명확히 해야 합니다. 역할이 겹치면 연동을 아무리 걸어도 정보가 어디 있는지 헷갈리는 문제는 그대로 남습니다. 도구 담당 영역 생명주기 Figma 화면의 최신 모습, 인터랙션, 스타일 자주 바뀜 Jira 지금 진행 중인 작업 단위, 담당자, 상태 작업이 끝나면 종료 Confluence 왜 이렇게 결정했는지에 대한 근거와 정책 사업 규칙이 바뀔 때만 갱신 정리하면 Figma는 "지금 화면이 어떻게 생겼는가", Jira는 "지금 무엇을 ...