Por que esta Sprint é valiosa, o que pode ser Done e como o trabalho será realizado - um guia aprofundado sobre planejamento colaborativo, Sprint Goals, previsões, autonomia dos Developers e criação do Sprint Backlog inicial.
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 a como um evento colaborativo do ; explicar a estrutura Por quê-O quê-Como; distinguir de ; entender como os selecionam items e fazem previsões do trabalho; explicar como o inicial é criado; e reconhecer as armadilhas mais comuns sobre na avaliação .
Introdução: planejamento empírico da
A não é uma tentativa de prever a com perfeição. É o momento em que o cria direção compartilhada suficiente e um plano inicial acionável para começar a aprender de maneira inteligente.
O planejamento tradicional de projetos frequentemente busca confiança por meio do aumento do nível de detalhe. Requisitos são decompostos, atividades são sequenciadas, dependências são mapeadas, estimativas são negociadas e um cronograma é produzido antes do início da execução. Isso pode ser útil quando o trabalho é previsível. No desenvolvimento de produtos complexos, porém, maior detalhamento do planejamento não cria necessariamente maior certeza. O que é desconhecido permanece desconhecido até que o produto, a tecnologia, os usuários e o ambiente forneçam evidências.
O responde planejando em vários horizontes. O fornece direção de longo prazo. O contém a compreensão atual e ordenada do trabalho que pode melhorar o produto. A cria um plano de curto horizonte para uma . Durante a , os atualizam esse plano à medida que aprendem. Assim, o sistema de planejamento é contínuo e empírico, em vez de concentrado em um único grande evento preditivo.
A inicia a . Ela não é uma reunião realizada em preparação para uma que começará depois. O plano criado durante a torna-se imediatamente o plano inicial da ativa. Todo o colabora, porque valor do produto, direção do produto, viabilidade, capacidade, conhecimento técnico, qualidade e risco de entrega precisam convergir em uma única conversa.
O Scrum Guide 2020 tornou a estrutura da especialmente clara ao enfatizar três tópicos. Primeiro: Por que esta é valiosa? Segundo: O que pode ser Done nesta ? Terceiro: Como o trabalho escolhido será realizado? Esses não são itens burocráticos de pauta. Eles formam uma cadeia lógica. Sem o Por quê, o time pode otimizar a produção sem compreender o valor. Sem o O quê, o objetivo não possui uma realista. Sem o Como, os items selecionados permanecem desejos em vez de um plano viável.
Este capítulo desenvolve essa cadeia em profundidade. Ao longo do caminho, distinguiremos de compromisso, explicaremos por que os - e não o ou o - selecionam e planejam o trabalho da , mostraremos como e se conectam e examinaremos por que um é intencionalmente incompleto e deve evoluir. Essas distinções são essenciais tanto para a prática profissional do quanto para a avaliação .
Propósito e trabalho colaborativo
O Scrum Guide define diretamente o propósito da : ela inicia a ao estabelecer o trabalho a ser realizado durante a . O plano resultante é criado por meio do trabalho colaborativo de todo o .
Essa última expressão é importante. não é uma passagem de trabalho do para os . Não é uma negociação entre a gestão e um time de entrega. Tampouco é uma cerimônia na qual o lê uma lista de verificação. Todo o colabora porque cada accountability contribui com um tipo diferente de conhecimento.
O traz o contexto de valor do produto, a direção do , a ordenação do e o conhecimento dos stakeholders. Os trazem conhecimento de entrega, capacidade, risco técnico, considerações de qualidade, experiência de Sprints anteriores e compreensão do que é realisticamente alcançável. O ajuda todos a compreender e utilizar o de maneira eficaz e pode facilitar quando isso for útil, mas a facilitação não torna o o proprietário do plano.
O time pode convidar outras pessoas para participar da e fornecer aconselhamento. Isso é útil quando um especialista, representante de cliente, especialista em segurança, arquiteto, cientista ou especialista de domínio pode melhorar a compreensão. Esses convidados aconselham; eles não adquirem uma accountability do nem autoridade para atribuir tarefas.
O resultado da é o inicial: o , os items selecionados para a e o plano acionável para entregar o . Como o é emergente, a palavra inicial é importante. O planejamento inicia a ; ele não a congela.
Âncora para a
A é um trabalho colaborativo de todo o . Seu resultado é o inicial, e não um contrato de escopo fixo.
Tópico Um: Por que esta é valiosa?
O primeiro tópico da pergunta por que vale a pena investir nesta . O propõe como o produto poderia aumentar seu valor e sua utilidade durante a atual. Em seguida, todo o colabora para definir um que comunique por que a é valiosa para os stakeholders.
Começar pelo Por quê representa uma grande melhoria conceitual em relação ao planejamento que começa perguntando quantos itens do backlog cabem na . Um time pode concluir com eficiência um grande volume de trabalho e, ainda assim, criar pouco valor. O força o time a discutir o resultado ou o progresso que justifica consumir mais uma de capacidade profissional.
O ocupa posição central porque maximizar o valor do produto é sua accountability. Entretanto, ele não simplesmente anuncia o . Todo o colabora para defini-lo. Os podem revelar oportunidades técnicas, riscos de entrega ou maneiras mais eficazes de criar o resultado desejado. O pode ajudar o time a criar foco e evitar que o objetivo se transforme em uma lista de tarefas.
O deve estar finalizado antes do término da . A partir daí, torna-se o compromisso associado ao e o único objetivo da . Ele fornece estabilidade suficiente para que os possam adaptar o trabalho exato, preservando o propósito da .
Um útil descreve por que a importa sem prescrever todos os detalhes de implementação. "Concluir os itens 124, 129 e 133" é uma lista, não um objetivo significativo. "Reduzir falhas no checkout para clientes recorrentes em dispositivos móveis" expressa um resultado de produto e permite que os descubram o melhor trabalho necessário para alcançá-lo.
O também comunica valor aos stakeholders. Um stakeholder que leia o deve conseguir compreender a direção da sem interpretar dezenas de tarefas técnicas. Isso aumenta a transparência e favorece Reviews significativas.
Por quê antes de volume
A não deve começar mentalmente com "Quantos pontos cabem?". A pergunta mais importante é: "Qual objetivo valioso esta deve fazer avançar?"
e
O e o operam em horizontes de planejamento diferentes. O descreve um estado futuro do produto e é o objetivo de longo prazo do . O descreve o único objetivo da atual.
A deve conectar esses horizontes. O assegura que os participantes estejam preparados para discutir items importantes e como eles se relacionam ao . Normalmente, o deve representar um passo significativo em direção a esse objetivo de prazo mais longo.
Essa conexão evita a otimização local. Sem ela, um pode criar bons Goals que não se acumulam em progresso coerente do produto. Uma melhora relatórios, outra redesenha uma página, outra altera infraestrutura e outra adiciona uma solicitação de marketing, mas o produto nunca se aproxima de um estado estratégico claro.
A conexão não significa que cada selecionado para a deva se relacionar mecanicamente ao . Algum trabalho necessário pode apoiar manutenção, redução de riscos ou outras necessidades do produto. O ponto crítico é que o confere coerência à e o confere direção estratégica à sequência de Sprints.
Para raciocinar na , mantenha a hierarquia simples: é o objetivo de longo prazo e o compromisso associado ao . é o objetivo da e o compromisso associado ao . A conecta ambos por meio de valor e planejamento.
Tópico Dois: O que pode ser Done nesta ?
Depois que o compreende por que a é valiosa, a aborda o que pode realisticamente ser Done durante a . Por meio de discussão com o , os selecionam items para incluir na atual.
A palavra selecionar é importante. Os não recebem do uma atribuição obrigatória de escopo. O ordena o e explica valor e trade-offs. Os decidem quanto podem prever de maneira responsável com base no conhecimento do trabalho e em sua capacidade.
O pode refinar items durante a para aumentar a compreensão e a confiança. Isso reforça que refinement é uma atividade contínua, e não um evento obrigatório separado. Se um item não possuir clareza suficiente, a pode incluir discussão adicional, decomposição ou esclarecimento.
Selecionar uma quantidade apropriada de trabalho é algo intencionalmente empírico. O Scrum Guide não fornece uma fórmula. Os podem considerar desempenho anterior, capacidade disponível, , riscos conhecidos, complexidade do produto, feriados, responsabilidades de suporte, dependências técnicas ou qualquer outra evidência relevante para a .
A é especialmente importante porque "quanto pode ser Done" significa quanto pode alcançar o estado de qualidade utilizável acordado - e não quanto pode ser codificado, projetado, analisado ou parcialmente testado. Um planejamento fraco ignora o custo de qualidade necessário para finalizar. Um planejamento profissional o inclui.
O desempenho histórico também importa, mas deve informar, não controlar. Um time pode analisar trabalho concluído, , ou outras evidências empíricas de Sprints anteriores. O não exige velocity, ou qualquer técnica específica de estimativa. O objetivo é uma crível, e não a conformidade com uma métrica.
Os items selecionados são mais bem compreendidos como uma do que os acreditam poder realizar enquanto perseguem o . Trabalho complexo contém incerteza; portanto, não é possível garantir honestamente o escopo exato na .
Isso não torna a informal. Os devem usar julgamento profissional e as melhores evidências disponíveis. Uma é uma declaração séria sobre o que parece realista nas condições atuais. Ela apenas reconhece que novas informações podem tornar incorretos os detalhes originais.
A distinção entre e compromisso é um dos conceitos mais importantes da . O é o compromisso associado ao . Os items selecionados não se transformam individualmente em compromissos imutáveis por entrarem na .
Se o trabalho se mostrar diferente do esperado, os colaboram com o para negociar o escopo sem afetar o . Isso oferece ao uma combinação poderosa: compromisso com o propósito e flexibilidade na execução.
Organizações que transformam a em um contrato fixo frequentemente criam comportamentos prejudiciais. Times escondem descobertas, reduzem a qualidade, evitam experimentação, inflacionam estimativas ou tratam adaptação como fracasso. O , ao contrário, espera que o se torne mais preciso à medida que a realidade é descoberta.
x compromisso
Os fazem uma dos items selecionados. O é o compromisso associado ao . O escopo exato da pode se adaptar à medida que se aprende mais.
O Scrum Guide é explícito: por meio de discussão com o , os selecionam os items a serem incluídos na atual. Isso preserva a fronteira entre accountability de valor e accountability de entrega.
O decide a ordenação do e pode explicar por que determinados itens são valiosos. Os determinam o que acreditam poder realizar durante a , considerando capacidade, qualidade, risco e realidade técnica. Nenhum dos lados consegue produzir um bom plano sozinho.
Se o atribui unilateralmente dez itens, a dos é enfraquecida. Se os ignoram a ordenação do e selecionam apenas trabalhos tecnicamente interessantes, a accountability de valor do é enfraquecida. A é o ponto de colaboração em que ambas as perspectivas produzem um único plano.
Stakeholders não selecionam diretamente o trabalho da . Eles podem influenciar o antes e durante discussões sobre o produto, e o pode convidá-los para aconselhamento. Entretanto, a não é uma fila aberta de solicitações em que cada stakeholder adiciona escopo.
O também não decide quanto trabalho entra na . Ele pode ajudar a expor premissas irreais, orientar o planejamento empírico e facilitar a discussão. A continua pertencendo aos .
Tópico Três: Como o trabalho escolhido será realizado?
O terceiro tópico da passa da intenção do produto para o plano de entrega. Para cada selecionado, os planejam o trabalho necessário para criar um que atenda à .
É aqui que a autonomia técnica se torna explícita. O Scrum Guide afirma que a forma de realizar esse trabalho fica a critério exclusivo dos . Ninguém mais lhes diz como transformar items em Increments de valor.
Planejar o Como pode incluir decisões de arquitetura, estratégia de testes, colaboração em design, trabalho de integração, preparação de dados, segurança, deployment, experimentos, spikes técnicos, documentação, sequenciamento, pairing, ou qualquer outro trabalho necessário para criar um Done. O deliberadamente não prescreve práticas de engenharia ou de domínio.
O Scrum Guide observa que os frequentemente decompõem items em itens menores de trabalho, com duração de um dia ou menos. A palavra "frequentemente" importa: a decomposição é útil, mas o não exige granularidade ou formato obrigatório para tarefas.
O propósito da decomposição não é o controle administrativo. Ela ajuda os a criar um plano suficientemente acionável, identificar dependências e riscos e estabelecer uma base para inspeção diária. Planejamento insuficiente pode deixar o time sem um ponto de partida viável. Planejamento detalhado demais pode desperdiçar tempo, porque o evoluirá de qualquer forma.
Um time maduro planeja o suficiente para começar com confiança e deixa espaço para o que emergir. Essa é a essência do planejamento empírico: uma hipótese inicial crível, seguida de inspeção e adaptação contínuas.
Como o inicial é formado
O , os items selecionados para a e o plano para entregá-los formam, em conjunto, o . Portanto, o artefato espelha diretamente os três tópicos da .
Tópico do planejamento
Componente do
Significado
Por quê
Por que a é valiosa e qual único objetivo confere coerência à .
O quê
items selecionados
O que os atualmente preveem que pode ser Done durante a .
Como
Plano acionável de entrega
Como os atualmente planejam criar o Done.
O é um plano feito pelos e para os . Ele é altamente visível e representa o trabalho que os planejam realizar para alcançar o . Deve conter detalhe suficiente para apoiar a inspeção no .
O artefato, intencionalmente, não é finalizado na . Conforme aprendem, os o atualizam. Tarefas podem surgir ou desaparecer. Itens selecionados podem ser renegociados. O plano técnico pode mudar significativamente. Isso não significa que a falhou; significa que o plano está se tornando mais preciso.
Um que não pode mudar é incompatível com a teoria empírica do . O oferece estabilidade, enquanto o artefato evolui à medida que as evidências melhoram.
Participantes e contribuições
A pertence a todo o . Compreender as diferentes contribuições evita confusões comuns sobre papéis.
Participante
Contribuição para a
Traz o contexto de valor, a direção do , a ordenação do e prepara o time para discutir PBIs importantes. Propõe como valor e utilidade poderiam aumentar.
Selecionam PBIs, fazem a do que pode ser Done, determinam o Como, criam o plano do e consideram qualidade e capacidade.
Ajuda todos a compreender o , assegura que o evento seja positivo, produtivo e permaneça dentro de seu , e pode facilitar sem assumir as decisões.
Todo o
Colabora para definir o e criar entendimento compartilhado da .
Consultores convidados
Podem fornecer aconselhamento especializado quando útil, mas não recebem accountability do nem autoridade sobre o plano da .
como alvo de planejamento
O não é criado novamente a cada . Ele já existe no como o objetivo de longo prazo do . A o utiliza como alvo de planejamento.
Antes da , o deve assegurar que os participantes estejam preparados para discutir items importantes e como eles se relacionam ao . Essa preparação ajuda a evitar que o evento se transforme em uma leitura a frio das entradas do backlog.
O permite que o avalie se uma proposta cria progresso coerente. Se um não possui relação significativa com a direção atual do produto, o time deve inspecionar o motivo. Pode haver uma necessidade urgente legítima, mas a desconexão deve ser transparente.
O também favorece a comunicação com stakeholders. Eles podem compreender que a atual não é um compromisso isolado, mas um passo empírico em uma jornada de produto mais longa.
Evidências para uma crível
O Scrum Guide destaca três tipos de informação que aumentam a confiança dos ao selecionar quanto trabalho prever: desempenho passado, capacidade disponível e .
O desempenho passado fornece evidências sobre o que o time efetivamente conseguiu concluir. É mais útil do que uma suposição abstrata sobre produtividade ideal. Os times podem utilizar Sprints anteriores, ,, estimativas históricas, items concluídos ou outras evidências adequadas ao contexto.
A capacidade disponível reconhece que a próxima não é idêntica à anterior. Férias, feriados, suporte à produção, treinamento, atividades externas conhecidas ou mudanças no time podem afetar o que é realista. Capacidade não é um convite para alocar cada pessoa a 100% de utilização; é informação para a .
A esclarece o custo real da conclusão. Se Done inclui integração, testes automatizados, verificações de segurança, documentação, observabilidade ou prontidão para deployment, essas atividades precisam ser consideradas no planejamento. Contar apenas o esforço de implementação criaria uma irrealista.
Em conjunto, essas entradas formam um planejamento empírico. O time usa o que sabe, reconhece abertamente a incerteza e produz uma que pode ser adaptada à medida que novas informações surgem.
da
A possui máximo de oito horas para uma de um mês. Para Sprints mais curtas, o evento normalmente é mais curto.
O é um máximo, não um objetivo. Um time maduro, com refinado, claro, forte colaboração e domínio familiar, pode terminar bem antes do máximo. Outro time, lidando com alta incerteza, pode precisar de mais tempo e ainda assim permanecer dentro do limite.
O incentiva preparação e foco. A não deve ser utilizada para realizar toda a , refinement, análise de arquitetura ou negociação com stakeholders que deveriam ter acontecido continuamente antes do evento.
Ao mesmo tempo, otimizar apenas para uma reunião muito curta pode ser prejudicial. Se um time conclui a em vinte minutos, mas sai sem um significativo ou um plano acionável, a velocidade substituiu a eficácia.
O não especifica fórmulas proporcionais como "quatro horas para uma de duas semanas". O Guide afirma que Sprints mais curtas normalmente têm eventos de planejamento mais curtos. A regra formal máxima é de oito horas para uma de um mês.
Armadilha do
Oito horas é o máximo para uma de um mês, não uma duração obrigatória e tampouco uma fórmula que deva ser dividida proporcionalmente para Sprints mais curtas.
Detalhe suficiente para um plano acionável
Um útil precisa conter detalhe suficiente para que os comecem o trabalho e inspecionem o progresso. Não precisa conter um mapa preditivo completo de tarefas para cada dia da .
Planejamento insuficiente cria ambiguidade. Dependências permanecem ocultas, trabalhos importantes de qualidade são esquecidos e os podem descobrir imediatamente que os items selecionados não foram compreendidos. Planejamento excessivo cria falsa confiança e consome tempo produzindo detalhes que a realidade invalidará.
A profundidade apropriada do planejamento depende de risco, incerteza, experiência do time, maturidade do produto e contexto técnico. Uma alteração de manutenção familiar pode exigir pouquíssima decomposição. Uma integração arriscada pode se beneficiar de experimentos explícitos, caminhos de fallback e validação técnica antecipada.
A sugestão do Scrum Guide de que o trabalho frequentemente é decomposto em itens de um dia ou menos oferece uma heurística útil de planejamento, mas não uma regra obrigatória. A intenção é tornar o plano acionável e inspecionável, não padronizar o tamanho das tarefas.
O e a colaboração contínua entre fazem parte do sistema de planejamento. A estabelece o plano inicial. A adaptação diária mantém sua utilidade.
como evento empírico
A é um evento empírico porque se baseia em evidências atuais, e não em uma alegação de perfeita. O propõe valor com base no conhecimento do produto. Os fazem previsões com base na capacidade real e em evidências históricas. O time cria um objetivo e um plano que serão testados pela própria .
A transparência é essencial. Se o estiver pouco claro, a capacidade estiver oculta, as expectativas de qualidade forem ambíguas ou riscos técnicos forem suprimidos, a será construída sobre informações falsas. A inspeção, então, torna-se enganosa.
A adaptação começa ainda durante o planejamento. O pode refinar items à medida que novas perguntas surgem. Um proposto pode mudar durante a discussão. Os podem revisar a quantidade de trabalho selecionado quando a revelar esforço oculto.
Após a , o ciclo empírico continua. Os Daily Scrums inspecionam o progresso em direção ao . Os atualizam o . O e os renegociam escopo quando necessário. A fornece evidências sobre o produto, e a Retrospective melhora a eficácia futura. Portanto, o planejamento é um ciclo contínuo, não um evento isolado.
Exemplo prático: em uma plataforma de APIs
Imagine um responsável por uma plataforma de APIs utilizada por produtos bancários internos. O é tornar APIs críticas mais fáceis de integrar e mais confiáveis sob alto volume de transações.
Antes da , o ordenou o com base em evidências recentes. Incidentes em produção mostram que uma dependência de autenticação cria latência elevada durante picos de tráfego. Times internos de produto relatam que tentativas de retry são difíceis de diagnosticar. Os refinaram vários items relacionados e compreendem o contexto técnico atual.
O Tópico Um começa com valor. O propõe que a próxima reduza falhas relacionadas à autenticação para consumidores de APIs de alto volume. O discute se esse é o objetivo de curto prazo mais valioso e cria um : melhorar a resiliência da autenticação para tráfego de APIs em pico, preservando os controles de segurança.
O Por quê agora está claro. A não é valiosa porque o time concluirá quatro tickets; ela é valiosa porque o produto deve se tornar mais resiliente para um grupo significativo de usuários.
O Tópico Dois aborda o que pode ser Done. Os discutem com o os items de maior ordem. Consideram seu desempenho anterior, as férias planejadas de um Developer, a e o trabalho conhecido de suporte operacional. Selecionam itens relacionados a cache de dependência, observabilidade de retries, testes de desempenho e rollout seguro.
Os itens selecionados formam uma , não um escopo fixo garantido. Uma melhoria de dashboard de menor valor permanece fora da porque os entendem que o trabalho de qualidade exigido pelos itens mais importantes já consome uma quantidade realista de capacidade.
O Tópico Três aborda o Como. Os planejam um experimento antecipado de teste de carga, colocam especialistas de API e segurança em pairing no design do cache, definem mudanças de observabilidade, identificam uma sequência de deployment e decompõem diversos itens em trabalhos menores. O responde a perguntas sobre comportamento aceitável e risco de negócio, mas não dita a implementação.
O percebe que o time está discutindo se um stakeholder deseja adicionar uma funcionalidade de analytics não relacionada. Em vez de decidir por eles, o ajuda o time a retornar ao e à ordenação do . A funcionalidade permanece no para consideração futura.
Ao final da , o contém o , os items selecionados e um plano inicial acionável. O time não finge que o plano está completo. No segundo dia, um teste de carga pode revelar um gargalo diferente. Se isso acontecer, os atualizarão o enquanto protegem o .
Isso é profissional: valor primeiro, realista em segundo lugar, plano técnico acionável em terceiro, seguido de adaptação empírica contínua.
Antipadrões
Antipadrão
Por que enfraquece o
Sem
O evento se torna um exercício de carregamento de tarefas e a fica sem um objetivo coerente.
atribui o escopo
Enfraquece a dos e transforma uma em um contrato imposto.
conduz o planejamento como gerente de projetos
O pode facilitar, mas não é proprietário do escopo nem do plano dos .
Somente participam
e fazem parte do ; a é trabalho colaborativo de todo o .
Somente o fala
O planejamento exige conhecimento dos sobre viabilidade, risco, capacidade e aspectos técnicos.
Todo PBI deve se relacionar individualmente ao
O cria coerência, mas o não define essa regra rígida.
determina escopo obrigatório
Dados históricos podem informar a , mas nenhuma métrica do determina uma quantidade obrigatória de trabalho.
O planejamento cria um congelado
O é atualizado ao longo da .
A é ignorada na
A se torna irrealista porque o verdadeiro custo da qualidade utilizável fica oculto.
Todo o design técnico deve ser concluído no planejamento
Os precisam de um plano acionável, não de um design preditivo completo de cada detalhe futuro.
Stakeholders adicionam trabalho urgente diretamente
Stakeholders podem aconselhar e influenciar por meio do ; eles não controlam a seleção da .
é refinement
Refinement pode ocorrer durante o planejamento, mas a possui o propósito mais amplo de Por quê-O quê-Como.
O máximo de oito horas deve sempre ser utilizado
O evento termina quando seu propósito é atingido; oito horas é apenas o máximo para uma de um mês.
Armadilhas da
Armadilha
Interpretação correta no
A ocorre antes da .
Falso. A inicia a .
Somente os participam.
Falso. Todo o participa.
O define sozinho o .
Falso. O propõe valor; todo o colabora para definir o .
Os devem aceitar os PBIs de maior prioridade selecionados pelo .
Falso. Os selecionam itens por meio de discussão com o .
Os PBIs selecionados são um compromisso com o escopo exato.
Falso. Eles são uma ; o é o compromisso associado ao .
O decide como o trabalho será implementado.
Falso. O Como fica a critério dos .
O decide se a é aceitável.
Falso. O pode orientar ou facilitar; a pertence aos .
Toda deve durar oito horas.
Falso. Oito horas é o máximo para uma de um mês.
Uma de duas semanas possui obrigatório de quatro horas para a Planning.
Falso. Sprints mais curtas normalmente têm planejamentos mais curtos, mas o não define fórmula proporcional.
O é finalizado e não pode mudar após a Planning.
Falso. Ele evolui à medida que os aprendem.
Refinement não pode ocorrer durante a .
Falso. O pode refinar itens selecionados durante o evento.
O é criado durante cada .
Falso. Ele é o compromisso de longo prazo associado ao e serve como alvo de planejamento.
Os devem usar para fazer a .
Falso. O não prescreve técnica de estimativa.
O Como deve estar completamente decomposto antes do início da .
Falso. O plano deve ser acionável, mas planejamento e adaptação adicionais continuam durante a .
Checklist para raciocinar na
Por quê: o está discutindo por que esta é valiosa e criando um ?
: a proposta se conecta de maneira significativa à direção de longo prazo do produto?
O quê: os estão selecionando uma realista por meio de discussão com o ?
Evidências: desempenho passado, capacidade disponível e estão informando a ?
Como: os mantêm critério exclusivo sobre como PBIs se tornam Increments Done?
: o resultado inclui , PBIs selecionados e um plano acionável?
Adaptabilidade: o pode evoluir durante a ?
: a Planning permanece dentro do máximo de oito horas para uma de um mês, sem inventar regras proporcionais rígidas?
Colaboração: todo o está envolvido sem transformar o evento em atribuição de tarefas conduzida pela gestão?
x compromisso: o é tratado como compromisso enquanto o escopo exato selecionado permanece adaptável?
Heurística rápida para a prova
Valor primeiro (Por quê), realista dos em segundo lugar (O quê), plano de implementação pertencente aos em terceiro (Como).
Conclusão: planejamento empírico em ação
A é o ato de abertura de cada e uma das demonstrações mais claras de planejamento empírico no . O não tenta prever cada detalhe do trabalho complexo. Ele estabelece um objetivo valioso, uma realista e um plano inicial acionável, e então espera que o aprendizado melhore esse plano.
O Por quê dá propósito à . O propõe como valor e utilidade poderiam aumentar, e todo o colabora para definir o . Esse objetivo torna-se o compromisso associado ao e fornece estabilidade de propósito.
O O quê transforma propósito em . Os selecionam items por meio de discussão com o , utilizando seu conhecimento sobre desempenho passado, capacidade disponível e . O escopo selecionado é sério, mas não congelado.
O Como transforma a em um plano acionável. Os determinam como o trabalho selecionado se tornará um Done. O protege sua autonomia técnica e profissional porque decisões de implementação complexas precisam permanecer próximas das pessoas que estão descobrindo o trabalho.
Em conjunto, Por quê, O quê e Como criam o inicial. A palavra inicial importa. A própria produzirá evidências. Os inspecionarão o progresso, atualizarão o plano, renegociarão escopo quando necessário e protegerão o .
Na minha visão, os Teams mais maduros saem da com confiança, mas não com certeza. Eles compreendem por que a importa, o que atualmente parece alcançável, como pretendem começar e quais premissas podem mudar. Isso não é um planejamento mais fraco. É um planejamento projetado para a realidade - exatamente o tipo de raciocínio esperado na avaliação .
Principais aprendizados
A inicia a .
O plano resultante é criado pelo trabalho colaborativo de todo o .
O pode convidar outras pessoas para fornecer aconselhamento.
O Tópico Um pergunta: Por que esta é valiosa?
O propõe como o produto poderia aumentar valor e utilidade; todo o colabora para definir o .
O deve ser finalizado antes do término da .
O Tópico Dois pergunta: O que pode ser Done nesta ?
Os selecionam items por meio de discussão com o .
Desempenho passado, capacidade disponível e aumentam a confiança na .
Os items selecionados são uma , não um compromisso de escopo fixo.
O Tópico Três pergunta: Como o trabalho escolhido será realizado?
Os têm critério exclusivo sobre como items são transformados em Increments de valor.
Os frequentemente decompõem o trabalho em itens menores, mas o não exige formato específico de tarefa.
O , os PBIs selecionados e o plano de entrega formam, em conjunto, o .
O é um plano feito pelos e para os , e evolui durante a .
A possui máximo de oito horas para uma de um mês; Sprints mais curtas normalmente têm Plannings mais curtas.
O fornece o alvo de prazo mais longo que a deve ajudar a avançar.
Questões da frequentemente testam dos , versus compromisso e a estrutura Por quê-O quê-Como.
