Sprints, aqui está o problema: muitas equipes planejam suas sprints completamente de trás pra frente. Isso não é totalmente inesperado.

O Guia do Scrum é bastante escasso quando se trata do tópico de criar a meta para as sprints, basicamente afirmando que o objetivo da sprint é a meta do sprint, e serve para informar, inspirar e orientar a equipe com relação ao que mesmo explicando por que a equipe está trabalhando no produto.

No entanto, tudo isso parece um pouco autorreferencial – a meta é o que eles estão trabalhando e o que a equipe está trabalhando os traz para o objetivo? – Isso não parece fornecer muita orientação para a equipe.

Não é de surpreender que muitas equipes consigam atingir seus objetivos de maneira ascendente. A equipe examina o que está no topo da lista de pendências, com talvez um pouco de acréscimo do Product Owner e de outras partes interessadas, e estabelece o objetivo ao compilar as histórias e tarefas adicionadas ao sprint.

Para um exemplo simples, imagine que eu quero estar preparado para uma festa que estou organizando hoje à noite. Meu backlog pessoal pode conter tarefas como:

1. Pegar gelo;
2. Fazer lanches;
3. Selecionar músicas; e
4. Aspirar o tapete.

Acrescento essas quatro tarefas à minha lista diária e decido que meu objetivo é pegar gelo e comida, limpar a casa e escolher algumas músicas.

Fácil de entender e parece muito com uma lista de tarefas simples. E, no entanto, eu posso fazer todas essas coisas e ainda não estar pronto para a festa.

É assim que parece um objetivo de baixo para cima – uma lista de tarefas que, se concluídas, significa que podemos verificar tudo e encerrar o dia – Isso é inútil quando se trata de saber se você está fazendo as coisas corretas; não é uma maneira eficaz de inspirar uma equipe; e não oferece muita flexibilidade caso a situação mude ou novas informações sejam descobertas.

Essas são as razões pelas quais a missão para os sprints devem ser criada de cima para baixo – determinando como seria uma iteração bem-sucedida (“Estou preparado para a festa”), e não como a agregação das tarefas envolvidas.

Deve incluir todos os itens que já são conhecidos e vários que não são. Vejamos como uma equipe pode fazer um melhor objetivo de sprint.

Primeiro, ignore a lista de pendências

Quando a equipe inicia a sessão de planejamento, é tentador simplesmente abrir a lista de pendências, ver quais histórias estão no topo e perguntar ao proprietário do produto se essas histórias ainda são importantes.

Se o Product Owner e o Scrum Master tiverem realizado seu trabalho corretamente, um backlog bem preparado terá os itens mais críticos no topo e estarão prontos para desenvolvimento com requisitos e definições  de pronto claramente definidos.

Pegando as principais tarefas

Em seguida, é um exercício simples arrastar as principais histórias para o sprint, até que a capacidade seja esgotada e concluir o planejamento.

De fato, dada uma ferramenta sólida o suficiente e com uma lista de pendências mantida em boa forma, esse método de planejamento pode ser feito sem uma reunião ou mesmo sem a interação humana. O que também seria completamente errado.

É assim que o planejamento de baixo para cima opera; a equipe “descobre” a meta observando as tarefas que estão prestes a serem concluídas.

Embora isso atenda a todos os critérios de planejamento e, de fato, crie um sprint devidamente formado e cheio de trabalho, não criará um objetivo ou direção para a equipe.

Para usar outro exemplo simples, uma decisão que a maioria das pessoas toma diariamente é decidir o que elas querem comer no jantar.

Às vezes, o método para fazer essa determinação envolve abrir os armários, ver o que está armazenado lá e decidir o que eles querem é uma tigela de sopa, ou as sobras da noite passada.

Certamente, isso servirá ao propósito de deixar a pessoa com menos fome, e pode até ser satisfatória o suficiente, estará longe do que eles “queriam” para o jantar.

Da mesma forma, o objetivo dos sprints devem ser algo que motive a equipe, dê um objetivo à equipe e ajude com as milhares de micro decisões que precisam ser tomadas ao longo do sprint.

Foco nos resultados

Em vez de prestar atenção no que itens individuais precisam ser feitos, a equipe deve se concentrar no resultado que espera obter do sprint.

Essa seria a abordagem de cima para baixo para criar uma meta, prestando atenção ao que a equipe está tentando realizar.

Em nosso exemplo, isso seria garantir que eles estejam preparados para a festa ou que tenham uma refeição satisfatória; em um exemplo real, serão coisas como garantir que um cliente possa entrar em um site, fazer um pedido ou entrar em contato com o atendimento ao cliente para obter suporte.

Com esse objetivo em mente, a equipe pode decidir quais histórias e tarefas serão necessárias para alcançar esse resultado e adicioná-las aos sprints.

A importância das histórias e o que adiar nas sprints

Histórias importantes, mas que não ajudam a atingir o objetivo do sprint atual, podem ser adiadas por enquanto.

À medida que o sprint progride, novas tarefas, cenários e até obstáculos surgirão e precisarão ser trabalhados.

Isso não é incomum; a adição de tarefas (embora geralmente não sejam histórias) ao sprint atual acontece com frequência e pode até ser representada em um gráfico de detalhamento padrão.

Com a compreensão de qual é o objetivo do sprint, adicionar coisas que ajudem a alcançar os critérios de saída pode ser comunicado de uma maneira que faça sentido para todos.

Também ajuda a agir como uma barreira para adicionar coisas que não parecem relevantes ou urgentes.

Certamente, itens de missão crítica e coisas necessárias para manter as luzes acesas entrarão na fila, mas isso ajuda a definir um nível alto para o quão difícil deve ser a inserção de novos trabalhos nos sprints depois de ter sido concluído e planejado considerando o objetivo principal do sprint,

Prever como atingir a meta das Sprints

Depois que o objetivo do sprint é determinado, a próxima tarefa é descobrir como alcançá-lo. Um mecanismo para fazer isso é pensar no que a equipe gostaria de apresentar no final das sprints em uma demonstração.

Ao determinar o que deve estar funcionando, o que deve estar visível e como isso será mostrado, pode ajudar a esclarecer quais tarefas precisam ser trabalhadas.

A equipe pode trabalhar de trás para frente a partir dessa descrição para ajudar a identificar o que não precisa ser desenvolvido imediatamente, especialmente se puder ser mostrado de uma maneira alternativa.

Vi demonstrações em que, depois de inserir alguns dados em um formulário da web, a próxima parte da apresentação foi a saída de uma consulta SQL escrita em um editor de banco de dados.

Não é bonito, mas prova suficiente de que a capacidade estava funcionando.

Parte disso envolve uma boa fatia vertical, mas o objetivo real é fornecer uma visão do que a equipe precisa fazer. A lista de trabalhos que precisam ser concluídos – como feito, feito, feito – deve ficar claro na mente de todos.

Separando o joio do trigo

Desde o final da reunião de planejamento até a extensão completa do sprint, a equipe deve ter uma imagem mental de exibição de seu trabalho e saber como o que eles estão trabalhando ajudará a alcançar esse objetivo.

Se um desenvolvedor se encontrar trabalhando em algo que não considera que impeça a apresentação do recurso, esse trabalho deverá ser deixado de lado para se concentrar ainda mais nos principais componentes do recurso.

Afinal, um bom objetivo do sprint ajuda a inspirar a equipe, dando-lhes algo para visualizar, além de conectar o trabalho que está sendo concluído ao resultado desejado.

Ele deve ser usado tanto taticamente, na determinação da lista de histórias que a integram quanto na estratégia, motivando a equipe para a conclusão.

Decida como medir suas Sprints

Uma vez que a última parte a descobrir é como a meta será avaliada e, em particular, o que a equipe deve acompanhar para determinar o sucesso.

Entretanto, o resultado de um sprint é redigido no tempo futuro, como em que funcionalidade estará disponível no final.

Pode ser que um cliente possa efetuar login ou fazer um pedido, mas o termo operacional é que ele é capaz de fazê-lo, e não o que realmente faz.

Em geral, a equipe de desenvolvimento não é responsável por gerar interesse ou demanda por um recurso ou produto; é mais seu objetivo disponibilizar recursos e produtos.

No entanto, isso não impede a equipe de desenvolvimento de apresentar métricas de sucesso para o que está construindo.

Deixe a equipe decidir

Dependendo do recurso, a equipe pode decidir que, dentro de uma semana após o lançamento, pelo menos uma pessoa utilizará a função em um ambiente de produção.

Contanto que o próprio Product Owner o faça, isso será fácil de conseguir.

Se houver uma melhoria em algo existente, a equipe poderá observar taxas de sucesso, desempenho ou alguma medida existente, e dizer que dentro de um certo período de tempo, isso mudará para melhor.

O que fazer com sprints de trás para frente

Também é útil fazer as duas coisas:

1. Dizer que dentro de uma semana, um certo número de pessoas usará um recurso com sucesso e,
2. Dentro de um mês, um número ainda maior o usará.

Pode ser uma combinação de tipos diferentes, medindo o uso e o desempenho, de modo que um número de clientes use o recurso e ele tenha características de desempenho.

Qualquer que seja o pensamento por trás da métrica, o objetivo principal é pensar em primeiro lugar.

Concluindo

Em suma, definir uma meta ajuda a criar uma visão sobre o que a equipe está trabalhando, definindo a métrica ainda mais na mente da equipe de desenvolvimento.

Ambos são extremamente importantes.

Então para criar uma meta de sprint de cima para baixo não é apenas uma parte necessária do processo, pode ser a parte mais importante.

Em conformidade a essa criação que ajuda a orientar tudo, desde a decisão do que fazer nos sprints, até o que precisa ser adicionado e o que não é necessário, e permite que as pessoas se concentrem no que será demonstrado quando tudo terminar.

Em suma, ao iniciar uma sessão de planejamento, decidindo o que você está tentando realizar, levará a um resultado melhor para todos.