PMI PMP: Agile, Scrum e Entrega Híbrida — Guia de estudos

By Laurynas Brazys · 21 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Faz parte do PMP — Guia de estudos. Pratique com respostas verificadas no centro de exames da PMI, ou faça testes cronometrados no ExamRoll.io.

Estimativa, Story Points e Velocity

Story points medem esforço relativo, complexidade e incerteza — não a duração. Uma história de cinco pontos representa aproximadamente cinco vezes o esforço de uma história de um ponto para aquela equipe específica. A Velocity (pontos concluídos por sprint) então emerge empiricamente ao longo de várias sprints e é usada para prever intervalos, não para firmar compromissos de calendário.

Tratar story points como dias fixos é uma armadilha séria por várias razões. Primeiro, isso destrói a abstração: se 1 ponto = 1 dia, a equipe simplesmente estimará em dias e inflará as estimativas para cumprir os prazos. Segundo, elimina o sinal de incerteza — uma história de 13 pontos não é apenas “longa”, ela é arriscada, e esse risco deve levar à sua decomposição. Terceiro, permite que a gerência use os números como arma (“vocês disseram 40 pontos, por que só terminaram 32?”), o que incentiva um comportamento de subestimar a capacidade (sandbagging). O uso correto é: tendência da velocity + tamanho do backlog → previsão de lançamento probabilística, comunicada como um intervalo.

Gerenciando Impedimentos, Interrupções e Fluxo

O trabalho mais tangível do Scrum Master é a remoção de impedimentos. Quando um membro da equipe está com dificuldades em silêncio — talvez por orgulho ou por ser novo demais para expor o problema — o líder da equipe deve intervir diretamente, entender o impedimento e ajudar a resolvê-lo ou escalá-lo. Ignorar o propósito da daily standup é o que permite que esse padrão se agrave; a participação inconsistente na standup cria silos de conhecimento, oculta bloqueios e permite que pequenos problemas se tornem riscos para o cronograma. A participação é inegociável precisamente porque o valor da cerimônia está na sincronização, não no reporte de status.

As interrupções ad-hoc — a solicitação “urgente” que ignora o backlog — são igualmente corrosivas. Elas corroem a meta da sprint, invalidam a previsão e ensinam aos stakeholders que o processo pode ser contornado. O tratamento correto é encaminhar novas solicitações através do PO, que decide se elas justificam um cancelamento da sprint (raro) ou se devem ser incluídas em uma sprint futura (geralmente).

Para equipes híbridas onde os testes ou outra disciplina se tornam um gargalo, a visualização do fluxo por meio de quadros Kanban e gráficos de burndown/burnup expõe a restrição. Se a equipe identificar uma ferramenta que poderia desbloquear os testes, o gerente de projetos não deve aprovar ou rejeitar unilateralmente — ele deve avaliar a proposta de forma colaborativa, verificar a governança organizacional (aquisições, segurança), envolver o PO sobre o impacto no backlog e então decidir. A aprovação reflexiva pula a devida diligência; a negação reflexiva ignora a expertise da equipe.

Retrospectivas e Melhoria Contínua

As retrospectivas fecham o ciclo. Uma boa retrospectiva produz uma ou duas ações de melhoria concretas e com responsáveis definidos — não uma sessão de desabafo. Trazer as equipes de operações e QA para as retrospectivas desde o início evita as falhas clássicas de passagem de bastão (handoff), onde as equipes otimizam para as demos de fim de sprint, mas não para a realidade da produção. A melhoria contínua é o mecanismo que mantém a velocity honesta, o DoD significativo e o engajamento da equipe alto ao longo da vida do produto.

Problema Prático: Cenário de Caso de Uso

Cenário: Priya Nair é a Scrum Master da equipe da carteira móvel “LumenPay” em uma fintech, trabalhando em sprints de duas semanas com seis desenvolvedores, um engenheiro de QA e um designer de UX. Nas últimas três sprints, o Product Owner, Marcus Reeves, participou de apenas uma sessão de planejamento da sprint e de nenhuma sprint review, alegando conflitos de responsabilidade como chefe de Parcerias de Varejo. Stakeholders das áreas de Compliance e Operações de Fraude começaram a enviar e-mails diretamente para os desenvolvedores com solicitações de prioridade conflitantes, e a equipe transferiu 34 de 82 story points nas duas últimas sprints. A patrocinadora, VP de Produto Anita Chen, está começando a questionar a velocity da equipe.

Desafio: Priya precisa restaurar o engajamento do Product Owner e impedir a fragmentação do backlog sem ultrapassar seu papel de líder-servidora, tomando ela mesma as decisões de produto.

Abordagem Recomendada:

1. Documentar os impactos específicos da ausência do PO nas últimas três sprints — pontos transferidos (carryover), critérios de aceite ambíguos, itens de backlog não resolvidos e a contagem de solicitações diretas de stakeholders que não passaram pelo PO — para construir um caso baseado em fatos.
2. Realizar primeiro uma conversa individual (one-on-one) com Marcus, compartilhando os dados e perguntando diretamente se ele pode se comprometer com as 10 a 15 horas semanais que o papel exige, ou se o papel precisa ser reatribuído ou dividido.
3. Escalar formalmente para Anita Chen com as evidências documentadas, apresentando duas opções: reatribuir o papel de PO para alguém com capacidade, ou negociar uma redução nas responsabilidades de Marcus em Parcerias de Varejo.
4. Orientar (fazer coaching) a equipe de desenvolvimento para redirecionar todas as solicitações de stakeholders para o product backlog, em vez de aceitá-las ad hoc, e reforçar que apenas o PO pode repriorizar.
5. Assim que um PO comprometido for confirmado, realizar um workshop de refinamento do backlog para realinhar as prioridades, limpar os critérios de aceite e redefinir a meta da sprint para a próxima iteração.
6. Estabelecer um acordo de trabalho (working agreement) especificando a presença do PO no planejamento, na review e em pelo menos duas sessões de refinamento por sprint.

Por que isso funciona: Escalar a vacância para a patrocinadora preserva a integridade do papel — a Scrum Master não deve se tornar uma Product Owner substituta (proxy), pois isso mascara permanentemente o problema organizacional e compromete a priorização baseada em valor. Basear a escalada em métricas concretas mantém a conversa focada nos resultados da entrega, em vez de em personalidades, e redirecionar o tráfego de stakeholders através do backlog restaura a disciplina de fonte única de verdade (single-source-of-truth) da qual o Scrum depende.

← Liderança de Equipe e Gerenciamento de Recursos · Todos os domínios · Escopo →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →