Introdução à Certificação PSM I e Roteiro Completo de Estudos
O que a Professional Scrum Master I realmente valida, como compreender Scrum sem confundi-lo com hábitos organizacionais e como percorrer uma trilha completa de 62 capítulos até a preparação para o exame e a prática profissional.
Edição consolidada
Por João Ricardo Dutra••Artigo completo
Edição consolidada
Este capítulo reúne integralmente as informações dos dois materiais de origem. Trechos equivalentes foram fundidos para eliminar redundâncias, sem excluir conteúdo informativo. O núcleo introdutório do Capítulo 1 original tinha tempo estimado de leitura de 20 minutos; esta versão é mais extensa porque incorpora também o roteiro completo de 62 capítulos.
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender o que representa a certificação (), quem a mantém, que nível de conhecimento ela exige, por que o Scrum Guide é a referência central, como distinguir de práticas organizacionais ou técnicas complementares, como raciocinar diante de questões situacionais e como se organiza a trilha completa de estudos, da base histórica à aplicação do no mundo real.
1. Por que a é mais do que um teste de vocabulário
A maneira mais rápida de interpretar mal a é tratá-la como uma prova de definições, nomes de eventos ou reuniões. A forma mais útil de compreendê-la é enxergar como um sistema empírico e coerente para aprender em ambientes complexos. O exame exige que o candidato reconheça esse sistema e aplique suas regras mesmo quando várias alternativas parecem plausíveis ou quando a situação descrita é diferente da prática de sua empresa.
surgiu no início da década de 1990, quando profissionais buscavam maneiras melhores de desenvolver produtos complexos sob incerteza. Ken Schwaber e Jeff Sutherland desenvolveram o framework nesse período e o apresentaram formalmente ao público na OOPSLA, em 1995. O Scrum Guide foi publicado pela primeira vez em 2010 para oferecer uma definição comum e deliberadamente concisa do framework; a versão oficial indicada nos materiais-base é a de novembro de 2020.
A se insere nessa história. .org, fundada por Ken Schwaber em 2009, mantém o programa de certificações . Por isso, a avaliação não procura saber como uma empresa específica “faz ”; procura verificar se o candidato entende o conforme definido no Scrum Guide: o que o framework exige, o que permite, o que deixa deliberadamente em aberto e como um deve ajudar pessoas e organizações a usá-lo profissionalmente.
O estudo torna-se mais consistente quando fatos isolados são conectados em um modelo mental. Em vez de apenas decorar nomes, é preciso perguntar por que a transparência vem antes da inspeção, por que a inspeção sem adaptação é incompleta, por que o é accountable por estabelecer conforme definido e não por distribuir tarefas, por que o é uma única pessoa, por que a é , por que a é indispensável à transparência e por que a não é uma frase decorativa em uma ferramenta de acompanhamento.
2. O que a certificação realmente valida
A é a certificação fundamental de da .org. Ela é baseada em conhecimento e é obtida pela aprovação em uma avaliação, não simplesmente pela presença em um curso. Participar de treinamento oficial pode ser recomendado, mas não é pré-requisito para adquirir e realizar a prova.
A palavra “fundamental” não deve ser confundida com “superficial”. A certificação comprova uma base correta sobre o , sobre as accountabilities do e sobre a aplicação de dentro de Teams. Ela não pressupõe que a pessoa já tenha resolvido todas as dificuldades de transformação organizacional, mas exige uma fundação sólida o bastante para que experiência e aprendizado avançado sejam construídos sobre ela.
Esse domínio envolve duas camadas complementares. A primeira é o conhecimento do framework: ,,,, e suas accountabilities, eventos, artefatos e compromissos. A segunda é interpretativa: compreender como esses elementos se relacionam, que problemas procuram resolver e como agir quando uma situação ameaça transparência, foco, , ou entrega de valor.
Um exemplo mostra a diferença. Memorizar que o é um evento de 15 minutos para os é útil. Compreender seu propósito é mais importante: ele existe para inspecionar o progresso em direção à e adaptar o quando necessário. Portanto, transformá-lo em uma reunião de status na qual cada Developer presta contas ao ou a um gerente entra em tensão com o propósito do evento.
A prova não é a profissão
Aprovar-se na demonstra um nível fundamental de conhecimento de . Isso não torna automaticamente alguém um facilitador, coach, ou experiente. Essas capacidades se desenvolvem com prática deliberada, observação, facilitação, coaching, influência organizacional e .
Ser um , portanto, vai além de possuir um certificado. Pressupõe uso disciplinado de , compromisso com seus valores e capacidade de ajudar pessoas a enfrentar problemas complexos por meio do , e não por cerimônias mecânicas. O não é apenas quem agenda reuniões, atualiza quadros ou remove pessoalmente todos os obstáculos. Seu serviço envolve estabelecer como definido, aumentar a efetividade da , favorecer , apoiar e e ajudar a organização a interagir melhor com .
3. Para quem esta trilha é indicada
A e esta trilha não se destinam apenas a quem já ocupa o cargo de . O conteúdo é útil para profissionais que precisam de uma compreensão rigorosa do framework e de sua aplicação em problemas complexos.
Aspirantes o que desejam sair do conhecimento zero ou parcial até a preparação para a por meio de uma sequência estruturada.
Masters em atuação que aprenderam sobretudo por hábitos organizacionais e desejam comparar essas práticas com o Scrum Guide.
e Product Owners que querem compreender as accountabilities e as interações de todo a .
coaches, consultores e facilitadores que precisam separar básico de práticas complementares.
Gerentes de projeto, delivery managers, engineering managers e líderes que transitam de estruturas preditivas ou de para entrega empírica de produtos.
Estudantes e profissionais de tecnologia que buscam uma credencial fundamental reconhecida e um vocabulário transferível entre organizações.
Profissionais de diferentes setores nos quais equipes resolvem problemas complexos, refletindo o uso de para além do desenvolvimento de software.
Não é necessário chegar com anos de experiência. A .org não exige curso oficial antes da avaliação. Essa acessibilidade favorece o estudo autodirigido, mas também aumenta a responsabilidade do candidato de distinguir oficial de práticas populares que apenas podem coexistir com .
4. Conhecimentos esperados e áreas de competência
O conhecimento esperado começa pela arquitetura do framework. O candidato deve saber explicar e os três pilares - Transparency, Inspection e Adaptation - e compreender os cinco : Commitment, Focus, Openness, Respect e Courage, não como uma lista isolada, mas como condições comportamentais que sustentam o funcionamento do .
Também é necessário compreender a como uma unidade coesa e formada por um , um e ; conhecer o propósito de cada evento; e entender a relação entre os três artefatos e seus compromissos: com , com e com . Os compromissos criam foco e transparência para que a inspeção tenha um referencial claro.
Nos materiais-base, a .org organiza o escopo da em três grandes áreas de competência: Understanding and Applying the ; Developing People and Teams; e Managing Products with Agility. Nessas áreas aparecem, entre outros temas, ,,, eventos, artefatos, Done, teams, facilitação, coaching, ,, valor de produto, gestão do , stakeholders e clientes.
O centro de gravidade da preparação para a é o Scrum Guide. Ele contém a definição oficial de , é mantido por Ken Schwaber e Jeff Sutherland e, segundo os materiais-base, tem como versão oficial vigente a edição de novembro de 2020. Sua brevidade é enganosa: quase cada frase estabelece uma relação, uma restrição, um propósito ou uma accountability.
Dois erros de estudo são comuns: ler o Guide apenas uma vez, como se fosse um folheto introdutório, e migrar imediatamente para simulados; ou tentar memorizá-lo palavra por palavra sem formar conexões conceituais. Uma abordagem mais robusta é fazer leituras em camadas: primeiro, compreender a estrutura geral; depois, perguntar por que cada elemento existe; em seguida, relacionar ,,, eventos, inspeção e adaptação; e, nas leituras posteriores, concentrar-se nas expressões que estabelecem accountabilities ou limites.
Uma pergunta útil após cada parágrafo é: “Que equívoco esta frase impede?”. Se o texto afirma que a é , investigue o que violaria essa característica. Se diz que o pode delegar trabalho, mas continua accountable, examine o que a delegação muda e o que não muda. Se estabelece que algo só faz parte de um quando atende à , pergunte o que acontece com o trabalho incompleto.
Para responder à , o Scrum Guide deve prevalecer sobre hábitos do trabalho, posts de blog, documentação de ferramentas ou práticas ensinadas por colegas experientes. Uma empresa pode precisar de governança, relatórios, revisões de arquitetura, aprovações de release, critérios de segurança, testes adicionais ou métodos de estimativa. Essas escolhas podem coexistir com , mas não passam a fazer parte da definição do framework por serem adotadas localmente.
O Guide também ensina contenção: é intencionalmente incompleto. Ele não prescreve um processo integral de entrega de produtos; fornece um framework leve dentro do qual outras técnicas podem ser utilizadas. Por isso, respostas de prova muito “organizadas” podem estar erradas quando introduzem , atribuem autoridade à accountability errada ou transformam uma prática opcional em regra obrigatória.
6. Separe do ecossistema ao redor de
Um princípio de organização desta trilha é separar quatro tipos de conhecimento: oficial; o universo mais amplo; práticas comumente utilizadas com ; e tópicos complementares. Essa classificação evita um dos erros mais frequentes na : concluir que uma prática familiar é um elemento obrigatório do framework.
User Stories, ,,, Burndown Charts, ,,, /, workflows, release plans e podem ser úteis em determinados contextos, mas nenhum deles se torna requisito básico de apenas porque uma equipe ou empresa os utiliza. O estudante deve saber responder: isto é ,, prática complementar, métrica, framework de escala ou escolha organizacional?
7. Saber não é o mesmo que saber aplicá-lo
Conhecimento declarativo permite dizer o que é uma , listar eventos, identificar artefatos e nomear accountabilities. Conhecimento relacional e situacional permite decidir o que fazer quando pressão, incerteza e comportamento humano colocam hábitos locais em conflito com os propósitos do .
Considere a . Saber que ela serve para planejar formas de aumentar qualidade e efetividade é importante. Entender que a inspeciona como a transcorreu em relação a pessoas, interações, processos, ferramentas e permite perceber por que “não aconteceu nada de errado” não é motivo para cancelá-la: a Retrospective é uma oportunidade regular de melhoria, não um post-mortem reservado a falhas.
A mesma lógica vale para a atuação do . Uma interpretação fraca de seria “o faz tudo que a equipe pede”. Uma interpretação profissional é servir de modo a elevar capacidade e autonomia: facilitar quando necessário, ensinar, orientar, fazer coaching, ajudar na e, em certas situações, permitir que o próprio time resolva um problema em vez de criar dependência permanente.
8. Por que experiência profissional não substitui o estudo do framework
Experiência e prova respondem a perguntas diferentes. A experiência mostra “o que vi funcionar no meu contexto”; a avaliação pergunta “o que é consistente com e com o ?”. As duas coisas podem se sobrepor, mas não são idênticas.
Organizações adaptam linguagem e responsabilidades. Uma empresa pode chamar o de delivery lead, exigir que ele aprove mudanças no , pedir que o administre um comitê, criar uma “”, transformar o em status report ou usar a como gate formal de aprovação. Algumas escolhas podem nascer de restrições legítimas; outras podem ser equívocos. Nenhuma se torna apenas porque é praticada há anos.
Experiência também pode gerar viés de autoridade: se um gerente, coach ou colega sênior ensinou uma versão específica de , o candidato pode defendê-la inconscientemente. O remédio não é descartar a experiência, mas reclassificá-la como evidência contextual. Mantenha duas categorias mentais: “ exige” e “nossa organização escolhe”. exige ; a empresa pode registrá-lo no . exige ; a organização pode incluir critérios específicos de segurança, testes ou compliance. exige um para ; o formato da conversa é uma escolha. não exige ; a equipe pode optar por utilizá-los.
Essa separação melhora tanto a prova quanto a prática profissional. Ela permite dizer com precisão: “isto é política organizacional, não regra do ” ou “esta técnica pode ser útil, desde que não prejudique ”.
9. O hábito mais perigoso na prova: responder “como minha empresa faz”
Muitas questões situacionais acionam memórias do trabalho antes que o candidato analise . Surgem respostas automáticas como “o escalaria isso ao gerente”, “o distribui o trabalho” ou “estenderíamos a porque a entrega atrasou”. Uma contramedida é substituir mentalmente “o que faríamos?” por “o que procura otimizar aqui?”. Essa pergunta redireciona a atenção para , valor, foco, e accountabilities explícitas.
Outra técnica é procurar o “erro de autoridade”. A alternativa concede poder que não concede? O manda executarem tarefas? Um gerente altera a ? Um stakeholder reordena diretamente o ? O determina como devem criar o ? Muitas opções erradas soam eficientes porque centralizam controle; combina accountabilities claras com e feedback frequente.
Também é essencial reconhecer o propósito dos eventos. não é reunião geral de status para stakeholders. não é apenas demo, apresentação, aprovação ou gate de release. não é contrato que congela o . não se torna opcional porque tudo correu bem.
Por fim, observe a linguagem absoluta. Algumas regras são firmes: uma dura um mês ou menos; a conclui a ; o é uma pessoa; a possui as accountabilities definidas. Outras decisões são contextuais. A maturidade para a inclui reconhecer essa diferença.
10. Exemplo prático: transformar um cenário de trabalho em raciocínio
Imagine uma na metade de uma de duas semanas. Um executivo sênior pede ao que inclua uma funcionalidade urgente. O considera a solicitação valiosa e determina aos que substituam imediatamente dois itens selecionados. Em seguida, pedem ao que atualize o quadro e garanta o cumprimento do novo plano.
Uma resposta baseada em hábito organizacional poderia priorizar hierarquia: “o executivo é sênior, o concordou, então o deve coordenar a mudança”. O raciocínio começa pela . Durante a , o escopo pode ser esclarecido e renegociado conforme o aprendizado, mas as mudanças não devem colocar a em risco. O é um plano dos e para os , atualizado continuamente à medida que aprendem.
O é accountable por maximizar valor e pela gestão efetiva do . Essa accountability não significa controle unilateral sobre o plano dos dentro da . e podem colaborar para renegociar o escopo sem destruir a . O pode facilitar a conversa, ensinar aos stakeholders como lida com mudanças de prioridade, orientar o e ajudar os a proteger o foco enquanto permanecem responsivos a novas informações.
O objetivo não é resistir rigidamente à mudança. foi concebido para adaptação. O objetivo é adaptar sem destruir a estrutura empírica que permite aprendizado, foco e transparência. Esse padrão permanece útil em questões com executivos, prazos, defeitos, solicitações de clientes, ausências, previsões ou políticas: os pontos de ancoragem continuam sendo , accountabilities, , transparência, inspeção, adaptação, valor e propósito dos eventos e artefatos.
11. Como estruturar a preparação para a
Uma preparação forte deve avançar de definição para compreensão, aplicação e fluência sob tempo limitado. Começar por centenas de questões pode gerar falsa confiança por memorização de padrões; ficar apenas na teoria também é insuficiente. O caminho proposto alterna leitura conceitual e feedback prático.
Leia o Scrum Guide integralmente sem tentar decorar cada frase. Faça uma segunda leitura para anotar relações e uma terceira concentrada em accountabilities, restrições, propósitos dos eventos e diferenças entre e equívocos comuns.
Crie um mapa de uma página contendo , accountabilities, eventos, artefatos, compromissos, e pilares empíricos.
Use Open e outros recursos oficiais como mecanismos de diagnóstico, não como exercícios de perseguição de nota. Ao errar, registre por que seu raciocínio falhou: confundiu accountability com autoridade? Tratou uma prática popular como obrigatória? Respondeu pelo costume da empresa? Ignorou ou ?
Pratique raciocínio situacional identificando, em cada cenário, o elemento envolvido, seu propósito, a accountability pertinente, o risco empírico e a resposta que preserva enquanto aumenta efetividade.
À medida que a prova se aproxima, simule o limite de tempo. Fluência importa porque a média disponível é inferior a um minuto por questão; o objetivo é que o Scrum Guide já tenha moldado sua forma de pensar, em vez de precisar ser consultado a cada item.
Trate prontidão como consistência, não como sensação de familiaridade. Um bom sinal é conseguir explicar por que uma alternativa está correta, por que as plausíveis estão erradas e qual regra, propósito ou princípio de sustenta a conclusão.
12. Retrato da avaliação indicado nos materiais-base
Os dados abaixo foram apresentados como verificados em recursos da .org disponíveis em agosto de 2026. O próprio material alerta que detalhes de avaliação podem mudar e devem ser conferidos antes da compra ou realização da prova.
Detalhe
Situação indicada
Mantenedor
.org
Nível
Domínio fundamental de
Preço indicado
USD 200 por tentativa
Questões
80
Tempo limite
60 minutos
Nota mínima
85%
Formatos
Múltipla escolha, múltiplas respostas e verdadeiro/falso
Curso obrigatório
Não
Avaliação prática
Open
Senha da avaliação
Não expira até ser utilizada e vale para uma tentativa
Validade do certificado
Vitalícia; sem taxa anual de renovação
Referência central
Scrum Guide, versão oficial indicada: novembro de 2020
13. Arquitetura da trilha completa de 62 capítulos
O programa é deliberadamente progressivo. Os capítulos 1 a 53 constroem entendimento; os capítulos 54 a 60 convertem esse entendimento em desempenho para a ; e os capítulos 61 e 62 devolvem o foco ao crescimento profissional depois do exame. A lógica geral percorre contexto histórico, domínio do framework, , práticas complementares, atuação do , escala, preparação específica e continuidade.
Etapa
Capítulos
Ênfase
Fundamentos
1-14
Contexto histórico, ,,, pilares e valores
15-34
, accountabilities, eventos, artefatos e compromissos
Produto
35-36
Valor, , e
Práticas complementares e métricas
37-46
User Stories, INVEST, estimativas, ,, métricas e evidências
na prática
47-51
Liderança, facilitação, coaching, impedimentos, conflitos e stakeholders
Escala
52-53
Múltiplos Teams e
Preparação
54-60
Memorização de alto valor, armadilhas, questões situacionais, Open, simulados e revisão final
Continuidade
61-62
Aplicação no mundo real e próximos passos profissionais
Arquitetura da trilha completa de 62 capítulos.
14. Roteiro completo do curso
PARTE I - ENTENDENDO POR QUE O SURGIU
O curso começa antes do . Ele estabelece por que ciclos longos de feedback, planejamento extensivo antecipado e requisitos em mudança levaram profissionais de software a formas de trabalho mais adaptativas. Esse contexto histórico evita que seja reduzido a rituais sem um problema a resolver.
Cap. / Tempo
Título
Conteúdo
1 · 20 min
Introdução à Certificação
Este é o próprio capítulo consolidado. Ele apresenta a , seu mantenedor, o significado de , público-alvo, conhecimento esperado, estrutura de preparação, papel central do Scrum Guide, diferença entre conhecer e aplicar , limites da experiência profissional e risco de responder com base em hábitos da empresa.
2 · 25 min
Desenvolvimento de Software Antes do
Organização tradicional de projetos de software: planejamento extensivo antecipado, separação funcional entre análise, desenvolvimento, testes e entrega, gestão orientada a planos, previsibilidade versus incerteza, diferenças entre software e produção industrial e custo de ciclos longos de feedback.
3 · 25 min
O Modelo
História e contexto do ; requisitos, análise, design, implementação, testes, deployment e manutenção; situações em que pode ajudar; limitações diante de necessidades mutáveis; descoberta e validação tardias de erros; contraste entre desenvolvimento sequencial e iterativo.
4 · 25 min
Complexidade e Incerteza em Projetos
Diferenças entre problemas simples, complicados e complexos; mudanças em requisitos, mercados e tecnologia; feedback de usuários; hipóteses versus fatos; limites de prever todo o projeto antecipadamente; necessidade de ciclos curtos de aprendizado.
PARTE II - FUNDAMENTOS DO
Apresenta como movimento e orientação mais ampla, não como sinônimo de . O estudante conhece valores e princípios que influenciaram o desenvolvimento adaptativo moderno e as diferenças em relação ao planejamento tradicional.
Cap. / Tempo
Título
Conteúdo
5 · 20 min
A Ascensão do Movimento
Indústria de software dos anos 1990, , problemas enfrentados pelos profissionais, encontro de Snowbird em 2001, , como conjunto de valores e princípios e por que não constitui uma metodologia única.
6 · 25 min
Os Quatro Valores do
,, e Responding to change; significado de “over”, razão pela qual os itens da direita continuam tendo valor, exemplos práticos e interpretações equivocadas comuns.
7 · 30 min
Os 12 Princípios do
Os 12 princípios individualmente e sua relação com entrega de valor, requisitos mutáveis, ciclos curtos, colaboração, motivação, comunicação, ,,, simplicidade, equipes e , incluindo conexões posteriores com .
8 · 25 min
vs. Desenvolvimento de Software Tradicional
Comparação de planejamento, escopo, feedback, entrega, gestão de mudanças, participação do cliente, organização das equipes, risco, métricas e aprendizado. Esclarece abordagens iterativas, incrementais, adaptativas e preditivas e quando diferentes abordagens podem ser adequadas.
PARTE III - FUNDAMENTOS DO
Com o contexto histórico e estabelecido, a trilha entra no : origens, definição, ,, pilares e valores. Essa é a base conceitual dos demais temas da .
Cap. / Tempo
Título
Conteúdo
9 · 25 min
História e Origens do
Origem do nome , artigo “The New New Product Development Game”, de Takeuchi e Nonaka, Jeff Sutherland, Ken Schwaber, desenvolvimento do nos anos 1990, apresentação pública, Scrum Guide, evolução do framework e expansão para além de software.
10 · 25 min
O que é ?
Definição de como framework leve para produtos complexos e soluções adaptativas; geração de valor; por que não é metodologia prescritiva; estrutura mínima; possibilidade de conter práticas complementares; efeitos da remoção de elementos essenciais.
11 · 25 min
Conhecimento derivado da experiência e de evidências observadas, relação entre e complexidade, feedback loops, , experimentação, hipóteses, validação e modo como operacionaliza controle empírico.
12 · 25 min
Os Três
Transparency, Inspection e Adaptation: informação visível, entendimento compartilhado, , inspeção frequente, detecção de desvios, , ajuste oportuno e cadeia central Transparency -> Inspection -> Adaptation.
13 · 20 min
e
Redução de desperdício, foco no essencial, criação de valor, ciclos pequenos e relação entre e , incluindo por que executar mais trabalho não significa necessariamente gerar mais valor.
14 · 25 min
Os Cinco
Commitment, Focus, Openness, Respect e Courage com definições, exemplos, comportamentos esperados, comportamentos que contradizem cada valor e relação com e .
PARTE IV - A
Transforma teoria em limites claros de accountability. Explica quem compõe a , como funcionam e e pelo que , e respondem.
Cap. / Tempo
Título
Conteúdo
15 · 25 min
Estrutura da
,, e ; ausência de hierarquias internas e subequipes definidas por ; responsabilidade coletiva; tamanho recomendado; foco em uma ; accountability pela criação de valor.
16 · 25 min
Equipes e
,, autonomia com accountability, quem decide quem faz o quê e como o trabalho é executado, colaboração e habilidades complementares; diferença entre a terminologia antiga e a atual .
17 · 30 min
Aprofundamento da accountability: maximização de valor, ,, ordenação e comunicação de PBIs, transparência, delegação sem perda de accountability, como uma pessoa e relações com stakeholders, e , incluindo armadilhas da .
18 · 25 min
Quem são os em , criação do ,,, planejamento e adaptação diários, accountability profissional e mútua, qualidade e autonomia técnica.
19 · 30 min
Aprofundamento em estabelecer , efetividade da , true leadership, , coaching, ensino, mentoring, facilitação, , e serviço ao , e organização. Reforça que o não é gerente da .
20 · 25 min
na Organização
como : ensino de , adoção organizacional, barreiras, colaboração com stakeholders, mudança cultural, estruturas de , trabalho com organizações tradicionais e melhoria da efetividade organizacional.
PARTE V - EVENTOS DO
Os eventos são estudados como feedback loops, não como cerimônias. Cada evento possui propósito e específicos e cria oportunidade formal de inspeção e adaptação.
Cap. / Tempo
Título
Conteúdo
21 · 25 min
A
como contêiner dos demais eventos, duração de um mês ou menos, início e fim, Sprints contínuas, , qualidade, refinement durante a , adaptação de escopo, previsibilidade e ciclos curtos de aprendizado.
22 · 20 min
Quando uma pode ser cancelada, significado de tornar-se obsoleto, autoridade para cancelamento, responsabilidade do , impactos, tratamento de trabalho concluído ou inacabado e cenários comuns de prova.
23 · 30 min
Três tópicos de planejamento - por que esta é valiosa, o que pode ser Done e como o trabalho será realizado -, participação da ,,, PBIs selecionados, planejamento dos , forecast, inicial e .
24 · 25 min
Propósito, participação dos , de 15 minutos, inspeção de progresso, , adaptação do , liberdade de formato, antigas três perguntas, por que não é status meeting, papel do e bons e maus exemplos.
25 · 25 min
Inspeção do resultado da , participação de stakeholders, feedback, mudanças no ambiente, próximos passos, , valor e colaboração. Distingue Review de apresentação, demo, reunião de aprovação ou gate de release.
26 · 25 min
Qualidade e efetividade por meio de pessoas, interações, processos, ferramentas, , identificação de melhorias e . Distinção essencial: Review -> produto; Retrospective -> forma de trabalhar.
27 · 20 min
Timeboxes dos
de ,,, e ; durações para uma de um mês; eventos tipicamente menores em Sprints menores; razão dos timeboxes e questões comuns de certificação.
PARTE VI - ARTEFATOS E COMPROMISSOS
Consolida as estruturas de informação que tornam transparente. Cada artefato é associado ao seu compromisso para que trabalho, objetivos e qualidade sejam inspecionados contra alvos claros.
Cap. / Tempo
Título
Conteúdo
28 · 20 min
Visão Geral dos Artefatos
, e ; como viabilizam transparency, inspection e adaptation; compromissos , e .
29 · 30 min
e
ordenado e emergente, Items, como objetivo de longo prazo, evolução do backlog, accountability do , transparência, ordenação, e refinement.
30 · 25 min
Refinement como atividade contínua, não evento ; decomposição, clareza, tamanho, ordenação, participação dos , papel do , refinement contínuo, quanto fazer e preparação para Sprints futuras.
31 · 25 min
e
Componentes do :, PBIs selecionados e plano para criar o ; accountability dos ; atualização e adaptação contínuas; flexibilidade de escopo; proteção da .
32 · 25 min
como valor utilizável, integração com Increments anteriores, múltiplos Increments em uma , entrega antes da , relação com e qualidade.
33 · 30 min
Aprofundamento de Done; como compromisso do ; transparência, qualidade, padrões organizacionais, compartilhada, trabalho que não atende à , PBIs incompletos, utilizável e evolução da .
34 · 20 min
Os Três Compromissos
Consolida -> , -> e -> ; propósito de cada compromisso, melhoria de transparência e foco e relação com .
PARTE VII - GESTÃO DE PRODUTOS COM AGILIDADE
Amplia a perspectiva para : valor, outcomes, e em ambientes complexos.
Cap. / Tempo
Título
Conteúdo
35 · 25 min
Produto, Valor e
Produto, valor, stakeholders, usuários, clientes, outcomes versus outputs, , hipóteses de produto, feedback, aprendizado e decisões orientadas a valor.
36 · 25 min
e
Diferença entre forecast e compromisso absoluto, incerteza e planejamento em ambientes complexos, evidência histórica, capacidade, planejamento progressivo, mudanças baseadas em aprendizado, releases e relação entre planejamento e .
PARTE VIII - PRÁTICAS COMPLEMENTARES COMUMENTE USADAS COM
Apresenta práticas utilizadas por muitos Teams, reforçando que não são elementos obrigatórios de . Essa distinção é particularmente importante para a .
Cap. / Tempo
Título
Conteúdo
37 · 25 min
User Stories
Origem, formato comum “Como / eu quero / para que”, stories como mecanismos de conversa, contraste com requisitos tradicionais, divisão de stories, stories grandes versus pequenas e fato de User Stories não serem obrigatórias em .
38 · 25 min
INVEST e Boas User Stories
Independent, Negotiable, Valuable, Estimable, Small e Testable; exemplos bons e ruins, divisão de stories e como INVEST pode apoiar .
39 · 20 min
Relação com PBIs, exemplos, Given/When/Then, versus e diferença entre requisitos específicos de um item e padrões globais de qualidade do produto.
40 · 25 min
Fundamentos de Estimativas
Por que equipes estimam, incerteza, , complexidade, esforço, risco, tamanho, estimativa versus prazo, e responsabilidade dos pelo .
41 · 20 min
, escalas semelhantes a Fibonacci, complexidade, esforço, incerteza, comparação entre itens, problemas de converter pontos em horas e por que não são obrigatórios em .
42 · 20 min
Propósito e fluxo, estimativas simultâneas, divergência, discussão, conhecimento coletivo, redução de influência prematura, limitações e como técnica opcional.
43 · 25 min
Entrega histórica, , variação de para , problemas de comparar equipes, , riscos de metas de e como ferramenta possível, não requisito .
PARTE IX - MÉTRICAS E EVIDÊNCIAS
As métricas são tratadas como evidências para o , não como teatro de produtividade. O estudante aprende a interpretar fluxo, valor e qualidade entendendo que não prescreve a maioria desses indicadores.
Cap. / Tempo
Título
Conteúdo
44 · 25 min
Gráficos Burndown e Burnup
Eixos, trabalho restante, trabalho concluído, escopo, tendências, limitações, uso para inspeção e por que não exige esses gráficos.
45 · 25 min
,,,, Aging , gargalos, previsibilidade e , mostrando como podem apoiar .
46 · 25 min
Métricas de Valor e Qualidade
Valor entregue, satisfação do usuário, qualidade, defeitos, disponibilidade, uso do produto, conversão, outcomes versus outputs e métricas técnicas versus de negócio. Alerta contra medidas de produtividade por contagem de tarefas e comparação de profissionais por .
PARTE X - NA PRÁTICA
O curso passa do conhecimento de prova para o ofício comportamental de ajudar equipes e organizações a melhorar. Liderança, facilitação, coaching e dinâmica organizacional tornam-se centrais.
Cap. / Tempo
Título
Conteúdo
47 · 25 min
e True Leadership
Contraste entre liderança tradicional e versus /verdadeira, influência sem autoridade hierárquica, autonomia, confiança e responsabilidade.
48 · 30 min
Ensino, Mentoring, Coaching e Facilitação
Diferença entre ensinar, mentoring, coaching e facilitação; quando utilizar cada postura, exemplos práticos, risco de o resolver tudo e modo como intervenções devem desenvolver autonomia.
49 · 25 min
Impedimentos
Impedimentos versus problemas cotidianos, responsabilidade do , resolução de problemas pelos , barreiras organizacionais, dependências, escalonamento e prevenção de dependência excessiva do .
50 · 25 min
Conflito e Equipes
Conflito saudável, segurança psicológica, responsabilidade coletiva, facilitação, comunicação, autonomia, decisões coletivas, quando a intervenção do é apropriada e desenvolvimento da maturidade da equipe.
51 · 25 min
e Stakeholders
Relações com stakeholders, transparência, , feedback, colaboração, accountability do por maximizar valor, proteção contra e educação de stakeholders sobre .
PARTE XI - MÚLTIPLAS EQUIPES E ESCALA
Distingue regras de para múltiplos times trabalhando em um produto de frameworks opcionais de escala. O objetivo é preservar coerência do produto, integração e qualidade compartilhada.
Cap. / Tempo
Título
Conteúdo
52 · 25 min
com Múltiplos Teams
Múltiplas equipes em um produto, identidade compartilhada do produto, ,,,, integração, dependências, comunicação e desafios de escala.
53 · 25 min
Introdução ao
, sua relação com .org, problema que procura resolver, múltiplos Teams em um produto, dependências, integração, e eventos/artefatos adicionais em alto nível. Esclarece que complementa e não faz parte do básico definido no Scrum Guide.
PARTE XII - PREPARAÇÃO ESPECÍFICA PARA A
Converte o conhecimento acumulado em desempenho de prova, com memorização seletiva, armadilhas, raciocínio situacional, Open, simulados, revisão final do Scrum Guide e critério de prontidão.
Cap. / Tempo
Título
Conteúdo
54 · 20 min
O que Realmente Precisa Ser Memorizado
Consolidação de 3 accountabilities, 5 eventos, 3 artefatos, 3 compromissos, 3 pilares e 5 valores: fatos e relações de alto valor para recuperação rápida.
55 · 30 min
Armadilhas Comuns da
como gerente, como comitê, Daily como status, como aprovação/demo, Review versus Retrospective, distribuindo trabalho, /User Stories//Burndown como obrigatórios, como métrica oficial, momento de release do ,, mudança de escopo e .
56 · 30 min
Como Resolver Questões Situacionais
Método de 10 perguntas: identificar accountability, propósito do evento, artefato, compromisso, transparency, inspection, adaptation, , risco de e se a prática realmente existe no Scrum Guide. Inclui exemplos comentados.
57 · 20 min
Open Assessment
O que é Open, como utilizá-lo, por que não memorizar questões, identificação de lacunas, registro de erros, classificação por tema, revisão do Scrum Guide e repetição até desempenho consistentemente alto.
58 · 25 min
Estratégia de Simulados
Simulação realista, gestão do tempo, questões fáceis primeiro, itens de múltiplas respostas, palavras absolutas, eliminação de alternativas incompatíveis com , revisão de respostas, análise de erros pós-simulado e ciclo Simulado -> Análise -> Scrum Guide -> Revisão -> Novo Simulado.
Leitura final em que cada elemento é testado por propósito, accountability, transparency, inspection, adaptation, Value relacionado e problema que surgiria se o elemento fosse removido.
60 · 20 min
Checklist de Prontidão para a
Verifica se o estudante consegue explicar sem notas, , pilares, valores, accountabilities, eventos, artefatos, compromissos, , versus ,, práticas opcionais, questões situacionais, simulados cronometrados e desempenho consistentemente alto no Open.
PARTE XIII - DEPOIS DA
A certificação é um marco, não o fim do desenvolvimento profissional. A parte final conecta conhecimento de prova ao crescimento real como e a uma jornada mais ampla de aprendizagem.
Cap. / Tempo
Título
Conteúdo
61 · 25 min
Aplicando no Mundo Real
Diferença entre passar na prova e ser , observação de equipes, facilitação, coaching, experimentação, Retrospectives, métricas, cultura organizacional, e comunidades .
62 · 20 min
Próximos Passos na Jornada
Possíveis caminhos: II, III, , certificações complementares, , Product Management, facilitação, coaching, , métricas, liderança e, acima de tudo, experiência prática como principal motor de crescimento após a certificação.
15. Carga estimada e como usar o roteiro
O roteiro estima de 24 a 30 horas de estudo teórico para os 62 capítulos, pois a maioria foi desenhada para cerca de 20 a 30 minutos e pode ser estudada de modo independente, sem grandes blocos obrigatórios. Quando são acrescentados Scrum Guide, exercícios, revisões, Open, questões comentadas e simulados completos, a preparação total é estimada em aproximadamente 35 a 45 horas.
O tempo real deve permanecer empírico: alguém com experiência forte em pode avançar mais rapidamente em certos temas, enquanto um profissional vindo de gestão preditiva pode precisar de prática adicional em , valor e .
Um ritmo prático
Estudando dois capítulos por dia de estudo, os 62 capítulos exigem 31 dias de estudo. Mantendo cinco dias de estudo por semana, isso corresponde a pouco mais de seis semanas, antes de acrescentar tempo extra para pontos fracos, leituras do Scrum Guide e simulados completos.
Carga estimada e como usar o roteiro.
16. Exemplo de como um estudante percorre a trilha
Imagine um engenheiro de software que participou de “projetos ” durante três anos, mas nunca leu o Scrum Guide com atenção. Na primeira semana, ele percebe que vários hábitos de sua empresa - escopo de fixo, distribuindo trabalho e usada como aprovação - não são regras de . As Partes I a III oferecem o contexto histórico e empírico para compreender o motivo.
Nas Partes IV a VI, o estudante reconstrói o framework com base em limites de accountability, propósito dos eventos, artefatos, compromissos e . Em vez de decorar fatos isolados, passa a explicar por que são responsáveis pelo , por que a permite flexibilidade de escopo e por que não é gate de release.
As Partes VII a X ampliam as habilidades: valor, , estimativas e métricas são estudados sem transformar ou em requisitos do . Os capítulos de liderança mostram por que o promove autonomia em vez de tornar-se gerente operacional da equipe.
As Partes XI e XII formam a camada final de certificação: múltiplos times em um produto, como complemento, estrutura de memorização de alto valor, armadilhas, raciocínio situacional, Open, simulados e checklist final.
Depois da aprovação, a Parte XIII evita o erro de supor que o aprendizado terminou: a certificação passa a ser o início da prática real, com observação, facilitação, coaching, experimentação, uso de evidências e participação em comunidades profissionais.
17. O que o sucesso deve significar antes da prova
Antes de tentar a , o estudante que percorreu bem esta trilha deve demonstrar capacidade de:
Explicar de memória como um framework coerente baseado em e .
Nomear e diferenciar 3 accountabilities, 5 eventos, 3 artefatos, 3 compromissos, 3 pilares e 5 valores.
Explicar , e e associar cada compromisso ao artefato correto.
Raciocinar sobre cenários usando accountability, propósito do evento, transparency, inspection, adaptation e .
Identificar práticas opcionais sem promovê-las indevidamente a requisitos do .
Usar Open como diagnóstico, e não como banco de perguntas para memorização.
Realizar simulados inéditos dentro da restrição real de tempo, com precisão consistente e revisão controlada das respostas.
O objetivo real
O certificado é um resultado da trilha, não a única razão para percorrê-la. O resultado mais forte é um leitor capaz de reconhecer de fato, explicar por que seu desenho importa e continuar desenvolvendo julgamento profissional depois da avaliação.
18. Conclusão: comece pelo mapa, depois aprenda o sistema
A é uma certificação fundamental, mas o conhecimento por trás dela não é trivial. é intencionalmente leve, o que torna cada elemento significativo. Um Guide curto ainda exige compreensão profunda porque as questões da prova e o trabalho real de produto combinam elementos em situações, em vez de apresentá-los como definições isoladas.
A progressão de 62 capítulos começa antes do , mostra por que o desenvolvimento adaptativo surgiu, introduz por e e aprofunda , eventos, artefatos e compromissos. Em seguida, acrescenta gestão de produtos, estimativas e métricas sem borrar a fronteira entre e práticas complementares; trabalha liderança sem hierarquia, facilitação, coaching, impedimentos, conflitos, stakeholders e cultura organizacional; aborda escala com múltiplos Teams e ; e termina com preparação específica para a avaliação e desenvolvimento profissional posterior.
A preparação mais consistente combina história suficiente para entender o problema, teoria de suficiente para compreender o sistema, práticas complementares suficientes para reconhecer contexto e disciplina de prova suficiente para demonstrar o conhecimento sob pressão de tempo. Depois, o certificado deve voltar ao mundo real na forma de prática, observação e .
19. Referências oficiais e de curso presentes nos materiais-base
.org - About .org: informação institucional sobre a organização fundada pelo cocriador do Ken Schwaber, responsável por treinamento, certificação e recursos.
Course Roadmap - CAPITULOS.txt: roteiro de estudos em 13 partes e 62 capítulos fornecido pelo autor e usado como base do panorama curricular completo.
Nota sobre atualidade
Os próprios materiais-base registram que detalhes da avaliação podem mudar com o tempo. Antes de adquirir ou realizar a , os dados operacionais devem ser conferidos nos recursos oficiais da .org.
