Um método repetível de raciocínio para a PSM I que ajuda a identificar a pessoa responsável, proteger o objetivo dos eventos e os compromissos, aplicar o empirismo, preservar o autogerenciamento, eliminar processos inventados e escolher a resposta mais forte sob a pressão da prova.
Tempo estimado de leitura: 30 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá ser capaz de aplicar um filtro de raciocínio com dez perguntas às questões situacionais da , eliminar alternativas plausíveis porém incorretas, distinguir regras do framework de práticas opcionais, explicar por que uma resposta é mais forte que outra e resolver cenários envolvendo ,,, eventos do , artefatos, compromissos, , autogerenciamento, ,, impedimentos, e .
Introdução: pare de procurar a frase - reconstrua o framework
Questões situacionais são difíceis porque várias respostas podem parecer razoáveis. A melhor resposta geralmente é aquela que preserva o sistema do , e não a que soa mais gerencial.
A avaliação não testa apenas se você consegue repetir definições. Ela verifica se você consegue aplicar a situações nas quais autoridade, incerteza, qualidade, objetivos, stakeholders e comportamento do time interagem. Uma questão pode descrever um problema de trabalho perfeitamente comum e oferecer quatro respostas que, à primeira vista, parecem úteis.
A habilidade decisiva é reconstruir o framework. Em vez de perguntar "Qual frase do Scrum Guide eu lembro?", pergunte: "Que parte do esta situação está testando?" A questão é realmente sobre a responsabilidade do ? Proteção do ? Autogerenciamento dos ?? Objetivo do evento? Transparência?
Essa abordagem reflete o motivo pelo qual o próprio foi concebido. se fundamenta no : torne a realidade transparente, inspecione-a e adapte-se com base em evidências. O raciocínio situacional deve funcionar do mesmo modo. Primeiro, identifique o que realmente está acontecendo; depois, inspecione as restrições do framework; por fim, escolha uma adaptação que preserve responsabilidades e objetivos.
O Scrum Guide é deliberadamente pequeno e propositalmente incompleto. Isso importa porque muitos distratores adicionam processos que nunca exigiu: cadeias de escalonamento, estimativas obrigatórias, gates de aprovação, atribuição de tarefas, reuniões especiais, gerentes de projeto ou uma técnica de engenharia específica. Uma resposta pode soar organizada e, ainda assim, enfraquecer .
O método deste capítulo converte o framework em dez perguntas diagnósticas. Em uma questão difícil, talvez você não precise de todas as dez. Muitas vezes, as quatro primeiras eliminam metade das alternativas, e o teste de autogerenciamento ou o teste de limite do Scrum Guide elimina o restante.
O método também é útil fora da certificação. Organizações frequentemente enfrentam a mesma ambiguidade: o deve resolver um problema ou fazer coaching do time? O escopo pode mudar? Quem decide? Uma solicitação de stakeholder é uma decisão do ou uma decisão do plano dos ? Um bom raciocínio produz decisões mais rápidas, claras e responsáveis.
O limite final continua importante: é um framework complementar de escalabilidade mantido pela .org. Ele se apoia em e o estende minimamente, mas não é o básico definido pelo Scrum Guide. Se uma questão situacional disser apenas , não importe responsabilidades, eventos, artefatos ou compromissos específicos do .
O método de raciocínio situacional em 10 perguntas
Use as perguntas na ordem quando um cenário parecer ambíguo. Elas avançam dos fatos estruturais para os princípios empíricos e, por fim, para verificações de limite do framework.
Figura 1. As dez perguntas transformam a em uma sequência diagnóstica para uso durante a prova.
#
Pergunta
Por que funciona
1
Quem possui a responsabilidade?
Impede que a autoridade seja deslocada para a pessoa errada.
2
Qual é o objetivo do evento?
Evita que , Review, Retro e Planning virem reuniões genéricas.
3
Qual artefato está envolvido?
Identifica o trabalho ou valor visível que está sendo discutido.
4
Qual compromisso deve ser protegido?
Encontra o limite do , ou .
5
Qual opção aumenta a transparência?
Prefere a realidade visível a status oculto ou relato excessivamente otimista.
6
Qual opção permite inspeção?
Cria oportunidade para aprender com o produto ou trabalho real.
7
Qual opção favorece a adaptação?
Permite que evidências alterem os planos sem destruir objetivos ou qualidade.
8
Qual opção preserva o autogerenciamento?
Mantém as decisões com as pessoas responsáveis por elas.
9
Alguma opção transforma o em chefe?
Elimina atribuição de tarefas, e substituição gerencial.
10
A prática mencionada realmente existe no Scrum Guide?
Elimina práticas opcionais apresentadas como obrigatório.
1. Quem possui a responsabilidade?
Comece pelas pessoas. Muitas questões situacionais se tornam fáceis assim que a responsabilidade correta é identificada.
O é responsável por maximizar o valor do produto e pela gestão eficaz do . O é responsável por estabelecer conforme definido e pela eficácia do . Os são responsáveis por criar um utilizável, pelo , por aderir à , por adaptar o plano diariamente e por responsabilizar-se profissionalmente uns com os outros.
A armadilha é confundir colaboração com autoridade. O pode colaborar sobre o , mas não atribui tarefas aos . O pode facilitar conversas sobre o , mas não ordena o . Stakeholders podem influenciar decisões de valor, mas não priorizam diretamente os .
Responsabilidade
Âncora principal para a prova
Território situacional típico
Valor, , gestão do
Direção do produto e ordenação
conforme definido, eficácia do
Sistema, coaching, impedimentos, eventos, organização
utilizável, , qualidade, adaptação diária
Como o trabalho é feito e como o plano da evolui
Atalho de responsabilidade
Se uma resposta desloca uma decisão para longe da pessoa ou do grupo explicitamente responsável por ela, examine essa alternativa com muito cuidado.
2. Qual é o objetivo do evento?
Os eventos do não são reuniões genéricas. Cada um existe para um propósito específico de inspeção e adaptação.
Um distrator frequentemente descreve uma atividade útil, mas a coloca no evento errado. Por exemplo, um relatório de status pode ser útil à gestão, mas isso não o transforma no objetivo do . Uma demonstração de funcionalidade pode ser útil, mas isso não reduz a a uma demo.
Evento
Propósito a reconstruir
Iniciar a estabelecendo por que ela é valiosa, o que pode ser Done e como o trabalho será realizado.
Inspecionar o progresso em direção ao e adaptar o .
Inspecionar o resultado da com stakeholders e determinar adaptações futuras.
Planejar maneiras de aumentar qualidade e eficácia.
Contêiner de todos os eventos e cadência para transformar ideias em valor.
Teste do evento
Quando duas respostas parecerem plausíveis, prefira aquela que melhor atende ao propósito do evento sem inventar autoridade ou cerimônia adicional.
3. Qual artefato está envolvido?
Os artefatos indicam que tipo de evidência ou plano a questão realmente está tratando. Questões sobre normalmente envolvem direção do produto, ordenação, refinamento e trabalho futuro. Questões sobre dizem respeito ao plano da atual. Questões sobre dizem respeito a valor de produto utilizável e qualidade.
Depois de identificar o artefato, pergunte imediatamente qual é o seu compromisso. O par artefato-compromisso é um dos dispositivos de raciocínio mais fortes para a .
4. Qual compromisso deve ser protegido?
se relaciona ao . se relaciona ao . se relaciona à .
Isso importa porque questões situacionais frequentemente perguntam se algo pode mudar. A resposta muitas vezes depende de qual compromisso cria o limite. O pode mudar enquanto o fornece direção. O escopo do pode mudar enquanto o protege o foco. A implementação pode mudar, mas o trabalho não faz parte do até atender à .
Artefato
Compromisso
Questão situacional que ajuda a resolver
Direção para decisões de produto
Propósito e coerência da
Estado transparente de qualidade
5-7. Use os três pilares como teste de qualidade da resposta
Depois das perguntas estruturais, teste as alternativas restantes contra o . se apoia em transparência, inspeção e adaptação. Respostas fortes normalmente melhoram a qualidade de um ou mais desses ciclos.
Transparência significa que o estado real está visível. Inspeção significa que as pessoas certas conseguem examinar evidências relevantes com frequência suficiente para detectar problemas ou oportunidades. Adaptação significa que planos ou comportamentos podem mudar quando as evidências mostram um caminho melhor.
Observe a ordem. Uma resposta que oculta trabalho incompleto, mas promete inspecioná-lo depois, é fraca porque a inspeção se baseia em falsa transparência. Uma resposta que cria um dashboard, mas nunca adapta nada, é reporting, não .
Pilar
Comportamento de uma resposta forte
Sinal de alerta
Transparência
Tornar objetivos, trabalho, qualidade, progresso e problemas visíveis.
Ocultar trabalho inacabado; relatar status otimista.
Inspeção
Examinar produto, artefatos, progresso e resultados.
Basear-se apenas em conformidade com o plano ou opiniões.
Adaptação
Alterar plano/processo com base em evidências, protegendo os compromissos.
Congelar escopo ou processo apesar de novo aprendizado.
8. Qual opção preserva o autogerenciamento?
Autogerenciamento não é uma preferência cultural suave. O Scrum Guide afirma explicitamente que os Teams decidem internamente quem faz o quê, quando e como.
Distratores situacionais frequentemente centralizam decisões em um , gerente de projeto, arquiteto, gerente funcional ou stakeholder. Pergunte se essa pessoa está fornecendo uma restrição legítima ou se está tomando uma decisão que pertence ao ou aos .
Autogerenciamento ainda inclui responsabilidade e limites organizacionais. Políticas de segurança, legislação, , e podem restringir escolhas. O teste é saber se o time mantém seu espaço legítimo de decisão dentro desses limites.
Heurística de autogerenciamento
Prefira a resposta que fornece às pessoas responsáveis informações e limites suficientes para que decidam, em vez da resposta que decide por elas.
9. A alternativa transforma o em chefe?
Este único teste elimina uma quantidade surpreendente de respostas erradas.
O pode ensinar, fazer coaching, mentorar, facilitar, influenciar a gestão, fazer com que impedimentos sejam removidos e até ser direto quando os limites do ou riscos sérios exigem clareza. Nada disso cria autoridade hierárquica sobre ou .
Sinais de alerta incluem atribuir tarefas, aprovar estimativas, decidir implementação técnica, ordenar Items, avaliar desempenho individual, aceitar trabalho em nome de stakeholders ou atuar como destinatário obrigatório de status.
Ação do
Raciocínio
Fazer coaching dos sobre um problema recorrente de colaboração
Coerente com o serviço do
Atribuir PBIs aos com base em habilidade
Armadilha de
Ensinar um stakeholder por que a não é um gate de aprovação
Coerente com o serviço do
Aprovar o do time
Não é responsabilidade do
Facilitar uma Retrospective difícil
Pode ser apropriado
Escolher a arquitetura porque o time está travado
Normalmente toma para si o espaço de decisão dos
10. A prática mencionada realmente existe no Scrum Guide?
O filtro final protege o limite do . é propositalmente incompleto. Uma prática pode ser excelente e, ainda assim, não ser exigida por .
Questões da frequentemente exploram candidatos que já trabalharam em times e, por isso, assumem que técnicas familiares são obrigatórias. Separe sempre "comumente usado com " de "definido por ".
Prática
Status correto no
User Stories
Formato opcional de
Método opcional de
Técnica opcional de estimativa
Métrica histórica local opcional
Burndown / Burnup
Visualizações opcionais para
Clarificação opcional específica de PBI
Política opcional, não um compromisso do
/ / /
Práticas complementares de engenharia
Estratégia complementar de fluxo
Framework complementar de escalabilidade da .org
Regra de limite
Se a questão disser MUST, REQUIRED ou ALWAYS e a prática não for um elemento essencial do , desconfie de uma armadilha.
O fluxo de eliminação em 45 segundos
Na prova, talvez você não queira executar conscientemente as dez perguntas todas as vezes. Comprima o método em um fluxo de eliminação de cinco etapas.
Figura 2. Um fluxo rápido de eliminação para questões sob pressão de tempo.
Leia primeiro a frase final: que decisão a questão está pedindo que você tome?
Identifique a âncora: responsabilidade, evento, artefato, compromisso ou pilar empírico.
Elimine qualquer resposta que viole claramente ,, ou autogerenciamento.
Entre as respostas restantes, prefira a que aumenta a transparência útil e permite inspeção e adaptação.
Prefira o processo menos inventado. raramente precisa de uma camada extra de aprovação, reunião obrigatória ou gerente para resolver algo que o framework já atribui.
Exemplo resolvido 1 - Stakeholder adiciona trabalho urgente no meio da
Cenário: um stakeholder sênior diz aos que adicionem uma funcionalidade urgente de relatórios durante a . O concorda que a funcionalidade é valiosa. Adicioná-la provavelmente impediria o time de alcançar o atual. O que deve acontecer?
Aplique o método. Responsabilidade: o gerencia decisões de valor do , enquanto os são donos do plano do . Evento: não é principalmente uma questão de evento. Artefato: . Compromisso: . O permite adaptação, mas o Scrum Guide afirma explicitamente que não são feitas mudanças que coloquem o em risco.
Portanto, a resposta mais forte é preservar o . A funcionalidade pode ser ordenada no para consideração futura. e podem renegociar o se uma mudança continuar apoiando o mesmo , mas não devem forçar trabalho que o coloque em risco.
Raciocínio correto
O é adaptável; o é o limite de compromisso. Urgência, por si só, não o substitui.
Exemplo resolvido 2 - virou relatório de status
Cenário: os respondem três perguntas todas as manhãs enquanto o registra status para a gestão. A reunião permanece dentro de 15 minutos. Qual é a melhoria mais importante?
Responsabilidade: os conduzem o . Objetivo do evento: inspecionar o progresso em direção ao e adaptar o . Autogerenciamento: reportar status ao afasta o evento da propriedade dos .Limite do Guide: as três perguntas não são obrigatórias no Guide de 2020.
A resposta mais forte é ajudar os a reorganizar o em torno do progresso em direção ao e da adaptação do plano. Manter a reunião dentro de 15 minutos é necessário, mas insuficiente se o propósito estiver errado.
Exemplo resolvido 3 - Trabalho incompleto na
Cenário: uma funcionalidade funciona em um ambiente de demonstração, mas ainda não concluiu os testes de segurança exigidos pela . Um stakeholder quer que ela seja mostrada como concluída durante a .
Artefato: . Compromisso: . Transparência: chamar a funcionalidade de Done tornaria a qualidade do produto opaca. A não pode aprovar uma exceção, porque a Review não cria o status do .
A funcionalidade não faz parte do . O time pode discutir honestamente o trabalho inacabado e o aprendizado, mas não deve apresentá-lo como parte concluída do .
Raciocínio correto
prevalece sobre prontidão para demonstração. O compromisso de qualidade não é dispensado pelo entusiasmo de um stakeholder.
Exemplo resolvido 4 - quer aumentar a
Cenário: o pede ao que faça o time aumentar a em 20% na próxima porque executivos querem mais produtividade.
Responsabilidade: o maximiza valor; o melhora a eficácia; os se autogerenciam. Limite do Guide: não é uma métrica oficial do . Risco de transparência: transformar pontos em uma meta pode distorcer estimativas em vez de melhorar valor.
Uma resposta mais forte é ajudar os stakeholders a esclarecer o resultado que desejam - entrega de valor mais rápida, menor , melhor previsibilidade ou mais valor ao cliente - e inspecionar evidências relevantes para esse resultado. O não deve transformar em uma meta obrigatória de desempenho.
Exemplo resolvido 5 - considera cancelar a
Cenário: na metade da , um PBI de alta prioridade se mostra muito mais difícil do que o esperado. O considera cancelar a para que o time reinicie com um plano melhor.
Responsabilidade: somente o pode cancelar. Compromisso: . Porém, a autoridade por si só não é a regra completa. O cancelamento é apropriado quando o se torna obsoleto, e não porque a estava incorreta ou o trabalho está difícil.
Se o ainda for valioso, os devem adaptar o e colaborar com o sobre o escopo. Cancelar apenas para reiniciar uma confunde o compromisso do com a conclusão de PBIs.
Exemplo resolvido 6 - resolve todos os impedimentos
Cenário: os relatam todos os bloqueios ao . O contata outros times, resolve problemas de ambiente, agenda todas as conversas e acompanha pessoalmente cada dependência. A entrega está melhorando, mas o time espera pelo sempre que surge um novo obstáculo.
Responsabilidade: o faz com que impedimentos sejam removidos; os são solucionadores profissionais de problemas e se autogerenciam. A resposta deve preservar tanto a eficácia quanto o crescimento da capacidade.
O deve ajudar os a resolver problemas dentro de sua autoridade, fazer coaching de colaboração direta e intervir mais diretamente quando as barreiras forem organizacionais ou estiverem além da capacidade do time. O objetivo não é maximizar a atividade do ; é construir um mais eficaz e autônomo.
Exemplo resolvido 7 - como cerimônia de aprovação
Cenário: a organização se recusa a liberar qualquer Done até que stakeholders de negócio o aprovem na .
Objetivo do evento: a inspeciona o resultado e determina futuras adaptações. Artefato/compromisso: + . O Scrum Guide afirma explicitamente que um pode ser entregue antes de a terminar e que a nunca deve ser considerada um gate para liberar valor.
A resposta mais forte é remover a interpretação da Review como gate de aprovação. Políticas organizacionais de release podem existir, mas , por si só, não usa a como permissão para liberar um Done.
Exemplo resolvido 8 - Uma resposta em uma questão de básico
Cenário: três Teams trabalham no mesmo produto. Uma alternativa afirma que eles devem criar um porque exige isso sempre que vários times compartilham um produto.
Limite do Guide: no básico, times que trabalham no mesmo produto compartilham o mesmo ,, e . O pertence ao Guide, não ao Scrum Guide.
Portanto, a alternativa está errada, a menos que o cenário declare explicitamente que a organização está usando . se apoia em e o estende minimamente; é complementar, não automático.
Limite na prova
Vários Teams não significam automaticamente . Se não for mencionado, raciocine a partir do Scrum Guide.
Exemplo resolvido 9 - Stakeholders querem um comitê de
Cenário: cinco unidades de negócio discordam sobre a ordenação do . Elas propõem um comitê em que cada unidade teria um voto e o desempata.
A responsabilidade resolve a questão imediatamente. O é uma única pessoa e continua responsável pela ordenação do e pela maximização de valor. Stakeholders devem influenciar, fornecer evidências e tentar convencer o . O pode melhorar a colaboração, mas não se torna a autoridade de desempate do produto.
A resposta correta fortalece a transparência com stakeholders e a responsabilidade do , em vez de substituí-la por governança por comitê.
Exemplo resolvido 10 - diz aos quanto trabalho selecionar
Cenário: na , o diz que o time deve selecionar doze PBIs porque concluiu doze na anterior.
Objetivo do evento: criar um plano para a . Responsabilidade: os selecionam PBIs por meio de discussão com o ; sua confiança é informada pelo desempenho passado, pela capacidade e pela . O fornece contexto de valor e ordenação, mas não prescreve a quantidade da .
A resposta mais forte permite que os façam a do que conseguem realizar enquanto todo o colabora em um valioso. Desempenho histórico é evidência, não cota.
Quando duas respostas são plausíveis
Questões difíceis frequentemente deixam duas respostas que não estão obviamente erradas. Use quatro critérios de desempate.
Primeiro, prefira a redação explícita do a uma invenção razoável. Segundo, preserve o espaço de decisão da pessoa responsável. Terceiro, prefira a opção que fortalece o e a capacidade de longo prazo, e não apenas a conveniência de hoje. Quarto, prefira uma resposta que resolva o problema no nível apropriado mais baixo, sem introduzir hierarquia desnecessária.
Critério de desempate
Preferência
Regra explícita do framework
Mais forte que uma boa prática gerencial genérica
Responsabilidade preservada
Mais forte que transferir a decisão para um ajudante/gerente
Feedback empírico melhorado
Mais forte que conformidade rígida com o plano
Autogerenciamento de longo prazo
Mais forte que resgate repetido
Processo menos inventado
Mais forte que adicionar gates, papéis, reuniões ou técnicas obrigatórias
Pistas de linguagem da prova que merecem atenção
Palavras como only, must, always, never, required, responsible, accountable e can podem mudar radicalmente uma resposta. A frequentemente testa limites precisos.
Por exemplo, "O pode cancelar a " é incompleto, mas aponta na direção correta; "Somente o tem autoridade para cancelar a " é a regra precisa de responsabilidade. "A pode incluir demonstração" pode ser verdadeiro; "A é uma demo" distorce o propósito do evento.
Palavra/expressão
Gatilho de raciocínio
must / required
Verifique se o elemento é realmente obrigatório no Scrum Guide
only
Procure responsabilidade ou autoridade exclusiva
always / never
Desconfie, a menos que o Scrum Guide seja explícito
may / can
Frequentemente indica técnica opcional ou comportamento dependente do contexto
accountable
É diferente de executar pessoalmente toda a atividade
Done
Teste imediatamente contra a
Teste imediatamente contra o
Sinais de alerta em alternativas erradas
O atribui, aprova, aceita, prioriza ou gerencia .
O dita a implementação técnica ou a alocação de tarefas dos .
Stakeholders alteram diretamente o trabalho da dos sem colaboração com o .
O é descrito como relatório de status ao ou gerente.
A é descrita como gate de release, aceitação ou aprovação.
Trabalho incompleto é tratado como porque pode ser demonstrado.
O é tratado como completamente fixo, ignorando adaptação baseada no .
Uma prática popular - ,, User Stories, , Burndown - é descrita como obrigatório.
Um elemento específico de é inserido em uma questão que descreve apenas .
Uma resposta adiciona novo papel, comitê, camada de aprovação ou cerimônia quando o Scrum Guide já define a responsabilidade.
Mini conjunto de prática - resolva antes de ler a resposta
Pergunta
Resposta + raciocínio
Um stakeholder não gosta de uma funcionalidade Done na Review. Ele pode rejeitar seu status de Done?
Não. A determina o status do ; o feedback pode alterar decisões futuras do .
descobrem uma forma mais simples de alcançar o que remove dois PBIs selecionados. O pode mudar?
Sim. Os adaptam o plano; o escopo pode ser renegociado enquanto o permanece protegido.
O está ausente. O deve ser cancelado?
Não. Ele é dos ; o não precisa participar, salvo se também estiver atuando como Developer.
O quer em todos os PBIs. Isso é requisito do ?
Não. são responsáveis pelo ; a unidade/técnica não é prescrita.
Um Done está pronto no Dia 6. O time deve esperar a Review no Dia 10?
Não. Um Done pode ser entregue antes de a terminar.
Um gerente quer que o escolha quem trabalhará em um PBI urgente.
Autoridade errada. Os autogerenciam o plano da .
O se torna irrelevante após uma mudança regulatória. Quem pode cancelar?
Somente o .
Dois Teams compartilham um produto. Eles devem criar um ?
Não, a menos que estejam usando . O básico não define .
Um fluxo prático para a prova
Use o método de forma diferente conforme a dificuldade da questão.
Para uma questão factual direta, responda de memória e siga em frente. Para uma questão situacional com uma violação óbvia do framework, elimine-a rapidamente. Para um cenário difícil com duas alternativas plausíveis, desacelere e execute explicitamente o filtro de dez perguntas.
Não projete em excesso o seu ambiente de trabalho sobre a prova. A testa conforme definido, e não a forma como sua empresa modifica . Se sua organização usa gerentes de projeto, aprovações obrigatórias, reunião fixa de refinement, , ou uma política especial de estimativas, mantenha essas práticas locais separadas do Scrum Guide.
Identifique uma violação de responsabilidade/evento/compromisso
Duas respostas plausíveis
45-90 s
Execute o filtro de 10 perguntas + critérios de desempate
Prática de nicho mencionada
20-45 s
Verifique o limite entre básico e prática opcional/complementar
Conclusão: domínio situacional vem de princípios estáveis, não de mais regras
Questões situacionais se tornam administráveis quando você para de tratar cada cenário como único. A maioria é apenas uma variação de um pequeno conjunto de limites do .
Comece pelas responsabilidades. O maximiza valor e gerencia o . O estabelece e melhora a eficácia. Os criam o e são donos do plano da . Isso resolve imediatamente muitas questões de autoridade.
Depois, identifique o propósito do evento, o artefato e o compromisso. O trata do progresso em direção ao . A Review trata de inspeção do produto e adaptação. A Retrospective trata de qualidade e eficácia. O orienta decisões do ; o protege a coerência da ; a protege a qualidade transparente.
Em seguida, aplique o . Respostas fortes tornam a realidade mais transparente, criam inspeção significativa e permitem adaptação baseada em evidências. Elas não protegem um plano contra o aprendizado apenas porque o plano existia primeiro.
O autogerenciamento é o próximo filtro. não precisa de um gerente escondido dentro da responsabilidade do . devem manter sua autoridade legítima de decisão, e o deve ajudar a capacidade do time a crescer, em vez de criar dependência.
Por fim, proteja o limite do framework. é propositalmente incompleto. User Stories, ,,, Burndown Charts, , / e podem ser úteis. A utilidade deles não os transforma em requisitos do básico.
ilustra esse limite perfeitamente. Ele é mantido pela .org e se apoia em para dar suporte a vários times trabalhando em um produto. Ele não é ativado automaticamente pela existência de vários Teams, e elementos específicos do só devem aparecer quando estiver explicitamente no contexto.
Na minha visão, o hábito de raciocínio mais forte para a é fazer uma última pergunta antes de selecionar uma alternativa: "Se esta opção se tornasse a forma normal de trabalho do time, ela fortaleceria responsabilidade, , autogerenciamento, qualidade e valor - ou substituiria silenciosamente por e processo adicional?" Essa pergunta frequentemente revela a resposta que a prova procura.
Principais aprendizados
Use um filtro de dez perguntas: responsabilidade, evento, artefato, compromisso, transparência, inspeção, adaptação, autogerenciamento, autoridade do e limite do Scrum Guide.
Comece pelas responsabilidades porque muitas questões situacionais são questões de autoridade disfarçadas.
Use o propósito do evento para rejeitar reuniões de status, gates de aprovação e cerimônias genéricas.
Associe a , a e a .
Use transparência, inspeção e adaptação como teste de qualidade da resposta.
Prefira opções que preservem o espaço legítimo de decisão de um .
Trate como suspeitas respostas que transformem o em chefe, atribuidor de tarefas, aprovador ou proxy do .
Não promova User Stories, ,,, Burndown ou outras práticas complementares a obrigatório.
O pode se adaptar; o é o limite de compromisso.
Um Done pode ser entregue antes da ; a Review não é um gate de release.
Somente o pode cancelar uma , e o cancelamento está ligado ao tornar-se obsoleto.
Trabalho incompleto não é , independentemente de quão impressionante seja a demonstração.
Quando duas respostas forem plausíveis, prefira explícito, responsabilidade preservada, , crescimento da capacidade e o processo menos inventado.
Não responda questões de básico a partir das modificações de processo da sua empresa.
se apoia em e o estende minimamente; é complementar e não faz parte do básico definido pelo Scrum Guide.
