기획자의 작업대

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

테스트 케이스, QA 요청 받은 기획자가 처음 작성하는 법 테스트 케이스, QA 요청 받은 기획자가 처음 작성하는 법 기획자의 작업대 · 실무 가이드 📌 목차 테스트 케이스란? 기획서와 무엇이 다른가 화면이 아니라 기획서에서 출발해야 하는 이유 테스트 케이스 한 줄의 구성 기획서에서 케이스 뽑는 순서 실무 팁 3가지 마무리 FAQ 프로젝트 마무리 단계에서 QA 요청을 받은 적이 있습니다. 개발된 화면을 점검하는 게 아니라, 기획한 내용이 빠짐없이 반영됐는지 확인해 달라는 요청이었습니다. 막상 시작하려니 화면을 따라가야 할지, 기획서를 따라가야 할지부터 헷갈렸습니다. 빈 엑셀 시트를 열어 두고 첫 행에 무엇을 적어야 할지 한참 고민했던 기억이 납니다. 이번 글에서는 테스트 케이스를 처음 쓰는 기획자가 어디서 출발해야 하는지, 그리고 기획서를 케이스 목록으로 바꾸는 순서를 정리해 보겠습니다. 1. 테스트 케이스란? 기획서와 무엇이 다른가 테스트 케이스(Test Case, TC)는 "이 조건에서 이렇게 하면 이런 결과가 나와야 한다"를 한 줄씩 적은 확인 목록입니다. 기획서와 다루는 대상은 같지만 질문이 다릅니다. 기획서는 "어떻게 동작해야 하는가" 를 적고, 테스트 케이스는 "그렇게 동작하는지 어떻게 확인하는가" 를 적습니다. 요리로 비유하면 기획서는 레시피이고, 테스트 케이스는 시식 체크리스트입니다. 레시피에 "소금 한 꼬집"이 있다면, 체크리스트에는 "간이 짜지 않은가"가 들어갑니다. 같은 요리를 보지만 쓰는 사람의 역할이 다릅니다. 2. 화면이 아니라 기획서에서 출발해야 하는 이유 처음 TC를 쓸 때 가장 쉽게 빠지는 함정이 있습니다. 개발된 화면을 켜 놓고, 보이는 버튼과 입...

피그마 빈 화면·오류 화면 검토법: 개발 전에 꼭 확인해야 할 예외 케이스 피그마 빈 화면·오류 화면 검토법: 개발 전에 꼭 확인해야 할 예외 케이스 기획 리뷰 단계에서 빈 화면과 오류 화면을 놓치면 개발 후반부에 리소스가 배로 듭니다. 화면 설계 시 반드시 짚어야 할 예외 케이스와 실전 검토 순서를 정리했습니다. 📌 목차 리뷰 때는 안 보이고 개발 때 터지는 화면들 핵심 개념 — UI 상태(State) 설계란 무엇인가 실제 사례로 보는 누락 패턴 적용 방법 — 리뷰 시 확인 순서 실무 팁 3가지 마무리 — 핵심 요약과 다음 행동 FAQ 1. 리뷰 때는 안 보이고 개발 때 터지는 화면들 기획 리뷰를 마치고 다 같이 화면을 검토했다고 생각한 순간, 개발자가 와서 "이 기능은 화면에 없는데 필요한 것 아닌가요?"라고 물어볼 때가 있습니다. 분명 여러 명이 함께 봤던 화면인데도 놓친 부분이 있었다는 걸 그제야 깨닫습니다. 특히 빈 화면이나 오류 화면처럼 평소 눈에 잘 띄지 않는 예외 케이스에서 이런 일이 자주 벌어집니다. 2. 핵심 개념 — UI 상태(State) 설계란 무엇인가 화면은 항상 "정상적으로 데이터가 채워진 상태"만 존재하는 게 아닙니다. 데이터가 아예 없는 상태(Empty), 요청 중인 상태(Loading), 요청이 실패한 상태(Error), 일부 데이터만 도착한 상태(Partial)가 함께 존재합니다. 기획 단계에서 정상 케이스만 그려두고 나머지 상태는 개발자 재량에 맡기면, 서비스 전체의 톤앤매너가 화면마다 달라지고 사용자 경험도 일관성을 잃게 됩니다. 3. 실제 사례로 보는 누락 패턴 검색 결과 리스트 화면을 기획하면서 정상적으로 결과가 나오는 화면만 그려두고 넘어간 적이 있습니다. QA 단계에서 "검색 결과가 없을 때 화면이 텅 비어 보인다"는 피드백을 받고서...

IT 기획자를 위한 스토리보드 작성법 스토리보드만 잘 그려도 프로젝트 성공 확률이 확~ 높아진다는 사실, 알고 계셨나요? 요즘 기획서 쓰다 보면 머리가 터질 것 같은 IT 기획자 분들 많으시죠? 저도 예전에 그런 시기를 겪었던 사람으로서, 스토리보드 작성이 얼마나 헷갈리고 힘든 일인지 정말 잘 압니다. 막상 머릿속에 그림은 그려지는데, 이걸 문서화해서 개발자랑 디자이너에게 전달하려고 하면 손이 멈추잖아요. 그래서 이번 글에서는 스토리보드를 쉽게 그리고, 빠르게 정리할 수 있는 실전 팁을 낱낱이 공유해볼까 합니다. 커피 한 잔 들고, 편하게 따라와 주세요! 목차 스토리보드가 필요한 이유 기획자가 알아야 할 구성요소 스토리보드 작성 도구 비교 실전 스토리보드 작성 순서 초보 기획자의 흔한 실수 디자이너·개발자에게 전달하는 팁 스토리보드가 필요한 이유 처음 기획안을 정리할 땐 머릿속으로 다 되는 것 같잖아요. 근데 실제로 개발자나 디자이너에게 설명하려다 보면 "이걸 어떻게 말로 설명하지?"란 생각이 들기 시작하죠. 그때 필요한 게 바로 스토리보드예요. 서비스의 흐름과 화면 구성을 시각적으로 보여주면 말보다 훨씬 더 빠르게 전달되고 오해도 줄어들거든요. 특히 비개발자와 협업할 때 필수입니다. 기획자가 알아야 할 구성요소 스토리보드는 단순한 그림이 아니라, 화면의 흐름과 의도를 담은 설명서예요. 주요 구성 요소를 빠짐없이 담아야 디자이너나 개발자가 이해하고 반영할 수 있어요. 아래 표를 참고해 보세요. 구성 요소 설명 화면 ID 각 화면을 구분하기 위한 고유 코드 화면명 화면의 명칭 또는 기능 기능 설명 해당 화면에서 사용자가 수행할 수 있는 주요 ...