Como o Scrum transforma a direção do produto em uma fonte de trabalho emergente e ordenada - e como o Product Goal confere foco, transparência e um objetivo de longo prazo ao Product Backlog sem transformá-lo em um plano de projeto fixo.
Tempo estimado de leitura: 30 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender o como um artefato emergente e ordenado, explicar o propósito e a estrutura dos Items, compreender o como o compromisso de longo prazo associado ao , distinguir ordenação de priorização fixa, explicar transparência, e refinamento e reconhecer as responsabilidades do e dos que tornam esse artefato útil.
Introdução: o é um modelo vivo do que o produto precisa a seguir
O não é uma promessa sobre o futuro. Ele representa a melhor compreensão atual do sobre o que pode ser necessário, a seguir, para melhorar o produto.
O desenvolvimento de produtos sempre enfrentou um problema de planejamento difícil: quanto do futuro deve ser decidido antecipadamente? Abordagens tradicionais de requisitos frequentemente tentavam responder a essa questão criando uma especificação extensa antes do início da implementação. Isso pode funcionar quando o problema é estável e bem compreendido. Em ambientes complexos de produto, porém, clientes aprendem, concorrentes se movimentam, tecnologias mudam, regulamentações evoluem e o próprio time descobre novas informações enquanto constrói o produto.
O responde a esse cenário mantendo o trabalho do produto transparente sem fingir que o futuro está definido. O é uma lista emergente e ordenada do que é necessário para melhorar o produto. Ele é a fonte única de trabalho realizado pelo . Isso o torna, ao mesmo tempo, disciplinado e adaptativo: existe uma única fonte visível do trabalho futuro do produto, mas espera-se que seu conteúdo e sua ordem evoluam.
O Scrum Guide de 2020 fortaleceu esse artefato ao introduzir o . Antes de 2020, o possuía um , mas não havia um compromisso de artefato formalmente nomeado que expressasse o objetivo de longo prazo do produto. O passou a fornecer foco e um alvo em relação ao qual o progresso pode ser inspecionado. O restante do emerge para definir o que pode contribuir para o cumprimento desse objetivo.
Isso cria um dos equilíbrios mais importantes do . O fornece estabilidade estratégica; o fornece adaptabilidade tática. O time pode aprender e reordenar o trabalho sem perder sua direção mais ampla. Ao mesmo tempo, o próprio não é permanente. O deve cumprir ou abandonar um antes de assumir o próximo, o que significa que a direção de longo prazo é explícita, mas continua sendo empírica.
Para candidatos ao , este tema contém muitas armadilhas porque os hábitos do ambiente de trabalho frequentemente diferem do . O não precisa conter user stories. Ele não é uma lista que somente o possui e edita isoladamente. O não é responsabilidade do . O refinamento não é um evento formal. O backlog não deve ser dividido em backlogs separados de defeitos, trabalho técnico, UX e funcionalidades para o mesmo produto. Acima de tudo, o é ordenado - e não congelado em uma classificação permanente de prioridades definida meses antes.
Este capítulo desenvolve um modelo mental prático: o responde para onde o produto está tentando ir; o contém as melhores possibilidades atuais para chegar até lá; a ordenação expressa o julgamento atual sobre o que importa a seguir; o refinamento aumenta a transparência; e o mantém todo o sistema capaz de mudar quando as evidências mudam.
O : a fonte única de trabalho futuro do produto no
O Scrum Guide define o como uma lista emergente e ordenada do que é necessário para melhorar o produto. Ele é a fonte única de trabalho realizado pelo .
Cada parte dessa definição é importante. Emergente significa que o backlog não está completo antecipadamente. Ordenado significa que os itens são organizados de acordo com o julgamento atual do , em vez de existirem como um conjunto sem ordem. O que é necessário para melhorar o produto confere ao artefato uma orientação para o produto, e não apenas para funcionalidades. Fonte única de trabalho significa que o não deve manter fontes concorrentes e ocultas que contornem o .
O pode conter capacidades voltadas ao cliente, correções de defeitos, melhorias técnicas, experimentos, trabalho de redução de riscos, mudanças de arquitetura, pesquisa, trabalho de conformidade, melhorias operacionais ou qualquer outra atividade que possa ser necessária para melhorar o produto. O não divide essas categorias em tipos de artefato separados.
Isso é especialmente importante para times que herdam filas departamentais tradicionais. Se defeitos ficam em um backlog, em outro, trabalho de segurança em outro e funcionalidades em um , o não consegue ordenar de forma transparente, em um único lugar, as necessidades concorrentes do produto. A organização pode acreditar que possui uma estratégia de produto única, enquanto o , na prática, recebe trabalho de diversas fontes.
Quando vários Teams trabalham no mesmo produto, eles devem utilizar o mesmo . Isso sustenta uma única direção de produto, uma única visão ordenada do trabalho e um único , em vez de fragmentar o produto em prioridades específicas por time.
Âncora para o
Um produto -> um . Ele é a fonte única de trabalho realizado pelo .
Emergente não significa desorganizado
Um backlog emergente muda à medida que o conhecimento muda. Isso não significa ser caótico, permanecer incompleto por negligência ou ser reescrito aleatoriamente todos os dias.
Um saudável possui transparência suficiente para as decisões atuais de produto. Os itens próximos do topo costumam ser mais bem compreendidos porque têm maior probabilidade de ser selecionados em breve. Itens mais distantes podem permanecer mais amplos e menos detalhados, pois gastar muito tempo definindo trabalho distante pode gerar desperdício caso as prioridades mudem.
A emergência permite que o incorpore aprendizados provenientes de Increments, Reviews, clientes, stakeholders, operações, mudanças de mercado, experimentos, descobertas técnicas e novas restrições. Itens podem ser adicionados, removidos, divididos, combinados, reescritos, reordenados ou abandonados.
O ajuda a impedir que a emergência se torne sem direção. Novas informações podem alterar a rota, enquanto o objetivo fornece um destino. Quando as evidências sugerem que o próprio destino deixou de ser valioso, o pode ser abandonado e substituído - mas manter um ativo por vez preserva o foco.
Essa é uma diferença central em relação a uma linha de base tradicional de requisitos. Uma baseline trata a mudança como um desvio a ser controlado. Um emergente trata a mudança como consequência normal do aprendizado, enquanto transparência e responsabilidade mantêm essa mudança disciplinada.
Items: unidades de possibilidade para o produto
As entradas individuais do são chamadas de Items, frequentemente abreviadas como PBIs. Um PBI representa algo que o pode precisar fazer para melhorar o produto.
O não exige que um PBI seja uma . User stories podem ser uma técnica útil, mas funcionalidades, defeitos, experimentos, trabalho técnico, pesquisa, atividades de redução de risco, documentação, infraestrutura e outras formas de representação podem ser Items válidos.
O Scrum Guide afirma que o refinamento do é uma atividade contínua que adiciona detalhes como descrição, ordem e tamanho. Os atributos exatos variam conforme o domínio do trabalho. Isso é intencionalmente leve. O não prescreve modelos de , formatos de stories, ,, campos no nem uma hierarquia obrigatória como -feature-story.
Um PBI precisa de transparência suficiente para as decisões que estão sendo tomadas naquele momento. Um item considerado para uma próxima exige maior entendimento compartilhado do que uma ideia ampla que talvez se torne relevante apenas daqui a seis meses. Isso cria elaboração progressiva em vez de detalhamento prematuro.
Items que podem ser concluídos pelo dentro de uma são considerados prontos para seleção no . Normalmente, eles adquirem esse grau de transparência após atividades de refinamento. Aqui, a palavra ready é uma descrição utilizada no Scrum Guide, e não uma exigência de uma separada.
Armadilha de formato
O exige Items, não user stories. Uma é apenas uma técnica opcional para expressar um PBI.
: o objetivo de longo prazo do
O é o compromisso associado ao . Ele descreve um estado futuro do produto que pode servir como alvo para o planejamento do .
O está contido no , e o restante do emerge para definir o que poderá concretizá-lo. Essa relação é importante: o objetivo não é um documento de estratégia separado e desconectado do trabalho cotidiano do produto. Ele fornece contexto ao artefato utilizado para o planejamento.
O Scrum Guide define o como o objetivo de longo prazo do . O não prescreve um horizonte de tempo exato. Um pode exigir várias Sprints ou um período muito maior, dependendo do produto e da natureza do objetivo.
Longo prazo não significa vago. Uma afirmação como “deixar os clientes mais satisfeitos” pode ser ampla demais para orientar escolhas significativas. Um mais forte descreve um estado futuro do produto com clareza suficiente para que o time e os stakeholders inspecionem o progresso e avaliem se os Items contribuem para ele.
Materiais de aprendizagem da .org frequentemente posicionam Product Goals entre uma Product Vision aspiracional e Goals individuais. O próprio não exige uma Product Vision, mas o conceito pode ser útil: uma Product Vision pode descrever um futuro amplo; o estabelece o objetivo atual de longo prazo; e Goals sucessivos criam etapas menores em direção a ele.
O deve criar foco sem prescrever a implementação. Se ele especifica cada funcionalidade que deve ser entregue, comporta-se como escopo fixo. Um útil define o estado futuro desejado, deixando espaço para que o aprenda a melhor maneira de alcançá-lo.
Um por vez
O é uma unidade coesa focada em um objetivo por vez: o . O Scrum Guide também afirma que o time deve cumprir ou abandonar um antes de assumir o próximo.
Essa regra protege o foco. Organizações frequentemente chamam cinco iniciativas estratégicas de “prioridade máxima”. Quando se espera que um persiga simultaneamente diversos objetivos de longo prazo sem relação entre si, a ordenação do torna-se política e os Goals podem se fragmentar em trabalhos desconectados.
Um único não significa que o possa conter somente itens que contribuam de maneira óbvia e direta para esse objetivo. Produtos possuem necessidades operacionais, trabalho de qualidade, defeitos urgentes, obrigações regulatórias ou investimentos técnicos. A ideia central é que um objetivo de longo prazo forneça o foco atual segundo o qual as decisões de produto podem ser compreendidas.
O objetivo pode ser cumprido quando o estado futuro desejado é alcançado. Também pode ser abandonado quando as evidências mostram que continuar deixou de ser valioso. Abandonar um objetivo não é necessariamente fracasso; no desenvolvimento empírico de produtos, interromper investimentos em uma direção invalidada pode preservar valor significativo.
Regra de foco
Muitos Product Goals podem existir ao longo da vida de um produto, mas o concentra-se em um ativo por vez.
Como o evolui em torno do
O estabelece o alvo; o contém a compreensão em evolução do que pode ser necessário para alcançá-lo. Isso torna a relação dinâmica, e não contratual.
Suponha que um seja permitir que clientes de pequenas empresas abram uma conta digitalmente, sem assistência de uma agência. Os primeiros Items podem envolver verificação de identidade, envio de documentos, orientação de onboarding, controles antifraude, ativação da conta e acessibilidade.
Após várias Sprints, evidências do produto podem mostrar que o envio de documentos não é o principal problema dos clientes. A maior taxa de abandono pode ocorrer durante a verificação de titularidade. O continua valioso, mas a ordem do muda radicalmente. Alguns itens planejados descem na ordem, novos experimentos surgem e itens existentes são divididos ou removidos.
É exatamente isso que a emergência deve proporcionar. O time permanece comprometido com o objetivo, recusando-se, porém, a permanecer comprometido com premissas que as evidências enfraqueceram.
A é um importante ponto de feedback porque o e os stakeholders inspecionam resultados e o progresso em direção ao . Novas informações podem então influenciar o . O refinamento continua durante a para que os próximos itens reflitam o conhecimento atual.
Responsabilidade do pela gestão do
O é responsável por maximizar o valor do produto resultante do trabalho do . A gestão eficaz do é parte central dessa responsabilidade.
O Scrum Guide identifica quatro responsabilidades explícitas de : desenvolver e comunicar explicitamente o ; criar e comunicar claramente os Items; ordenar os Items; e garantir que o seja transparente, visível e compreendido.
O pode executar esse trabalho pessoalmente ou delegar atividades a outras pessoas. A delegação não transfere a responsabilidade. Analistas, , designers, pesquisadores, especialistas de domínio ou outras pessoas podem ajudar a criar, refinar, descrever ou analisar Items, mas o continua responsável por uma gestão eficaz do .
Essa distinção ajuda produtos de grande porte a escalar sem criar comitês de Product Owners. Um único pode contar com ampla colaboração e, ao mesmo tempo, manter um ponto único de responsabilidade pelas decisões de valor e pela ordenação do .
A organização deve respeitar as decisões do para que essa responsabilidade funcione. Stakeholders podem influenciar a ordenação com evidências e necessidades, mas contornar o e atribuir trabalho diretamente aos destrói a transparência do artefato.
Transparência: o deve ser visível e compreendido
A transparência não é alcançada simplesmente colocando Items em uma ferramenta que todos tecnicamente conseguem acessar. O deve ser visível e compreendido o suficiente para sustentar inspeção e tomada de decisão.
Um transparente comunica a direção atual do produto, a ordenação atual, contexto suficiente sobre os itens e o . Stakeholders devem conseguir compreender o que o sabe, naquele momento, sobre o trabalho futuro do produto e discutir trade-offs de forma produtiva.
A transparência também expõe decisões difíceis. Se uma solicitação de um executivo estiver abaixo, no , de uma melhoria de confiabilidade, a ordenação torna esse trade-off visível. Os stakeholders podem discordar, mas a divergência ocorre em torno de um único artefato transparente, e não por meio de filas ocultas.
A falta de transparência aparece quando trabalho importante existe em planilhas privadas, mensagens diretas, projetos paralelos, sistemas separados de defeitos ou compromissos executivos não declarados. Nesses casos, o artefato deixa de ser a fonte única de trabalho e a inspeção empírica torna-se incompleta.
A transparência é sempre contextual. Informações sensíveis podem exigir controles de acesso apropriados. O não exige visibilidade pública irrestrita; exige visibilidade precisa e suficiente para as pessoas que precisam decisões de produto.
Ordenação: expressando o julgamento atual sobre o produto
O é ordenado, e não apenas categorizado por rótulos de prioridade. A ordenação força decisões relativas: se dois itens disputam atenção limitada, qual deles deve ser considerado primeiro de acordo com o conhecimento atual?
O não prescreve o algoritmo. O pode considerar valor esperado, risco, aprendizado, custo, dependências, criticidade temporal, conformidade, impacto no cliente, alinhamento estratégico, habilitação técnica ou outros fatores.
Essa flexibilidade é importante porque uma fórmula universal de priorização não consegue representar todos os contextos de produto. Um item de conformidade com baixa geração direta de receita pode precisar vir primeiro porque o produto não pode operar legalmente sem ele. Um experimento arriscado pode ser antecipado porque pode invalidar uma estratégia cara. Um item técnico pode habilitar diversas capacidades valiosas.
O é responsável pela ordem, mas uma boa ordenação é colaborativa. revelam dependências técnicas e riscos. Stakeholders fornecem evidências e restrições. O pode ajudar a melhorar o planejamento empírico do produto. O integra essas perspectivas em um único ordenado.
A ordenação deve mudar quando as evidências mudam. Tratar uma classificação de seis meses como fixa pode criar aparência de previsibilidade enquanto, na prática, impede a maximização de valor.
Possível fator de ordenação
Pergunta que o pode considerar
Valor para cliente/usuário
O item resolve um problema importante do usuário ou melhora um resultado relevante?
Risco/incerteza
Fazer isso antes exporia uma premissa perigosa antes de um investimento maior?
Criticidade temporal
O atraso reduzirá materialmente a oportunidade ou criará dano regulatório ou de negócio?
Dependências
Isso habilita ou desbloqueia outro trabalho valioso?
Qualidade/saúde técnica
Isso reduz defeitos, fragilidade, risco operacional ou custo futuro de mudança?
Aprendizado
Isso produzirá evidências capazes de alterar a estratégia do produto ou a ordenação futura?
Tamanho: os são responsáveis pelo dos Items
O refinamento do pode adicionar um tamanho aos Items. Os que realizarão o trabalho são responsáveis pelo .
Essa é uma fronteira específica de responsabilidade. O pode explicar valor, esclarecer contexto, discutir trade-offs e questionar premissas, mas não atribui unilateralmente tamanhos ao trabalho dos .
O não prescreve um método de .,, tamanhos de camiseta, contagem de itens, probabilística ou outras técnicas podem ser utilizadas quando forem úteis. Um time também pode evoluir ou substituir sua técnica ao longo do tempo.
O tamanho deve apoiar a tomada de decisão, não se transformar em uma nota de desempenho. Comparar entre times, forçar estimativas a corresponder a metas de gestão ou equiparar mais pontos a mais valor pode distorcer comportamentos.
não é sinônimo de valor. Um item grande pode ter pouco valor; uma mudança muito pequena pode gerar valor enorme. Por isso, a ordenação do deve combinar julgamento de valor com informações dos sobre tamanho, risco e viabilidade.
Armadilha do
Os que realizarão o trabalho são responsáveis por dimensionar os Items. O não exige .
Refinamento do : aumentando a transparência antes da seleção do trabalho
O refinamento do é o ato de decompor e definir com mais detalhes os Items, transformando-os em itens menores e mais precisos. Trata-se de uma atividade contínua.
O refinamento pode adicionar ou melhorar detalhes como descrição, ordem e tamanho. Também pode remover trabalho obsoleto, dividir itens grandes, esclarecer premissas, revelar dependências, expor riscos técnicos e melhorar o entendimento compartilhado.
O refinamento não é um dos cinco eventos formais do . O não prescreve uma reunião obrigatória de refinamento, uma agenda fixa, uma lista de participantes nem um . Os times podem agendar sessões de trabalho, refinar continuamente, utilizar conversas em pequenos grupos ou adaptar sua abordagem ao contexto do produto.
Orientações antigas do e muitos materiais de treinamento mencionam gastar até dez por cento da capacidade com refinamento. Isso não é uma regra do Scrum Guide atual. O Guide de 2020 reduziu intencionalmente o nível de prescrição. Para o , não trate “10%” como uma exigência obrigatória do .
O refinamento deve ser economicamente sensato. Refinar itens muito antecipadamente pode gerar desperdício, pois premissas e ordenação podem mudar antes que o trabalho seja selecionado. Os itens mais relevantes e próximos costumam merecer maior nível de detalhe.
Um bem refinado melhora o porque os podem selecionar trabalho com maior entendimento e confiança. Um backlog mal refinado transforma o em uma longa sessão de descoberta.
Quanto detalhe o deve conter?
Não existe tamanho obrigatório para o , número exigido de itens nem horizonte de planejamento prescrito. A quantidade adequada de informação depende da incerteza do produto e das decisões que o precisa tomar.
Um com milhares de itens detalhados pode criar uma falsa sensação de certeza. Muitos desses itens podem se tornar obsoletos antes de serem selecionados. Mantê-los consome tempo e pode ocultar as poucas decisões que realmente importam.
No outro extremo, um backlog contendo apenas ideias vagas pode tornar o pouco confiável e reduzir a transparência. O desafio é o detalhamento progressivo: mais informação onde as decisões estão próximas e menos onde o futuro permanece incerto.
Uma heurística útil é que itens próximos do topo sejam, em geral, menores, mais claros e melhor compreendidos do que itens distantes. Isso não é uma regra do , mas decorre naturalmente do planejamento empírico.
O também ajuda a controlar o tamanho do backlog. Se um item não tiver relação plausível com a melhoria do produto, com obrigações atuais ou com o , o deve questionar por que ele está consumindo atenção.
Exemplo prático - um para abertura digital de contas
Imagine um responsável pelo produto de abertura digital de contas de um banco. O é: permitir que clientes elegíveis de pequenas empresas abram e ativem uma conta digitalmente, sem visitar uma agência.
O contém várias possibilidades atuais: simplificar a verificação de titularidade, melhorar a captura de documentos de identidade, integrar uma fonte de dados de registro empresarial, reduzir a revisão manual de fraude, melhorar a acessibilidade, corrigir um defeito de ativação e fortalecer o logging de auditoria.
No início, o acredita que a captura de documentos seja o maior problema dos clientes e ordena vários itens relacionados próximos do topo. Os refinam os itens, explicam que uma das mudanças propostas no processamento de imagens é grande e sugerem um experimento menor que possa testar a premissa mais cedo.
Durante uma , o time libera analytics aprimorados e descobre que a maior parte do abandono ocorre, na verdade, durante a verificação de titularidade. Na , stakeholders do atendimento ao cliente confirmam que os usuários têm dúvidas sobre quais proprietários precisam ser declarados. O continua válido, mas a ordem do muda.
O move melhorias de verificação de titularidade para posições superiores, remove um item de captura de documentos que deixou de ser necessário e adiciona um pequeno experimento com perguntas orientadas sobre titularidade. Um item de integração com registro empresarial é dividido porque os descobrem que uma parte pode reduzir o esforço do cliente sem aguardar a integração completa.
Em seguida, um stakeholder da área regulatória apresenta uma nova exigência de auditoria. Ela não melhora diretamente a experiência do cliente, mas é necessária para que o produto permaneça em conformidade. O ordena adequadamente o trabalho de logging em relação às demais necessidades, em vez de colocá-lo em um “backlog de compliance” separado.
Durante o refinamento, os dimensionam os próximos itens. O não dita . Em vez disso, explica que o experimento de titularidade é altamente sensível ao tempo porque uma campanha de marketing começará em breve. Essa informação de valor ajuda o time e o a discutir trade-offs úteis.
Após várias Sprints, o alcança o estado futuro descrito pelo : pequenas empresas elegíveis conseguem abrir e ativar contas digitalmente com resultados aceitáveis de conclusão, fraude e conformidade. O time cumpre esse e pode então adotar o próximo objetivo de longo prazo.
Esse exemplo demonstra o sistema central: o fornece continuidade; o evolui à medida que as evidências mudam; a ordenação expressa o julgamento atual de valor; o refinamento aumenta a transparência; e o feito pelos informa decisões sem substituir a responsabilidade do .
Antipadrões comuns e armadilhas do
Armadilha / antipadrão
Interpretação correta no
O é uma baseline fixa de requisitos.
Falso. Ele é emergente e evolui à medida que mais é aprendido.
O deve conter user stories.
Falso. O não prescreve formato para PBIs.
Cada que trabalha no mesmo produto deve ter seu próprio .
Falso. Um produto utiliza um único .
Defeitos e devem ficar fora do .
Falso. O é a fonte única de trabalho necessário para melhorar o produto.
O deve escrever pessoalmente todos os PBIs.
Falso. O trabalho pode ser delegado; a responsabilidade permanece com o .
O é responsável por dimensionar os PBIs.
Falso. Os que realizarão o trabalho são responsáveis pelo .
são exigidos pelo .
Falso. O não prescreve técnica de .
O refinamento do é um evento formal do .
Falso. Trata-se de uma atividade contínua.
O refinamento deve consumir 10% da .
Falso segundo o Scrum Guide atual. Nenhum percentual obrigatório é definido.
O deve estar completamente detalhado antes de o desenvolvimento começar.
Falso. O detalhamento emerge progressivamente.
O é uma lista de funcionalidades.
Falso. Ele descreve um estado futuro do produto e um objetivo de longo prazo.
O pode perseguir vários Product Goals simultaneamente.
Falso. O time se concentra em um ativo por vez.
Um nunca pode ser abandonado.
Falso. Ele deve ser cumprido ou abandonado antes da adoção do próximo.
Stakeholders podem reordenar diretamente o .
Falso. Eles influenciam; o é responsável pela ordenação.
Ordenar significa usar uma única fórmula obrigatória de priorização.
Falso. O não prescreve algoritmo de ordenação.
Um framework de raciocínio para questões de sobre
Fonte única: todo o trabalho de produto conhecido do está representado por um único ?
Emergência: o backlog pode crescer, encolher e mudar à medida que as evidências mudam?
Ordenação: a resposta preserva a responsabilidade do pela ordenação?
: existe um único objetivo ativo de longo prazo fornecendo foco?
Transparência: o é visível e compreendido o suficiente para sustentar inspeção?
Formato de PBI: a resposta evita inventar user stories, modelos de aceitação ou campos de ferramenta como obrigatórios?
: a responsabilidade pelo tamanho permanece com os que farão o trabalho?
Refinamento: o refinamento é tratado como atividade contínua, e não como evento formal ou regra obrigatória de 10%?
Delegação: outras pessoas podem ajudar a gerenciar detalhes do backlog enquanto a responsabilidade do permanece intacta?
: resultados de Sprints e evidências de stakeholders podem alterar o backlog e até levar ao abandono de um ?
Heurística rápida para a prova
= para onde estamos tentando levar o produto. = nossa melhor compreensão atual e ordenada do que pode ser necessário para chegar lá.
Conclusão: a direção deve ser estável o suficiente para gerar foco e flexível o suficiente para permitir aprendizado
O e o formam um dos sistemas de planejamento mais importantes do . O fornece ao um objetivo de longo prazo. O contém a compreensão evolutiva e ordenada do que pode ser necessário para melhorar o produto e cumprir esse objetivo.
O é emergente porque produtos complexos revelam informações durante o desenvolvimento. Ele pode crescer, encolher, ser reordenado e mudar. Isso não é planejamento fraco; é planejamento projetado para incorporar evidências. O impede que essa adaptabilidade se torne sem direção ao criar um único foco estratégico ativo.
Items são intencionalmente leves. O não exige user stories, , modelos de nem uma ferramenta específica. Os itens precisam de transparência suficiente para as decisões atuais, e o refinamento melhora progressivamente sua descrição, ordem e tamanho.
As responsabilidades mantêm o artefato disciplinado. O é responsável pela gestão eficaz do e pela comunicação do . Os que realizarão o trabalho são responsáveis pelo . Stakeholders contribuem com evidências e necessidades, mas não controlam diretamente a ordenação.
O refinamento sustenta a transparência, mas permanece uma atividade contínua, e não um evento prescrito. Essa flexibilidade é importante porque produtos diferentes exigem quantidades e estilos diferentes de refinamento. O Guide atual evita intencionalmente regras como uma alocação obrigatória de dez por cento.
Os Product Backlogs mais fortes não tentam documentar todas as possibilidades futuras. Eles tornam visíveis as escolhas atuais mais importantes, mantendo espaço para descoberta. Os Product Goals mais fortes não ditam uma lista de funcionalidades. Eles descrevem um estado futuro do produto com clareza suficiente para focar decisões, permitindo que o caminho emerja.
Na minha visão, essa relação captura a atitude do em relação à incerteza melhor do que quase qualquer outra parte do framework. Uma gestão de produto fraca muda de direção constantemente ou se recusa a mudar. O oferece uma alternativa mais disciplinada: comprometer-se com um objetivo significativo, inspecionar continuamente as evidências e estar disposto a mudar tudo sobre a rota - ou até abandonar o objetivo - quando a realidade justificar essa decisão.
Principais conclusões
O é uma lista emergente e ordenada do que é necessário para melhorar o produto.
Ele é a fonte única de trabalho realizado pelo .
Um produto deve ter um , mesmo quando vários Teams trabalham nele.
Items podem representar qualquer trabalho necessário para melhorar o produto; o não exige user stories.
O é o compromisso associado ao .
O descreve um estado futuro do produto e é o objetivo de longo prazo do .
O concentra-se em um ativo por vez e deve cumpri-lo ou abandoná-lo antes de adotar o próximo.
O evolui à medida que o aprende com Increments, stakeholders, clientes, tecnologia e o ambiente.
O é responsável pela comunicação do , pela comunicação dos PBIs, pela ordenação do e pela transparência do backlog.
O trabalho de pode ser delegado, mas a responsabilidade do permanece.
O deve ser transparente, visível e compreendido.
A ordenação é contextual; o não prescreve uma fórmula de priorização.
Os que realizarão o trabalho são responsáveis por dimensionar os PBIs.
O não exige nem qualquer técnica específica de .
O refinamento do é uma atividade contínua que adiciona detalhes, ordem e tamanho e decompõe o trabalho em itens menores e mais precisos.
O refinamento não é um evento formal do e não possui uma alocação obrigatória de 10% do tempo no Scrum Guide atual.
