Certificação CSPO (Product Owner)

Cartões · 50

Responsabilidade primordial do Product Owner

Maximizar o valor do produto resultante do trabalho do Time de Desenvolvimento, e não apenas gerenciar tarefas ou prazos.

Armadilha do PO como intermediário ou 'garçom'

Apenas repassar pedidos dos stakeholders sem avaliar o real valor do negócio transforma o PO em mero tirador de pedidos.

Autoridade sobre o Product Backlog

O PO é a única pessoa responsável por gerenciar e priorizar o Product Backlog; ninguém de fora pode impor ordens ao time.

Definição de Pronto (Definition of Done - DoD)

Pertence aos Developers e garante qualidade técnica; o PO não deve flexibilizar o DoD para entregar mais rápido.

Conceito de Incremento

Deve ser utilizável, inspecionável e atender à Definição de Pronto ao final do Sprint, trazendo valor concreto.

Meta do Produto (Product Goal)

Compromisso de longo prazo do Product Backlog que guia as decisões e fornece foco estratégico contínuo ao time.

Meta da Sprint (Sprint Goal)

Compromisso do Sprint Backlog que define o propósito do Sprint; histórias podem mudar contanto que a meta seja mantida.

Diferença entre Saída (Output) e Desfecho (Outcome)

Output é a quantidade de itens entregues; Outcome é o impacto real no comportamento do usuário e no negócio. Foque em Outcome.

Armadilha da delegação excessiva do refinamento

O PO não deve terceirizar completamente o refinamento, pois perde o alinhamento de negócio e o contato com a viabilidade técnica.

Participação do PO na Daily Scrum

A Daily é uma reunião interna dos Developers; o PO só participa se for convidado ou se também for um Developer.

Cancelamento de Sprint

Apenas o Product Owner tem a autoridade para cancelar a Sprint, caso a Meta da Sprint se torne completamente obsoleta.

Papel do PO na Sprint Review

Apresentar o que foi concluído, receber feedback dos stakeholders e discutir o que vem a seguir no Product Backlog.

Papel do PO na Sprint Retrospective

Participar como membro pleno do Scrum Team para melhorar processos, relacionamentos e a eficiência da entrega de valor.

Armadilha de tratar o PO como comitê

O PO deve ser uma pessoa individual, não um comitê, para garantir decisões rápidas, claras e sem ambiguidades.

Técnica de Priorização: MoSCoW

Classifica itens em Must have, Should have, Could have e Won't have para alinhar expectativas mínimas de viabilidade.

Técnica de Priorização: WSJF

Weighted Shortest Job First prioriza itens dividindo o Custo do Atraso (Cost of Delay) pelo tamanho do esforço.

Custo do Atraso (Cost of Delay)

Mede o impacto financeiro ou estratégico de adiar a entrega de uma funcionalidade específica ao mercado.

Produto Mínimo Viável (MVP)

A versão mais enxuta do produto que permite validar hipóteses de valor com usuários reais usando o menor esforço possível.

Histórias de Usuário (User Stories)

Não são obrigatórias no Guia Scrum, mas são ferramentas úteis para capturar necessidades focadas no usuário final.

Critérios de Aceitação

Definem as condições específicas de negócio para que o PO considere um item do Product Backlog pronto para aceite.

Armadilha do Backlog infinito

Acumular centenas de itens antigos gera ruído; itens sem perspectiva clara de valor devem ser excluídos ou arquivados.

Refinamento do Backlog (Backlog Refinement)

Atividade contínua onde o PO e os Developers detalham, estimam e ordenam itens para deixá-los prontos para próximas Sprints.

Estrutura INVEST para User Stories

Independente, Negociável, Valiosa, Estimável, Pequena (Small) e Testável para garantir itens de alta qualidade.

Estimativa de esforço: quem faz?

Apenas as pessoas que farão o trabalho (Developers) estimam o esforço; o PO nunca deve forçar ou ditar estimativas.

Estimativa de valor de negócio: quem faz?

É responsabilidade prioritária do Product Owner, muitas vezes em colaboração com stakeholders e clientes.

Armadilha de aceitar itens inacabados no Sprint Review

Itens que não atendem 100% à Definição de Pronto não são demonstrados nem considerados entregues; voltam ao Backlog.

Diferença entre PO e Gerente de Projetos tradicional

O PO gerencia o valor do produto e maximiza o ROI, em vez de focar no controle de escopo, cronograma e pessoas.

Colaboração entre PO e Scrum Master

O SM ajuda o PO a encontrar técnicas eficazes de gestão do backlog e facilita o entendimento empírico do produto.

Mapa da Jornada do Usuário (Customer Journey Map)

Ajuda o PO a identificar pontos de atrito e momentos de valor na experiência do usuário para priorizar melhorias.

Story Mapping (Mapeamento de Histórias)

Organiza a visão do produto em duas dimensões (passos do usuário e prioridade de entrega) facilitando o fatiamento em MVPs.

Fatiamento Vertical de Histórias

Dividir itens entregando uma fatia completa de valor ponta a ponta (UI, lógica, banco), em vez de fatias horizontais.

Armadilha de fatiar por camada técnica

Criar histórias separadas para front-end, back-end ou banco não entrega valor utilizável nem permite validação rápida.

Dívida Técnica e o PO

Ignorar a dívida técnica desacelera o time a longo prazo; o PO deve equilibrar novas funcionalidades e sustentabilidade técnica.

Pesquisa com Usuários (User Research)

O PO deve fundamentar decisões em dados de comportamento real dos usuários, e não apenas em suposições internas.

Métricas de Vaidade vs. Métricas Acionáveis

Métricas de vaidade (como downloads totais) apenas impressionam; métricas acionáveis (retenção, conversão) orientam decisões.

Evidence-Based Management (EBM)

Framework que guia o PO usando quatro áreas-chave: Valor Atual, Valor Não Realizado, Capacidade de Entrega e Tempo de Resposta.

Visão do Produto (Product Vision)

Declaração clara e inspiradora que define para quem é o produto, qual problema resolve e o diferencial competitivo.

Disponibilidade do PO para o time

O PO precisa estar facilmente acessível durante o Sprint para esclarecer dúvidas e evitar bloqueios operacionais.

Armadilha da microgestão pelo PO

O PO define O QUE deve ser feito e POR QUE; o time de desenvolvimento é auto-gerenciável e decide COMO fazer.

Sprint Planning: Papel do PO

Apresentar o objetivo de negócio do Sprint, propor a Meta do Sprint e esclarecer dúvidas sobre os itens prioritários.

Gestão de Stakeholders

Stakeholders devem ser envolvidos e ouvidos continuamente, mas não têm poder de decisão final sobre a ordenação do Backlog.

Dizer 'Não' como habilidade essencial

Um PO de sucesso deve saber dizer 'não' com frequência para proteger o foco na estratégia e evitar sobrecarga de escopo.

Retorno sobre o Investimento (ROI)

O PO busca maximizar o valor entregue pelo menor investimento de esforço e tempo do time de desenvolvimento.

Release Planning (Planejamento de Lançamento)

Mecanismo para prever quando conjuntos de valor estarão no mercado, baseado na velocidade empírica e na capacidade real.

Ciclo Construir-Medir-Aprender (Lean Startup)

Ciclo iterativo em que o PO valida hipóteses o mais cedo possível para minimizar o risco de construir algo inútil.

Transparência do Product Backlog

O Product Backlog deve ser visível e compreensível para todos na organização para manter o alinhamento de prioridades.

Definição de Pronto vs. Critérios de Aceitação

DoD aplica-se universalmente a qualquer incremento; critérios de aceitação são específicos e exclusivos de uma história.

Priorização orientada por risco

Itens com alto risco de valor ou viabilidade técnica devem ser antecipados para permitir correções de curso baratas.

Capacidade do time vs. Carga do PO

O PO não deve forçar mais trabalho do que a capacidade estimada pelo time na reunião de planejamento do Sprint.

Empirismo no papel do PO

O PO baseia planos em fatos observados, inspeção frequente e adaptação, abandonando previsões rígidas e infundadas.