프로덕트오너 인터뷰 질문 (초급)
원본링크
https://www.knowledgehut.com/interview-questions/product-owner
프로덕트 오너로써, 전형적으로 어떤 행위들이 당신에 의해 이뤄지는가?
이 기초질문은 심사자로 하여금 지원자를 이해하고, 지원자는 자신에 대한 설명을 시작할 수 있도록 해준다.
대답은 지원자 마다 조금씩 다를 수 있지만, 전형적인 대답은 이것이다. 스프린트 계획, 스프린트 리뷰, 스프린트 회고, 그루밍. 만약 PO(Product Owner)가 데일리 스크럼(Daily Scrum) 이라했을 때, 그가 거기서 무엇을 했는지를 물어라, PO가 Daily Scrum 에 참석하는 것은 괜찮다. 하지만, PO는 관찰자가 되어야지 무언가를 말하는 사람이 되어서는 안된다.
c.f. Grooming: https://www.youtube.com/watch?v=UpEBfS9SZGM
당신은 스토리 그루밍 (Story Grooming), 유저스토리 분할, 추정 토의의 한 역할을 하나요?
그렇다, PO 는 팀이 올바르게 유저 스토리를 분할하고, 좀 더 정확하게 일을 추산할 수 있게, 팀이 유저 스토리의 온전한 이해 속에서 진행하는 것을 돕는다. PO가 SME(Subject Matter Expert) 로써, 사용자 스토리 이해를 위해 행동하는 동안, 팀이 이를 올바르게 이해하도록 돕지만, 그는 스토리 포인트나 스토리 추산을 제안하거나 직접하지 않는다.
c.f. Story Estimation: https://guide.quickscrum.com/scrum-guide/estimate-story/
PO(Product Owner) 와 Scrum Master를 한 사람이 해도 되나요?
아니다. PO 와 SM 은 분리된 다른 역할이며, 이 역할이 섞이면 개발 진행에 아주 부정적인 영향을 줄 수 있다. 두 역할은 100% 몰입을 요구하는데, Scrum Master(스크럼 마스터) 는 종종 목표가 다변화될 때, 개발팀과 PO 사이의 중재자 역할을 한다. 때문에, 한 사람으로써는 두 역할을 제대로 할 수 없다.
어떻게 백로그 (backlog) 목록에서 우선순위를 정하나?
전형적인 대답은 MoSCoW 가 될 것이다. — Must be, Should be, Could be, Won’t be — 하지만 경험있고, 유능한 PO(Product Owner)는 WSJF 같은 다른걸 얘기할 것이다.
c.f. Weighted Shortest Job First: https://www.scaledagileframework.com/wsjf/
좋은 Product Backlog item 이란 무엇인가?
잘 생성된 Backlog item 은 ‘DEEP’을 만족한다. — Detailed appropriately, Estimated, Emergent, Prioritized
백로그(Backlog) 정제(Refinement) 회의 — Grooming — 에서 우리는 다가오는 Sprints 에 초점을 맞추는가 아니면 현재 Sprints 에 초점을 맞추는가?
Product backlog refinement 미팅은 곧 다가오는 Sprint를 위한 것이다. 현재 진행 중인 Sprint 는 더이상 Product Backlog 에 존재하지 않는다. 그 업무들은 Sprint Backlog 에 존재한다.
c.f. Product backlog, Sprint backlog: https://www.projectmanager.com/blog/product-backlog-sprint-backlog
프로덕트 오너로써, 당신은 사용자 스토리 (User stories)를 작성하고 개발팀에 전달하는가?
아니다. PO(Product Owner)는 큰 사용자 스토리를 작성하고 이를 개발팀에 전달한다. 이를 논의하고 잘게 쪼개는 것은 팀의 몫이다.
좋은 사용자 스토리 (User story)의 특징은 무엇인가?
좋은 사용자 스토리는 ‘INVEST’ 를 만족한다. — Independent, Negotiable, Valuable, Estimable, Small, Testable
c.f. About INVEST: https://agileforall.com/new-to-agile-invest-in-good-user-stories/
유저 스토리 분할과 추정과정에서 개발팀이 어려워하는 것을 보았다. 무엇을 할 것인가?
만약 이것이 큰 유저 스토리의 이해 부족이나 비즈니스 요구사항(Business requirement) 에 의한 것이라면 PO 로써 더 논의하고 질의를 받을 것이다. 하지만 이 문제가 부정확한 스토리 분배 방법에 의한 것이라면 Scrum Master 에게 전달하여 좀 더 논의하고 추가적인 Gromming, Traning Session 을 가지도록 할 것이다.
무엇이 DoD(Definition of Done — 완료정의)이고, 누가 만드는가?
DoD 는 유저 스토리(User Story) 가 어떻게 하면 완료되는 것인지에 대한 공유된 이해이다. DoD는 완료되어야 하는 작업들의 리스트이며, 여기에는 씌여지는 코드들, 부연 설명, 유닛 테스트, 통합 테스트, 배포 노트, 디자인 문서 등이 포함된다.
DoD는 개발팀에 의해 만들어진다.
무엇이 Acceptance Criteria (허용기준) 이고, 누가 정하는가?
Acceptance Criteria 는 유저 스토리나 기능이 만족해야할 조건들이며, 이는 Product Owner 에 의해 승인된다. 그 조건들은 통과되거나 반려될 각 세부 조건들의 세트이며, 프로젝트 통합의 현재 스테이지에서 기능적인 혹은 비기능적인 요구사항을 특정한다.
PO 가 Acceptance Criteria 를 정한다.
DoD(Definition of Done)와 DoR(Definition of Ready) 는 동일한가?
아니다. DoD 는 코드 작성, 코드 리뷰/코멘트, 유닛 테스트, 통합 테스트, 배포 노트, 디자인 문서 등의 리스트이며,
DoR은 스토리가 다음 스프린트를 위해 Pick up 될 준비가 되었는지에 관한 기준이다.
PO (Product Owner — 프로덕트 오너) 한 사람이 여러 스크럼 팀(Scrum Team)에서 역할을 할 수 있는가?
여러 스크럼 팀이 같은 프로덕를 위해 일하고 있고, PO 가 충분한 시간적 여유가 있는한, 이것은 가능하다.
두 명 이상의 PO 가 하나의 스크럼 팀에 존재할 수 있는가?
아니다. 팀에는 한 명의 PO 혹은 만 존재해야 한다. PO 는 스크럼 팀이 프로덕트의 비전과 목표를 향해 가도록 방향을 제시하는 사람이다. 여러명의 PO 는 혼란을 불러일으킬 수 있다.
Burn Down chart 는 어떻게 PO 가 Sprint 진행상황을 추적하도록 도와주는가?
Burn-down 차트는 남은 시간 대비 업무를 나타내는 그래픽 표현이다. 기대이상의 업무는 수평 시간 축에 대비해 수직적으로 배치가 되며, 이는 기대이상 잘 진행되고 있는 일을 나타낸다. 차트는 언제 모든 일이 완료될지를 예측하는데 도움이 된다.
Burn-down chart on Jira: https://www.atlassian.com/agile/tutorials/burndown-charts
프로덕트 오너로써(PO) 스프린트 중단을 결정할 수 있는가?
그렇다. 스프린트를 취소할 수 있는 권한은 PO에게만 이지만, 이 결정은 이해관계자(주주 혹은 유관부서 등) 와 개발팀과 상의되어야 한다.
스프린트(Sprint) 가 중단된다면, 완료된 PBI(Product Backlog items) 는 어떻게 되는가?
스프린트가 중단되는 경우, 모든 PBI 는 재확인 되어야한다. 만약 이것이 잠재적으로 배포가능하다면, PO 는 이를 승인할 수 있다.
스프린트 완료까지 진행할 수 없는 SBI(Sprint Backlog Item) 은 어떻게 해야하는가?
마지막 Sprint Review 과정 DoD 에서 그 SBI 는 시연되지 않는다. 이를 바로 다음 Sprint 로 넘기는 것은 좋은 생각이 아니다. 그 대신 이를 PBI(Product Backlog Item)으로 옮기고 다음 스프린트 item 으로 포함시키기 전 다시 평가해보아야 한다.
PO가 Techinical 한 사람이 되어야 하는가?
Technical 배경을 가진 곳에서 PO 가 오는 것에는 문제가 없다. 하지만 PO 는 절대 개발팀(Development Team) 이 되지 않아야 한다. 또한, Technical 파트에서 온 PO 는 스토리 분할 과정에서 SME(Subject Matter Expert) 처럼 행동하지 않도록 해야하며, 이를 방지하도록 스스로 자제할 수 있는 훈련을 해야 한다.
당신의 개발팀이 Sprint 이행을 계속해서 실패하고 있다. Product Owner 로써, 무엇을 할 수 있나?
PO로써, 개발팀이 Sprint 완수를 실패하는 이유를 아는 것은 아주 중요하다. 여러가지 이유가 있을 수 있는데, 부정확한 추정, 신뢰와 협업 부족, User Story에 대한 이해 부족, 작업 분할의 실수 등이 있다. PO는 이를 기초로 하여 개발팀, Scrum Master 와 함께 해답을 찾을 필요가 있다.
