Criando boas metas de Sprint
Se temos um Sprint Backlog, essencialmente o plano para o Sprint, por que precisamos de uma meta da Sprint?
Essa é a pergunta que recebo várias e várias vezes em treinamentos e no trabalho. Lembre-se de que o desenvolvimento de software é complexo e não podemos planejar perfeitamente o desconhecido. Quando criamos o Sprint Backlog, existe a expectativa de que mais trabalho surja durante a Sprint. O escopo pode precisar ser renegociado. A Meta Sprint ajuda a focar em um objetivo que queremos alcançar e permite a flexibilidade para negociar o trabalho para atingir esse objetivo.
Criar um objetivo claro da Sprint pode ser um desafio para os times Scrum. Aqui estão quatro problemas comuns com as metas da Sprint e algumas dicas para melhorá-las.
1 – A Meta da Sprint é muito grande.
Quando temos metas de Sprint compostas (por exemplo, atingir X e Y e Z), estamos- dividindo o foco e não permitindo muita flexibilidade.- – Aqui estão algumas razões pelas quais acabamos nessa situação e sugestões de como pensar de maneira diferente.
- Estamos trabalhando em vários projetos ou iniciativas não relacionadas. – Quando estamos ordenando o Product Backlog e fazendo o Sprint Planning, considere tanto a coesão do trabalho quanto a iniciativa de prioridade máxima (singular).- Quando colocamos muito em uma Sprint, estamos nos preparando para o fracasso. Acabamos com o desperdício devido í mudança de contexto e pouco espaço para o trabalho emergir í medida que aprendemos.- Se parecer impossível escolher um, talvez nossas Sprints sejam muito longas e não ofereçam ao negí³cio a oportunidade de mudar o foco e a direção com a frequência suficiente.
- Tentamos abranger todos os itens do Product Backlog (PBI).- Quando dou cursos de Scrum, muitas vezes ouço que as equipes consideram sua Meta da Sprint como “completar todos os PBIs”. Isso é o equivalente a não ter uma meta da sprint. Isso parece um pouco preguiçoso.- Sim, chegar a bons objetivos de sprint é difícil.- Aproveite o tempo para fazê-lo.
- Achamos que a equipe pode não trabalhar tanto se o desafio não for grande o suficiente.- Esse sentimento me lembra um pouco de comando e controle.- Para que equipes auto organizadas- e capacitadas sejam eficazes, devemos acreditar que as pessoas estão comprometidas em fazer o melhor.- Se a meta da Sprint for atingida antes do final da Sprint, os profissionais descobrirão o que mais podem fazer para contribuir de maneira significativa. Isso pode significar entregar mais funcionalidade.- Isso pode significar trabalhar em itens de melhoria contínua.- Confie neles para descobrir.
2 – O objetivo da Sprint é vago.
Quando chegamos ao final de um Sprint, toda a equipe está de acordo se o objetivo da Sprint foi ou não alcançado? Caso contrário, o objetivo da Sprint pode ser muito vago. Aqui estão algumas dicas para criar metas de sprint mais claras.
- Durante o planejamento da Sprint, pergunte “como saberemos se alcançamos a meta da Sprint?” – Se tivermos respostas diferentes ou olhares confusos do Product Owner ou de qualquer membro da equipe de desenvolvimento, precisamos de mais discussão e refinamento da Meta da Sprin.
- Torne o Objetivo da Sprint mensurável. – Isso ajuda a reduzir a subjetividade, ou opinião.
- Durante o Planejamento do Sprint, use uma técnica de consenso para- confirmar a compreensão e o comprometimento de todos com o Objetivo da Sprint.- Essa também é uma maneira de ajudar a- incentivar a propriedade da equipe- .
Aqui estío alguns exemplos de objetivos de sprint pouco claros e modificações para torná-los mais claros.
Objetivo de sprint pouco claro | Objetivo de Sprint mais claro |
Melhore a funcionalidade do carrinho de compras. | Simplifique o processo de compra para permitir um aumento nas taxas de conversão. |
Melhorar o desempenho. | Aumente o tempo de carregamento da página em 10%. |
Novo segmento de mercado a bordo. | Permita que um novo segmento de mercado adquira o Serviço Y. |
3 – A equipe não presta atenção ao objetivo do Sprint durante o Sprint.
Lembre-se de que temos que realmente prestar atenção a ele para ajudar a fornecer foco.
- Torne-o visível.
– Escreva a Meta da Sprint no Scrum Board ou prí³ximo dele. Faça-o grande.
– Use uma cor ou borda que se destaque. - Ensine a equipe a- falar sobre o progresso em direção a Meta da Sprint na Reunião Diária.
– Os membros da equipe de desenvolvimento geralmente fornecem atualizações sobre os itens do backlog do produto em que estão trabalhando, e o objetivo do Sprint nunca é discutido.
– Faça parte do Daily Scrum.
– O facilitador pode perguntar í equipe no final da Reunião Diária como eles se sentem sobre a probabilidade de atingir a Meta da Sprint, se são necessários ajustes no plano diário para reorientar ou se o escopo precisa ser negociado.
– Isso pode ajudar a melhorar a colaboração da equipe . - Faça da Meta da Sprint uma medida de equipe e mantenha-a visível no espaço da equipe.
– Semelhante à forma como uma equipe pode rastrear sua velocidade ou cobertura de teste automatizado ao longo do tempo, uma equipe também pode rastrear a conquista da meta do Sprint ao longo do tempo.
– Manter essas informações visíveis ajuda a equipe a pensar sobre elas.
– Dados históricos e tendências podem ser usados para discussão na Sprint Retrospective. - Uma palavra de cautela: atingir uma meta de Sprint é passar/falhar.
– Não existe 85% alcançado.
4 – A Meta da Sprint não parece significativa.
Uma meta de sprint deve fornecer propí³sito.- Isso ajuda a equipe a saber por que eles estão construindo o incremento.- As pessoas querem fazer um trabalho significativo.- As pessoas querem fazer um trabalho que tenha impacto.- Este é um driver para a- motivação intrínseca.- Vamos pensar em maneiras de tornar as metas da Sprint mais significativas para as pessoas que estão construindo o produto.
- Torne-a focada no negí³cio ou no usuário quando possível. – O que um usuário poderá fazer quando implementarmos esse recurso?- O que uma área de negí³cio poderá alcançar quando implementarmos uma melhoria?
- Concentre-se em testar suposições de negí³cios e obter feedback.- Muitas vezes não sabemos o que os usuários realmente precisam ou estão dispostos a fazer (porque nem os usuários sabem).
– Um Product Owner precisa de feedback antecipado para testar suposições sobre valor para os usuários. - Torná-la focada na redução do risco.- Provar uma tecnologia ou design é uma parte importante da redução de riscos.- Se soubermos que uma tecnologia não vai atender í s nossas necessidades de desempenho, segurança ou escalabilidade, podemos mudar de direção.- Quanto mais cedo mudarmos de direção, mais barato será o custo da mudança.