Confuso sobre a modificação do backlog do sprint durante um sprint

Ultimamente, tenho lido muito sobre scrum e descobri o que parece ser uma informação conflitante sobre se é ou não certo alterar o backlog do sprint durante um sprint. O artigo da Wikipedia sobre scrum diz que não está bem, e vários outros artigos dizem isso também. Também meu professor de Desenvolvimento de Software ensinou a mesma coisa durante uma visão geral do scrum.

No entanto, li Scrum e XP nas Trincheiras e isso descreve uma seção para itens não planejados no painel de tarefas. Então, procurei o Guia Scrum e ele diz que durante o sprint "Nenhuma alteração foi feita que afetaria o objetivo do Sprint" e na discussão do objetivo do Sprint "Se o trabalho for diferente do que a equipe de desenvolvimento esperava, eles colaboram com o Dono do produto para negociar o escopo do Backlog da Sprint dentro da Sprint ". Continua dizendo na discussão do Sprint Backlog:

O Sprint Backlog é um plano com detalhes suficientes para que as mudanças em andamento possam ser entendidas no Daily Scrum. A Equipe de Desenvolvimento modifica o Sprint Backlog em todo o Sprint, e o Sprint Backlog surge durante o Sprint. Esse surgimento ocorre quando a equipe de desenvolvimento trabalha com o plano e aprende mais sobre o trabalho necessário para atingir a meta da Sprint.

Conforme novo trabalho é necessário, a Equipe de Desenvolvimento o adiciona ao Backlog da Sprint. À medida que o trabalho é executado ou concluído, o trabalho restante estimado é atualizado. Quando os elementos do plano são considerados desnecessários, eles são removidos. Somente a equipe de desenvolvimento pode alterar seu Sprint Backlog durante um Sprint. O Sprint Backlog é uma imagem altamente visível e em tempo real do trabalho que a Equipe de Desenvolvimento planeja realizar durante o Sprint, e pertence exclusivamente à Equipe de Desenvolvimento.

Então, neste ponto, estou completamente confuso. Pensando nisso, faz mais sentido para mim adotar a segunda abordagem. Os itens individuais e específicos da lista de pendências não me parecem ser a coisa mais importante, mas a meta do sprint; portanto, não faz sentido alterar a meta do sprint, mas ser capaz de alterar o backlog. Por exemplo, se o proprietário do produto e a equipe pensavam que estavam na mesma página sobre uma história, mas, à medida que o sprint avançava, eles descobriram que havia um mal-entendido, parece que faz sentido alterar as tarefas que compõem essa história de acordo. . Ou, se houvesse alguma história ou tarefa esquecida, mas necessária para atingir a meta do sprint, eu acho que seria melhor adicionar a história ou tarefa ao backlog durante o sprint.

No entanto, muitas pessoas parecem bastante inflexíveis quanto a qualquer alteração no backlog do sprint não ser aceitável. Estou entendendo mal essa posição de alguma maneira? Essas pessoas estão definindo o backlog do sprint de alguma forma diferente? Meu entendimento do backlog do sprint é que ele consiste nas histórias e nas tarefas em que estão divididas.

De qualquer forma, eu realmente aprecio informações sobre esta questão. Estou tentando descobrir qual é a abordagem ideal do scrum para alterar o backlog do sprint durante um sprint e se as pessoas que usam o scrum com sucesso para o desenvolvimento permitem alterar o backlog do sprint durante um sprint.

Primeiro, eu não teria regras rígidas sobre isso; o ponto principal do scrum é permitir que você se adapte à situação. Portanto, você poderá modificar o backlog do sprint durante o sprint, se absolutamente necessário (como se esqueceu de algo crítico).

Mas dizer que essa modificação no backlog do sprint durante o sprint deve ser resistida. O ponto principal do sprint ser curto é que o novo trabalho possa ser adicionado ao próximo sprint (depois de ter sido corretamente priorizado) sem afetar o cronograma geral do projeto (vários sprints).

Mas se o trabalho for crítico para uma das tarefas deste sprint, você terá duas opções.

1. Adicione novo item ao sprint.
   MAS remova um item de tamanho equivalente do sprint.
2. Solte o item mal planejado neste sprint (para que você possa planejá-lo adequadamente no próximo sprint).
   • Adicionar uma alternativa (de tamanho apropriado) à parte superior da lista de pendências do produto (que deve estar em ordem de prioridade na reunião de planejamento do sprint).
   • Ou quando todos os itens do sprint terminarem, permita que os desenvolvedores recuperem a folga do backlog do produto.

Portanto, estou no campo que você provavelmente não deve modificar o backlog do sprint. Mas você deve levar em consideração a situação, pode haver circunstâncias excepcionais. Na maioria dos casos, eu iria com as opções 2 e deixaria que os desenvolvedores pegassem a folga com as tarefas do backlog.

Em seguida, na próxima reunião de planejamento, a nova tarefa será analisada adequadamente e adicionada ao sprint (conforme apropriado).

Lembre-se de que o sprint é curto e apenas a marca da próxima gota não é o fim do ciclo de desenvolvimento. O proprietário do produto teria que estar muito desesperado por um recurso que não podia esperar pelo final do próximo sprint.

A confusão se deve a linguagem ambígua.

O Backlog da Sprint possui dois níveis de detalhe. Primeiro, é uma lista de itens (histórias de usuário) que a equipe se comprometeu a entregar. Segundo, são todas as TAREFAS que a equipe pretende fazer para entregar cada uma dessas histórias.

Portanto, quando as pessoas falam sobre o Sprint Backlog, devem realmente ter clareza sobre o que querem dizer. Ao ler o Guia do Scrum, você verá o seguinte: O Sprint Backlog é o conjunto de itens do Backlog do produto selecionados para o Sprint, além de um plano para fornecer o incremento do produto e atingir a meta do Sprint.

Portanto, é a lista de itens do backlog do produto E o plano (tarefas) para entregá-los.

Agora, muitas equipes gostam de adicionar todas as tarefas propostas (plano) no início do Sprint, para que possam rastrear um gráfico de burndown com base nas horas restantes. Outras equipes permitem que as tarefas surjam conforme necessário. É nesse momento que não há problema em adicionar ao 'Sprint Backlog', já que a equipe precisa fazer isso para inspecionar e adaptar para entregar os Itens e cumprir a meta da Sprint.

Sob certas circunstâncias, uma equipe pode estar bem adiantada no cronograma e (tendo eliminado todas as outras tarefas úteis que poderiam melhorar os recursos da equipe) pode decidir trabalhar com o Dono do produto para selecionar outra história (já deveria ter sido priorizada e dimensionada). o Backlog do produto ... mas apenas se eles tiverem a confiança de que será concluído dentro desse Sprint e que está alinhado com a meta do Sprint.

Então só temos isso; SIM ... as equipes adicionam tarefas ao plano de backlog da Sprint, conforme necessário. NÃO, eles geralmente não são adicionados à lista de itens da lista de pendências que definem o escopo da sprint.

Espero que isso esclareça a situação.

Depende das suas situações. Se algumas informações são perdidas durante o planejamento e, posteriormente, você descobre que precisa modificar ou adicionar alguns pontos a algumas histórias, acho que está tudo bem. Mas, sim, se o escopo de um recurso mudar completamente, será uma situação extrema e precisará ser tratada de maneira diferente.

Mas é claro, durante o planejamento, presume-se, que todos saibam e discutam claramente sobre cada um dos recursos em que estariam trabalhando. Se as discussões e o planejamento forem bons, em quase todos os casos você realmente não precisará de modificações.

Concordo com as respostas, gostaria de salientar que, se a história começou a se desenvolver, ela não pode ser interrompida até terminar.

Cavar seus calcanhares no início. Aqueles que pedem a mudança terão que aprender da maneira mais difícil; caso contrário, o planejamento acabará sendo inútil se as pessoas aprenderem que você pode fazer o que quiser de qualquer maneira.

Cite que a qualidade vem do foco e os erros vêm da queda de uma linha de pensamento. Cite o custo da alternância de contexto. O acompanhamento da dívida e o gerenciamento da redação, discussão e reprodução de uma história para abordar o trabalho incompleto são caros. Só não comece por esse caminho.

Idéia: conceda à gerência 3 créditos de switch para gastar a cada trimestre como um compromisso.