Planejamento de Sprints de trás para a frente?

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 auto-referencial – 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.

Como fundador da Projetos e TI, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar. Caso queira saber mais entre em contato comigo, ou me convide para uma palestra. PMP, SMC, SAMC, SPOC, SCT, PTMC, PTME, OKR, SDC, SSYB, SAP, CYNEFIN, M3.0, ACM, CPM-E, CKMS, CCNS, CDTS

1 Comment

Leave a comment

Your email address will not be published.