O que são considerados as em uma reunião de planejamento de Sprint?

Para chegar no Sprint Backlog uma sprint começa com uma reunião de planejamento do sprint, na qual a equipe de desenvolvimento multifuncional, que possui todas as habilidades necessárias para que os itens sejam “feitos”, prevê o trabalho que planeja fazer para o próximo sprint.

Com base na quantidade estimada de trabalho para cada item do backlog do produto, na capacidade projetada da equipe durante o sprint e no desempenho anterior da equipe durante os sprints anteriores (velocidade média da equipe), eles selecionam itens específicos do topo do backlog do produto.

Normalmente, a equipe escolhe itens considerados “prontos” para seleção a fim de trazer os itens do sprint backlog que vão trabalhar durante a sprint. Os itens selecionados no sprint backlog estão na mesma ordem em que estão no product backlog, com os itens de maior prioridade e mais refinados aparecendo primeiro, para que sejam trabalhados primeiro.

Um sprint backlog é o conjunto de itens que uma equipe multifuncional de produto seleciona de seu product backlog para trabalhar durante o próximo sprint.

Normalmente, a equipe concorda com esses itens durante a sessão de planejamento do sprint. Na verdade, o sprint backlog representa a saída primária do planejamento do sprint.

O backlog do produto é a lista abrangente de tarefas relacionadas ao produto que, a qualquer momento, devem abranger todas as coisas em que a equipe multifuncional concordou em trabalhar eventualmente, seja para trazer o produto ao mercado ou para melhorá-lo.

Quando esses itens são mantidos em ordem de prioridade, um backlog do produto deve comunicar quais histórias de usuários, recursos, correções de bugs e outros itens pendentes que a equipe de desenvolvimento deve trabalhar em seguida.

Você também pode pensar no backlog do produto como um detalhamento tático em nível de tarefa do plano estratégico descrito em seu roteiro de produto.

Com isso em mente, um sprint backlog é uma lista muito mais curta extraída dos itens do product backlog – especificamente, aqueles itens que a equipe identifica durante uma reunião de planejamento do sprint como as tarefas mais importantes a serem concluídas em seguida.

Aqui estão algumas dicas importantes sobre a distinção entre sprint backlogs e product backlogs, e como os dois funcionam juntos:

O Sprint Planning toma a forma de uma reunião envolvendo o Product Owner, o Time Scrum e o Scrum Master. O Product Owner discute o Product Backlog atual, com foco nas User Stories de alta prioridade.

A conversa envolve a explicação do Product Owner sobre as Histórias, incluindo os Critérios de Aceitação e o Time Scrum buscando esclarecimentos para que eles possam fazer escolhas informadas com relação à estimativa e o que eles irão comprometer para o Sprint.

O Time Scrum então fornece estimativas para as Histórias, geralmente em termos de Pontos de História usando o Planning Poker, e então se compromete com o que eles acreditam estar dentro de sua capacidade para o Sprint.

O produto desta reunião é um Sprint Backlog comprometido, que representa as Estórias de Usuário nas quais o Time Scrum trabalhará para o Sprint.

O Time Scrum também usa esta oportunidade para criar Tarefas para as Estórias de Usuário. Esta atividade ocorre durante a segunda metade da reunião de Planejamento da Sprint e pode ou não envolver o Product Owner.

À medida que o Sprint progride e as histórias de usuário são concluídas, elas serão demonstradas ao Product Owner, que confirmará que cada história de usuário está “concluída”.

Pode parecer supérfluo ter uma discussão sobre “pronto” ao lidar com Sprints, que são definidas como iterações de time-boxed. Alguém pode perguntar: “Um Sprint não está ‘feita’ quando as duas semanas (ou qualquer duração) terminarem?” A resposta curta é “Sim, um Sprint está ‘concluído’ quando executou sua duração originalmente programada”.

A parte chata entra em ação quando o Sprint termina, mas há histórias de usuário que não foram concluídas.

• O Time Scrum recebe crédito por Story Points parciais concluídos?
• A quantidade total de pontos é transferida com a história do usuário para a próxima Sprint (ou qualquer Sprint para a qual a história do usuário é movida)?
• O Sprint pode ser estendido se o Time Scrum estiver “próximo”?

Antes de respondermos a essas perguntas, vejamos o compromisso inicial da equipe, pois isso afetará o que é concluído na Sprint.

Mudanças no Sprint Backlog durante o Sprint

Depois que o planejamento do sprint estiver concluído, nenhum novo item poderá ser adicionado ou removido do sprint backlog durante o sprint. A única exceção ocorre se, durante um sprint – que é fixa em duração – todos os itens estiverem completos antes que o sprint termine e a equipe tenha tempo e capacidade para trabalhar em itens adicionais.

Nesse caso, a equipe de desenvolvimento colabora com o proprietário do produto e seleciona o(s) item(ns) do topo do backlog do produto – normalmente, o(s) próximo(s) item(ns) do backlog – para trazer para o sprint backlog para trabalhar durante o tempo restante na sprint.

Se essa exceção não for o caso, mas um stakeholder quiser adicionar um item durante um sprint, ele é encaminhado ao dono do produto para que em conjunto possa definir o item, a fim de adicioná-lo ao backlog do produto a ser priorizado e aprovado para uma sprint subsequente.

O backlog do sprint surge em termos de trabalho/tarefas à medida que se aprende mais sobre os itens. Cada item é dividido em tarefas durante o sprint, mas itens adicionais não podem ser adicionados ao backlog do sprint.

Somente a equipe de desenvolvimento pode adicionar ou atualizar tarefas no backlog do sprint. Durante o sprint, nenhuma alteração é feita para colocar em risco o objetivo do sprint, incluindo alterações na composição da equipe de desenvolvimento.

As metas de qualidade também não diminuem. Bloquear o escopo de cada sprint permite um ambiente estável para que a equipe de desenvolvimento possa se concentrar em “fazer o trabalho”, podendo otimizar e gerenciar com eficiência seus esforços de trabalho.

Isso é diferente do gerenciamento de projetos tradicional que usa uma abordagem em cascata, onde os desafios geralmente surgem em algumas organizações, quando as mudanças podem ser solicitadas, aprovadas, e normalmente ocorrem a qualquer momento durante o ciclo de vida do projeto.

Com base na minha experiência, esses desafios incluem problemas de alocação de recursos, um aumento na multitarefa causando alternância de contexto entre várias tarefas e falta de foco da equipe. Tudo isso afeta a qualidade e a capacidade da equipe de concluir os itens de prioridade mais alta primeiro.

Existem outras situações que podem ocorrer que podem impactar o sprint com relação a mudanças ou entrega de escopo. Uma situação é se uma mudança for considerada significativa o suficiente para um sprint em andamento, tornando o objetivo do sprint obsoleto.

Nessa situação, o dono do produto pode cancelar o sprint com base no feedback das principais partes interessadas e da equipe Scrum, e uma nova reunião de planejamento da sprint ocorrerá.

Cancelamentos de sprints são raros e muitas vezes podem não fazer sentido devido à curta duração dos sprints.

Em outro cenário, se a equipe de desenvolvimento perceber que não pode concluir todos os itens do sprint backlog durante o sprint, eles notificam o proprietário do produto para que possa ajustar a prioridade dos itens, se necessário, pois a equipe de desenvolvimento não poderá entregar os itens no prazo.

Além disso, quando essa situação ocorre, a equipe de desenvolvimento e o proprietário do produto analisam diferentes abordagens para entregar cada item impactado, que é dividido em tarefas, e refinam e ajustam as tarefas associadas de acordo, para que funcionalidades ou recursos parciais possam ser entregues.

Isso também pode envolver a modificação dos critérios de aceitação, se possível, ou a divisão de histórias de usuários para reduzir o escopo, de modo que uma parte da história possa ser concluída no sprint e o restante em uma iteração posterior.

O que vimos acima descreve como as mudanças de escopo são tratadas no Scrum, seguindo as regras vinculadas ao framework Scrum, com o mínimo de adaptação.

No entanto, com base nas lições aprendidas com os desafios encontrados em vários projetos, pode haver a necessidade de exceções à maneira acima de lidar com mudanças de escopo para mudanças urgentes que são absolutamente necessárias, de natureza menor e alinhadas ao objetivo do sprint.

Essas mudanças devem ser tratadas separadamente dos sprints e envolvem apenas uma pequena capacidade máxima definida da equipe, talvez 5%. Além disso, uma abordagem contínua, como o uso de um sistema Kanban, deve ser considerada para o gerenciamento dessas mudanças.

O uso de um sistema Kanban e a capacidade máxima definida são opções viáveis ​​para lidar com esses tipos de mudanças porque isolam e limitam a quantidade de trabalho em andamento associado a elas.

É importante manter essas mudanças separadas para que a qualidade não seja impactada, e os benefícios completos do Scrum (ou seja, minimizar riscos, controlar custos e otimizar valor) ainda sejam alcançados ao longo das iterações de time-box da sprint.

Mais de 5 por cento da capacidade da equipe para essas mudanças afetaria o foco e a capacidade da equipe de realizar o trabalho que tem o maior valor comercial para as partes interessadas.

Se a equipe não puder manter esses tipos de mudanças no mínimo, pode ser uma indicação de que eles podem não estar usando o Scrum corretamente ou que o Scrum não é uma boa opção para eles.

Também pode indicar que a duração do sprint pode precisar ser encurtada, se for muito longa. De qualquer forma, essa questão deve ser um tópico chave para discussão nas reuniões de retrospectiva do sprint, onde a equipe discute formas de melhorar seus processos.

De acordo com a estrutura do scrum, toda a equipe ágil – scrum master, product owner e membros da equipe de desenvolvimento – vão compartilhar a propriedade do sprint backlog.

O proprietário do produto pode estar ciente das novas realidades do mercado ou mudanças nas prioridades organizacionais que exigirão a priorização de histórias de usuários ou correções específicas.

Os desenvolvedores podem ter aprendido em sprints recentes que certos trabalhos de desenvolvimento estão demorando mais do que a equipe havia previsto inicialmente. Todos esses insights ajudarão a equipe a chegar a um backlog de sprint mais viável e estrategicamente sólido.

Embora escolher as tarefas para um sprint backlog seja um esforço de equipe, é importante observar que a equipe geralmente escolhe itens com base em quão bem eles se alinham com a meta do sprint , que o proprietário do produto define.

Nesse sentido, o Product Owner orientará as decisões do sprint backlog estabelecendo primeiro o objetivo geral para o sprint.

Como Mike Cohn, da Mountain Goat Software, explica, as pendências de sprint geralmente são planilhas embutidas, mas também podem ser desenvolvidas e mantidas em ferramentas de software projetadas para gerenciamento ágil de projetos ou até mesmo no aplicativo de rastreamento de bugs da sua organização.

Como essas listas incluem apenas o trabalho que pode ser concluído em um curto período de tempo (normalmente, duas ou quatro semanas), as pendências do sprint geralmente são muito simples.

Desenvolver um sprint backlog para iniciar cada sprint é um valioso ritual de equipe de produto por vários motivos. Isso dá à equipe uma chance no início de cada novo sprint para discutir o que é mais estrategicamente importante (e viável) para trabalhar em seguida.

Ele fornece aos desenvolvedores um conjunto fixo de tarefas e itens pendentes nos quais eles se concentram para o próximo sprint sem se preocupar que sua carga de trabalho possa ser completamente alterada a qualquer momento.

E dá à equipe ágil uma oportunidade contínua de aplicar novos aprendizados sobre quais tipos de histórias, correções e outros trabalhos de desenvolvimento podem ser concluídos dentro de um prazo típico de sprint, para que possam estimar melhor os prazos e os níveis de recursos – e trazer o trabalho em Tempo.

O que é feito durante a reunião de Planejamento da sprint?

Quais são os dois principais tópicos que a reunião de planejamento da sprint cobre?

Qual das seguintes reuniões faz parte de uma reunião de planejamento da sprint?

Quais são os principais tópicos de uma sprint planning?