Em junho de 2025, uma publicação do Jeff Sutherland deu o que falar. Foi o Scrum Guide Expansion Pack, em tradução direta, o Guia de expansão do Guia do Scrum escrito pelo próprio Jeff em parceria com Ralph Jocham e John Coleman. Ken Schwaber não é coautor nessa expansão.
Meu intuito neste artigo não será a tradução do documento que você poderá ver na íntegra clicando neste link. Em vez disso, vou apenas ressaltar alguns pontos que achei relevantes. Partirei da premissa que você, leitor, já conhece o Scrum. Caso não, dê uma lida nesse artigo aqui.
Por que eles criaram o Pacote de Expansão do Guia do Scrum?
De acordo com os autores, a ideia é ampliar o Guia Scrum de 2020 para os desafios modernos. Ele não é um substituto do guia e sim um complemento. Segundo eles, é necessário explicar o “porquê” e o “para quê” de cada elemento do Scrum (papéis, eventos, artefatos). Assim como o guia, eles reconhecem que o Scrum já se expandiu além da fronteira do desenvolvimento de software.
O objetivo é proporcionar apoio completo às equipes autogerenciáveis, desde a descoberta de problemas até a entrega de valor de forma sustentável. Ademais, ele cobre todo o ciclo de vida do produto, incluindo descoberta, criação, adaptação, manutenção e descontinuação — e enfatiza a importância de responder com agilidade às necessidades de stakeholders.
Reforçando os Fundamentos e Pilares do Scrum
Os autores mantiveram os fundamentos do Scrum e seus pilares de Transparência, Inspeção e Adaptação, reforçam a necessidade de se adaptar sempre frente à complexidade do trabalho, abordagem empírica e evolutiva e enxuta (lean). O foco está em reduzir desperdícios e tornar o trabalho mais intencional e eficaz.
Por outro lado, algo que eles dão muita ênfase ao longo do texto é a responsabilidade (accountability) profissional. Há momentos em que eles são severos em relação a isso e “convidam” a pessoa que não tem interesse em exercer determinada função a se retirar. Para eles, o profissionalismo vai além de conhecimento técnico: trata-se de assumir total responsabilidade pelo produto durante todo seu ciclo de vida. Isso inclui excelência técnica, comportamento ético, transparência, comprometimento com a qualidade e aprendizado contínuo. Profissionais no Scrum devem manter uma postura consistente e responsável, mesmo diante de pressões externas, e devem buscar sempre entregar valor de forma sustentável e respeitosa com todos os envolvidos.
Além disso, o pacote reforça práticas como experimentação, aprendizado contínuo, validação de valor e melhoria de fluxo. Além disso, recomenda uma visão sistêmica do trabalho, em que problemas e oportunidades são tratados como hipóteses a serem testadas, e não como certezas. Aqui tenho que fazer um merchant no nosso treinamento de Certified Product Owner (CSPO) sempre tratamos essa necessidade.
Valores do Scrum
Os valores do Scrum — Foco, Coragem, Comprometimento, Abertura e Respeito — foram mantidos e reforçados. Inclusive, os autores afirmam que juntos formam a base para um ambiente saudável, colaborativo e ético. Logo, eles promovem segurança psicológica, comunicação clara e um senso coletivo de responsabilidade. O Expansion Pack relaciona esses valores ao Ciclo OODA de John Boyd (Observar, Orientar, Decidir, Agir), mostrando como eles ajudam equipes a tomar decisões em cenários incertos. Mais do que palavras, esses valores devem guiar ações, comportamentos e decisões diárias.
Introdução de Novas Teorias
O Scrum Guide 2020 se fundamenta em três teorias principais: 1) controle empírico de processos, que enfatiza transparência, inspeção e adaptação para lidar com ambientes complexos; 2) o Lean Thinking, que orienta a maximização de valor com a eliminação de desperdícios; e o princípio da autogestão dos times, que valoriza equipes auto-organizadas e multifuncionais capazes de tomar decisões rápidas e eficazes. Essas teorias sustentam a estrutura do Scrum como um framework leve e adaptativo voltado à entrega contínua de valor em contextos incertos e dinâmicos. O Pacote de Expansão trás novas teorias que são importantíssimas para a boa adaptação do Scrum. Então, vamos a elas.
Product Thinking
Aqui eles detalharam uma coisa que já me parecia muito clara. Na verdade, o Product Thinking propõe a mudança de mentalidade: ao invés de pensar em projetos com início e fim, Scrum foca no ciclo contínuo de valor dos produtos. Produtos exigem cuidado permanente, equilibrando metas de curto prazo (como conquistar usuários) e de longo prazo (como sustentabilidade, evolução e manutenção). Portanto, essa forma de pensar exige que o Product Owner tome decisões estratégicas considerando valor, viabilidade, usabilidade e custo, além de evitar armadilhas como dívida técnica e entregas apressadas no estilo, “vai que o prazo está acabando”. Em resumo, o objetivo final é entregar valor real e duradouro, com foco em resultados concretos para os stakeholders.
Systems Thinking
O Systems Thinking reconhece que toda ação dentro de uma organização tem efeitos que se espalham de forma interconectada — muitas vezes não linear. Ele reforça a importância de compreender os impactos upstream (antes), cross-stream (paralelos) e downstream (depois) de qualquer decisão. Logo, essa abordagem ajuda a evitar otimizações locais que prejudicam o todo e encoraja a criação de ciclos de feedback e experimentos dirigidos por hipóteses. Em contextos complexos, essa visão sistêmica permite decisões mais adaptativas e eficazes.
Esse ponto é bem interessante, pois o Kanban já trata isso há algum tempo através do STATIK. Além do que foi a primeira vez que um documento Scrum mencionou o conceito de Fluxo de Valor e Fluxo de Trabalho. E eles deram muita importância a isso como deveriam. Juntos são mencionados mais de 30 vezes no documento.
Discovery (Descoberta)
Aleluia! Finalmente esse assunto foi tratado. O discovery é o processo contínuo de aprendizado sobre o que realmente importa para os stakeholders, utilizando observações, entrevistas e testes de hipóteses. Consequentemente, seu foco é identificar oportunidades, evitar suposições infundadas e alinhar soluções com as necessidades reais dos usuários. No Scrum, o trabalho de descoberta deve ser transparente e estar incorporado ao backlog e aos eventos da Sprint. Essa frase é para glorificar de pé!. A prática evita desperdícios e permite validar ideias antes de desenvolvê-las plenamente, equilibrando criatividade com disciplina.
Liderança
Liderança no Scrum não é um cargo, mas um comportamento COLETIVO e intencional que inspira, orienta e promove um ambiente seguro e produtivo. É baseada em escuta ativa, empatia, clareza de propósito e remoção de barreiras. Líderes promovem confiança, aprendizado com falhas, e decisões baseadas em evidência. Portanto, no contexto do Scrum, todos podem e devem demonstrar liderança (olha que já tinha visto isso por aqui): Scrum Masters criam as condições para que as equipes prosperem; Product Owners orientam com visão e foco em valor; Desenvolvedores lideram por meio da autogestão e profissionalismo; e os Supporters (os veremos em breve) habilitam mudanças estruturais necessárias à evolução da organização.
Novos Papéis
Aqui eles reforçam os papéis do Time Scrum, Product Owner (PO), Scrum Master (SM) e Desenvolvedores (Dev). Eles estendem o que já está escrito no guia de 2020. Entretanto, eles incluem alguns papéis:
Stakeholder
Tão comum em outras metodologias, o stakeholder é uma pessoa que tem algum interesse no produto que está sendo construído pelo Time Scrum, porém não faz parte do time. Por exemplo, usuários do produto / serviço, gestores, clientes, reguladores, fiscalização, agentes do governo etc. No entanto, é importante ressaltar que os autores incluem entidades não humanas como stakeholders. Dão como exemplo leis e Inteligência Artificial. Confesso que tenho certa dificuldade de chamar esses dois últimos de stakeholders.
Além disso descrevem mais detalhadamente a importância do: 1) usuário que pode não ter poder de decisão, mas tem muito poder de adoção; 2) o decisor que Jeff Patton atribui o nome de “chooser” que podem ser usuários ou não, porém tem o poder de decidir o rumo do produto; 3) legisladores; 4) patrocinadores financeiros (creio que em português seria melhor algo como financiadores) que são as pessoas que pagam pelo produto podendo ser o cliente ou até mesmo alguém da empresa investindo no projeto; e 5) especialista nos assuntos relacionados ao produto / serviço.
Lacuna de Satisfação (Satisfaction Gap)
Ainda nesse tópico, os autores aproveitam para definir um termo que acredito ser importantíssimos: Lacuna de Satisfação (Satisfaction Gap) que é, em outras palavras, a diferença na satisfação entre o que entregamos e o que o cliente esperava da entrega.
Apoiador (Supporter)
É um tipo de stakeholder que apoia a adoção do Scrum e os times Scrum. Por exemplo, alguém da Gestão de Pessoas que está mudando uma política da empresa ou contratado pessoas para compor o time. Seu trabalho não sofre impacto direto com os resultados do time Scrum, porém ela atua para auxiliar esse time. Outro exemplo é um consultor que está na empresa auxiliando na adoção do Scrum.
Inteligência Artificial
A Inteligência Artificial (IA), segundo o Scrum Guide Expansion Pack, pode ampliar capacidades do Time Scrum, especialmente na descoberta (product discovery), análise de dados, priorização contínua e identificação de padrões ocultos. Ela deve ser usada como uma ferramenta de apoio, nunca substituindo a responsabilidade (accountability) humana, e aplicada com responsabilidade, ética e supervisão (“human in the loop”).
Além do mais, a IA pode melhorar a transparência, inspeção e adaptação do Scrum, além de liberar os humanos para focar em decisões estratégicas e criativas. No entanto, é fundamental validar continuamente seus resultados e manter o foco nas dinâmicas humanas da equipe, tratando a IA como um agente auxiliar e não como tomadora de decisão autônoma.
Entretanto, Esse é um ponto que eu acho particularmente complicado. Vejo a IA como uma ferramenta, uma baita ferramenta, mas não consigo enxergá-la como um papel. Eu não tenho que conhecê-la de nada, ela não pode se negar a me responder e embora tenha esse nome de “inteligência”, hoje, ela não possui inteligência própria. Opinião do Avelino, acho que eles confundiram as coisas ou estão fazendo um exercício gigante de futurologia.
Papéis do Guia do Scrum 2020
Time Scrum (Scrum Team)
É literalmente o papel que agrupa os três papeis tradicionais. No pacote de expansão eles destacam muito a característica da autogestão. Segundo os autores, ela tem que ser coletiva: o time é responsável por se organizar, tomar decisões, resolver conflitos internos e ajustar o plano de trabalho sem intervenção externa. Times autogerenciáveis são mais aptos a lidar com a complexidade, pois podem se adaptar rapidamente e agir de forma coordenada. Isso exige um ambiente que promova confiança, autonomia e colaboração, além de liderança que habilite, e não controle, o time.
Desenvolvedor do Produto (Product Developer)
Muito, muito cuidado nesse papel, pois parece que é algo novo, mas não é. O Guia do Scrum 2020 chamou de Desenvolvedor e o Pacote de Expansão adicionou a palavra Product na frente. São as mesmas coisas, porém a expansão detalha um pouco mais.
|
Guia do Scrum 2020 |
Pacote de Expansão de 2025 |
|
Desenvolvedores |
Desenvolvedor de Produto |
|
Criar um plano para o Sprint, o Sprint Backlog; |
Criar um plano emergente no Backlog da Sprint para atingir a Meta da Sprint; |
|
Incutir qualidade aderindo a uma Definição de Pronto; |
Incutir qualidade aderindo e aprimorando a Definição de Resultado Realizado (Definition of Output Done); |
|
Criar pelo menos um Incremento utilizável a cada Sprint; |
|
|
Aprender, geralmente por meio de dados guiados pela Definição de Resultado Realizado (Definition of Output Done); |
|
|
Adaptar o plano diariamente em direção à Meta do Sprint; e |
Adaptar seu plano a cada dia em direção à Meta da Sprint; |
|
Responsabilizar-se mutuamente como profissionais. |
Responsabilizar uns aos outros como profissionais; e |
|
Melhoria real. |
Em suma, não é um papel novo, é apenas o detalhamento daqueles que já foram chamados de Time de Desenvolvimento até 2017, depois Desenvolvedores e agora é chamado de Desenvolvedor do Produto.
Eles adicionam uma informação bem severa nesse papel: “um Desenvolvedor de Produto que não está disposto, nem pronto, nem capaz de ser um profissional deve deixar o cargo de Desenvolvedor de Produto.”
Product Owner
Também vale a mesma coisa. Na prática, não foi criado um novo papel e sim uma ampliação e detalhamento das responsabilidades do Product Owner.
|
Aspecto |
Scrum Guide 2020 |
Expansion Pack 2025 |
|
Natureza do Papel |
Responsável por maximizar o valor do produto através da gestão do Product Backlog. |
Líder estratégico do Produto, com foco em valor de longo prazo e narrativa do produto. |
|
Participação organizacional |
Atua com Product Backlog, Stakeholders e Scrum Team. |
Atua em todos os níveis da organização, influenciando áreas e Stakeholders diversos. |
|
Formação |
Sem exigência explícita de skills. |
Deve possuir habilidades em gestão de produto e domínio de negócio. Caso contrário, deve ser apoiado ou substituído. |
|
Autonomia |
Tem autoridade sobre o Product Backlog. |
Tem autoridade delegada pela organização e suas decisões devem ser respeitadas por todos. |
|
Accountability |
Gestão do Product Backlog e maximização de valor. |
Responsável por: engajamento de Stakeholders, definição do Product Goal, Outcome Done, priorização e validação de valor. |
|
Criação de Product Backlog Itens (PBI) |
Responsável por criar itens do Product Backlog. |
Pode criar ou delegar a criação. O foco não é escrever PBIs, mas pensar estrategicamente e criar valor. |
|
Postura esperada |
Papel focado em produto. |
Deve agir como visionário, influenciador, representante do cliente, experimentador, decisor e facilitador de valor. |
|
Trabalho com múltiplos produtos |
Não aborda diretamente. |
Desencoraja. Caso ocorra, os outros gestores devem atuar como Stakeholders e não como co-owners. |
|
Product Owner como pessoa |
“Um único indivíduo” |
Reforça que deve ser uma única pessoa (nunca comitê ou tecnologia) e sempre humana. |
Scrum Master
De fato, de todos os papéis que já existiam, o Scrum Master foi o que eles detalharam mais. Segue o comparativo:
|
Aspecto |
Scrum Guide 2020 |
Scrum Guide Expansion Pack 2025 |
|
Natureza do papel |
Facilitador e servidor do Scrum Team |
Agente de mudança organizacional e líder sistêmico, com atuação ampla e estratégica |
|
Relação com a organização |
Trabalha com o time e partes interessadas para remover impedimentos |
Atua em todos os níveis organizacionais; treina, orienta, influencia cultura, estruturas e processos |
|
Responsabilidade primária |
Assegurar que o Scrum seja compreendido e aplicado corretamente |
Garantir a efetividade do Scrum Team e da adoção do Scrum em todos os envolvidos: PO, Stakeholders, Supporters, organização |
|
Postura esperada |
Líder Servidor |
Além de líder servidor, deve ser: mentor, coach, facilitador, removedor de impedimentos, catalisador de melhoria contínua |
|
Ações junto ao Product Owner |
Apoia na gestão do backlog, facilitação de eventos e entendimento do Scrum |
Apoia o PO em valor, objetivos estratégicos, Outcome Done, comunicação eficaz e decisões baseadas em dados |
|
Ações junto ao time |
Facilita eventos, remove impedimentos, ajuda na auto-organização |
Promove formação, upskilling *, foco em colaboração intencional, melhoria contínua, aprendizado por feedback real |
|
Ações junto aos Stakeholders |
Facilita colaboração entre o time Scrum |
Ensina de forma empírica em contexto complexo, estimula experimentação segura, promove engajamento e foco em valor real |
|
Trabalho com outros setores |
Mencionado superficialmente |
Atua com RH, financeiro, jurídico, marketing etc., fomentando mudanças para tornar a organização mais favorável ao Scrum |
|
Visão sobre eventos Scrum |
Garante que aconteçam e sejam produtivos |
Mesma função, mas com ênfase em aprendizado, ritmo sustentável e melhoria da Definição de Pronto |
|
Comportamentos não esperados |
Não listado diretamente |
Explicita o que não é ser SM: administrador, controlador de status, ausente, herói, ditador de regras, coordenador passivo |
|
Papel no todo |
Serve ao PO, Developers e à organização |
Serve ao produto, time, organização e cultura como líder transformador e facilitador de valor emergente |
|
Requisitos desejáveis |
Conhecimento do Scrum |
Espera-se conhecimento em Lean, complexidade, fluxo de valor, melhoria contínua, ética e liderança adaptativa |
|
Postura ideal |
Discreto, servidor |
Discreto, generoso, corajoso, com fome de mudança e de aprendizado, sem precisar estar no centro |
* upskilling é um neologismo-estrangeirismo que está se tornando comum em palestras e no LinkedIn. É quando você aprimora seus conhecimentos na área que trabalha. Ou seja, especialização. Outra palavra que aparece meio que fazendo o contraponto é: reskilling. Como você já deve imaginar, é quando você busca conhecimento fora da sua área de atuação, logo, generalização.
Novos Artefatos
O Guia do Scrum até 2020 foi bem simples na questão de artefatos. Eram eles: Product Backlog, Sprint Backlog e Incremento. O Pacote de Expansão do Scrum traz algumas novidades quanto a isso focando principalmente na área de domínio de negócio.
Produto
Aqui eu tenho que confessar um certo pecado. Eu jurava de pés juntos que esse artefato sempre esteve no Guia do Scrum. Como sempre falei sobre ele, acabei criando a falsa memória que ele era ali listado. Enquanto escrevia esse artigo, reparei que não. O produto é mencionado ao longo do texto, porém não está na lista de artefatos.
Aqui no Pacote de Expansão, o produto é o artefato central do Scrum. Pode ser uma experiência, serviço, plataforma, aplicação digital ou física que entrega valor contínuo aos Stakeholders. Para que o Produto seja bem-sucedido, deve ser desejável, viável, utilizável, seguro e mantido com profissionalismo. Ele possui um único Product Backlog e pode evoluir ao longo do tempo. O foco está em maximizar valor tanto no curto quanto no longo prazo, sendo a razão de existir do Time Scrum.
Product Vision (Visão do Produto)
Muito usado por diversos times, a Visão de Produto é uma representação aspiracional do Produto. Ela pode inspirar e orientar o time, sendo ponto de partida para definir Objetivos do Produto (Product Goals) que veremos mais à frente. A visão é útil, mas pode ser excessivamente abstrata e é por isso que os Product Goals se tornam necessários, para tornar a execução algo tangível e pragmático.
Product Goal
É o compromisso estratégico vinculado ao Product Backlog. Representa a grande meta que orienta a evolução do Produto. Um único Product Goal deve estar ativo por vez, e a equipe deve trabalhar até alcançá-lo ou abandoná-lo, pois se mostrou desnecessário ou inalcançável. Ele provê direção, foco e alinhamento com os Stakeholders e pode se adaptar conforme novas evidências surgem.
Definition of Outcome Done – DoOD (Definição de Pronto para Resultado)
Aqui é importante não confundir com a Definition of Done (Definição de Pronto). O DoOD é um compromisso com o produto e não com o incremento. Representa as evidências observáveis (quantitativas ou qualitativas) que demonstram a real entrega de valor para Stakeholders, ou seja, os resultados esperados são ou não atingidos. Por exemplo, ela pode estar ligada a metas específicas ou à estratégia do produto como um todo. Também é para glorificar de pé! Finalmente temos um guia de um método ágil sendo claro quanto garantir a eficácia de um produto e não apenas a eficiência. Como resultado, essa definição orienta a validação do impacto real das entregas, como satisfação do cliente, mudança de comportamento do usuário e métricas de negócio / produto.
Artefatos conhecidos, mas com algo a mais
Temos artefatos que ganharam uma repaginada, outros sem muitos mais detalhes e alguns que passaram por uma boa repaginada. Vamos a eles.
Incremento
O incremento está mais uma vez presente e continua sendo o resultado da iteração de construção do produto. Ele é o resultado do trabalho integrado e completado segundo a Definition of Output Done. É um passo concreto em direção ao Product Goal e deve ser útil e utilizável. Pode haver vários incrementos em uma Sprint.
Definition of Output Done
Esse artefato foi renomeado. O Definition of Done (Definição de Pronto) passou a se chamar Definition of Output Done, algo como Definição de Entregável Pronto ou Definição de Pronto para Entrega. Não acrescenta muita coisa ao que o Guia do Scrum 2020 já descrevia, apenas muda o nome para diferenciar do Definition of Outcome Done. A diferença básica desses dois é que o Definition of Output Done está ligado à qualidade da entrega e o Definition of Outcome Done está ligado ao resultado que obtemos com o produto inteiro.
Product Backlog e Product Backlog Item (PBI)
Esses também não tem muitas informações novas, eles mantiveram a necessidade do produto ter um único Product Backlog e que os itens que ele contém não têm uma forma pré-estabelecida.
Critérios de Aceitação – Acceptance Criteria
A novidade aqui é que eles acrescentam ao PBI os critérios de aceitação. Farei o merchant mais uma vez e digo que aqui na K21 nós já acrescentamos esse artefato à história de usuário há muito tempo.
Critérios de aceitação descrevem condições específicas que um PBI deve cumprir para ser considerado concluído. Eles complementam a Definition of Output Done com regras específicas do item. Devem ser claros, não ambíguos, e podem evoluir conforme o trabalho avança.
Critérios de Resultado – Outcome Criteria
Além dos critérios de aceitação, o PBI pode ter os Critérios de Resultado. Eles são o “porquê” por trás de um PBI — o impacto esperado. Isso também merece aplausos, pois ajudam a verificar se a entrega realmente gerou valor. Diferem-se dos critérios de aceitação, pois vão além do que foi feito, focando nos resultados desejados da entrega. Idealmente, são mensuráveis e guiados por métricas.
Sprint Backlog
Também não tem grandes informações novas. Ele é composto pelo Sprint Goal, os PBIs selecionados para a Sprint e um plano de ação para entregar o Incremento. Ele representa a visão dos Product Developers sobre o trabalho da Sprint e é ajustado ao longo dela conforme aprendizados ocorrem.
Sprint Goal (Objetivo da Sprint)
O Sprint Goal é o compromisso do Sprint Backlog. Ele dá propósito e coesão ao trabalho dos Product Developers durante a Sprint. Criado na Sprint Planning, guia as decisões da equipe e fornece flexibilidade tática. Não muda durante a Sprint, mas pode ser alcançado de formas alternativas conforme as descobertas evoluem.
Product Backlog Refinement (Refinamento do Product Backlog)
Aqui acho importante mencionar que o refinamento não está listado na seção de eventos, mas sim em artefatos do Scrum. Achei que ficou confuso, pois na primeira frase eles colocam: “Refinamento é uma atividade”. Eles o enquadram como artefato, mas creio que não é o melhor local. Também creio que “eventos” não seja o local ideal, pois é algo contínuo. Creio que poderiam criar uma unidade específica com o título de Atividades. Nela estariam o Refinamento, Descoberta (Discovery), Entrega (Delivery) e outras atividades que se repetem ao longo de todo o ciclo Scrum e não tem um momento específico para ocorrer.
Para ser mais claro, segundo os autores, o refinamento é o processo contínuo e emergente que esclarece, detalha e fatia itens do Product Backlog em partes menores e mais compreensíveis. Como consequência, ele reduz riscos e aumenta a confiança de que os itens selecionados para a Sprint podem ser completados dentro dela;
O pacote também traz a informação sobre o que podemos esperar como resultado desse refinamento. Além da descrição do item, os critérios de aceitação, critérios de resultado, prioridade, sequenciamento e tamanho.
Outra informação importante que resolve muitas dúvidas que aparecem na aula é que o Time Scrum participa do refinamento e o Product Owner é o facilitador desse refinamento. Stakeholders podem e devem ser convidados para participar da atividade.
Eventos do Scrum
Os eventos do Scrum não sofreram grandes modificações. Continuam os mesmos cinco, mas com alguns detalhes importantes. Neste artigo não vou repetir o que o Guia do Scrum 2020 já disse, apenas vou listar as mudanças de abordagens.
Sprint
Foi melhor detalhada e alguns pontos cruciais reforçados.
|
Tema |
Scrum Guide 2020 |
Expansion Pack |
|
Foco da Sprint |
Transformar um Sprint Goal em um incremento potencialmente utilizável. |
Criar valor tangível e validável, com foco em resultados (outcomes) e feedback real. |
|
Releases durante a Sprint |
Pode-se lançar a qualquer momento. |
Recomenda fortemente liberação frequente para validação de valor contínua. |
|
Quantos Incrementos |
Ao menos um por Sprint. |
Múltiplos Incrementos são incentivados dentro de uma única Sprint. |
|
Validação de valor (outcomes) |
Não aborda diretamente o conceito. |
Introduz forte ênfase em resultado de feedback (result feedback), com métricas de Outcome Done. |
|
Analogias e entendimento |
Descrito como iteração de valor. |
Descrito como um mini-projeto com objetivo claro, escopo variável e aprendizado. |
|
Encadeamento com outras Sprints |
Nova Sprint começa automaticamente. |
Destaca a Sprint como um ritmo organizacional que sustenta foco e estabilidade. |
|
Orientação à entrega |
Constrói Incremento conforme Definition of Done. |
Deve respeitar o Definition of Output Done, e permitir avaliação com base na Definition of Outcome Done. |
Sprint Planning (Planejamento da Sprint)
|
Tema |
Scrum Guide 2020 |
Expansion Pack |
|
Perguntas centrais |
– Por que esta Sprint é valiosa? – O que pode ser feito? – Como o trabalho será realizado? |
Organiza a Planning em três partes similares: “Por que?” (Sprint Goal), “O quê?” (PBIs), “Como?” (plano) — com mais profundidade. |
|
Sprint Goal |
Proposto pelo Time Scrum e refinado. |
Proposto pelo Product Owner e finalizado até o fim da Planning, com base no Product Goal. |
|
Seleção de PBIs |
Feita pelos Developers com base na meta e capacidade. |
Enfatiza seleção com base em valor, capacidade, histórico e fatiamento (vertical slicing). |
|
Plano de entrega (How) |
Desenvolvedores decidem como farão o trabalho. |
Claramente enfatizado que só os Desenvolvedores de Produto planejam o “como”, sem interferência externa. |
|
Capacidade e previsibilidade |
Usa histórico recente como referência. |
Foca fortemente em previsibilidade, fatiamento eficiente, amortecedores e evitar sobrecarga (Bayesian surprise)*. |
|
Importância do foco |
Relativa. |
Alta ênfase em foco, qualidade e finalização de trabalho antes de começar outro. |
|
Uso de técnicas adicionais |
Não mencionado. |
Sugere uso de burn ups, Monte Carlo, fuzzy sets, etc., sem substituir o empirismo. |
|
Papel do Product Owner |
Colabora com os Desenvolvedores. |
Atua como proponente inicial do Sprint Goal e ajuda a esclarecer compensações (trade-offs) de possíveis escolhas |
* Bayesian surprise, Surpresa Bayesiana, vem da teoria bayesiana de probabilidade. É uma expressão que o Jeff Sutherland utiliza bastante para descrever o efeito de mudanças repentinas e imprevisíveis durante a Sprint. Ela é a sensação que temos ou impacto psicológico negativo que ocorre quando alguma coisa inesperada ou imprevisível acontece e quebra a expectativa que tínhamos inicialmente. Por exemplo, um time faz uma Sprint Planning, combinam o Sprint Backlog. Três dias depois o Product Owner entra na sala e diz que agora a prioridade é outra e o time deve parar tudo o que está fazendo. Isso causaria uma surpresa Bayesiana.
Daily Scrum (Scrum Diária)
Essa aqui não teve grandes alterações. Eles apenas enfatizaram a importância da participação primária dos desenvolvedores de produto, o time-box de no máximo 15 minutos e o guia do Sprint Goal.
Sprint Review (Revisão da Sprint)
Também foi outro que não sofreu grandes acréscimos. Entretanto, as novidades se devem pelas questões do Product Goals.
|
Aspecto |
Scrum Guide 2020 |
Expansion Pack |
|
Objetivo |
Inspecionar Incremento e adaptar Product Backlog |
Inspecionar múltiplos aspectos do produto e planejar próximos passos |
|
Participantes |
Scrum Team e Stakeholders |
Scrum Team, Stakeholders e “Stakeholders” não-humanos (leis, normas) 😣 |
|
Destaques |
Apresentar Incremento e obter feedback |
Avaliar progresso com base em DoD, DoOD, Product Goal, e ajustar estratégia |
|
Inclusão de métricas |
Opcional |
Incentivada (progressos atuais, Outcome Done, telemetria) |
|
Itens incompletos |
Voltam para o Product Backlog |
Não são apresentados para os stakeholders |
|
Foco em adaptação futura |
Sim |
Mais explícito e ampliado (Product Goal, DoOD, Backlog) |
Sprint Retrospective (Retrospectiva da Sprint)
A “retrô” também só foi reforçada.
|
Aspecto |
Scrum Guide 2020 |
Expansion Pack |
|
Objetivo |
Melhorar qualidade e eficiência |
Além disso, melhorar a eficácia analisado resultados e supostos erros |
|
Inspeção |
Processos, colaboração, ferramentas |
Também inspeciona fluxo de valor, métricas, DoD/DoOD, inovação, cultura |
|
Profundidade da reflexão |
Alta, mas genérica |
Mais estruturada e focada em alavancas com maior impacto |
|
Valorização do que funcionou |
Sim |
Sim, e com destaque explícito para reforçar boas escolhas |
|
Acompanhamento das melhorias |
Recomendado |
Enfatizado como essencial (não pode ser só conversa). Ou seja, toda retrospectiva deve terminar com pelo menos 1 ação concreta de melhoria. |
|
Cultura de segurança psicológica |
Implicada |
Expressamente reforçada como base para aprendizado |
Scrum em Escala
Não poderia ficar de fora, o Pacote de Expansão também fala sobre agilidade em escala. Na verdade, eles escrevem mais alertas sobre o perigo da escala do que sobre como escalar.
A primeira dica é muito parecida com o formato que o Large Scale Scrum (LeSS) sempre afirmou, caso o Time Scrum se torne muito grande, ele pode ser reorganizado em vários times Scrum coesos, cada uma focada no MESMO produto. Elas compartilham o mesmo Product Goal, o mesmo Product Backlog, o mesmo e ÚNICO Product Owner e as mesmas Definition of Output Done e Definition of Outcome Done.
Os autores alertam para um problema muito comum que encontramos em diversas empresas que “escalaram” a agilidade: “Tenha cuidado com suposições cegas de que mais valor é produzido com mais Times Scrum. Escale somente quando os benefícios superarem claramente a sobrecarga adicional”. Em outras palavras, se você escala no momento em que um time não faz o seu trabalho da melhor forma possível, você só tornará o problema muito pior do que ele é. É o equivalente a escalar o Everest com uma camisa sem manga, bermuda e chinelo ou vestido de verão.
Time Scrum em escala
Eles ressaltam a importância de reduzir as dependências entre eles. Se eu tivesse que escolher o pior erro que os times que escalam cometem é esse. Criar muitas dependências por especialização e com isso filas intermináveis.Os times devem ser o mais multidisciplinares possíveis.
Product Owner em escala
O papel do Product Owner também muda um pouco. Já que ele continua sendo 1 para 1 produto, porém 1 para diversos times, ele deverá ter uma função mais estratégica. Para isso, ele deve delegar a resolução de problemas e aproveitamento de oportunidades para os Desenvolvedores de Produto, incluindo, por exemplo, aspectos de design ou gestão de Produto.
Product Backlog em Escala
Aqui eles não foram tão claros. O LeSS é categórico ao afirmar que há apenas 1 Product Backlog. Aqui eles só fazem uma recomendação quanto a ter o mínimo de backlogs possível. Se a quantidade de backlogs expandir, você terá silos de times indo cada um para o seu lado. A transparência reduz, pois cada um vai olhar para onde mais lhe agrada e o Product Owner perderá muito tempo para manter tudo alinhado. No final do texto, eles acabam recomendando fazer a mesma coisa que o LeSS faz. Tenha 1 Backlog!
Conclusão
Resumindo, o Scrum Guide Expansion Pack não pretende substituir o Scrum Guide oficial, mas expandi-lo com práticas, princípios e exemplos que aprofundam a compreensão e aplicação do Scrum em contextos reais e complexos. Ele oferece uma perspectiva mais rica sobre valor, entrega incremental, empoderamento do time e adaptação contínua — pilares essenciais em ambientes de incerteza.
Ao destacar conceitos como Definition of Outcome Done, Product Goal, fatiamento e a ampliação do papel dos Stakeholders, a expansão convida times e organizações a repensarem sua abordagem ágil de forma mais holística, centrada em resultados e não apenas em entregas.
Em síntese, mais do que seguir eventos cegamente, o Scrum proposto aqui é um convite à profissionalização contínua, ao foco estratégico e à responsabilidade compartilhada para gerar impacto. É, portanto, um material valioso para quem deseja evoluir na prática ágil, sem cair na armadilha do frÁgil.
