Planejamento de sprint

Artigo
06/10/2015

Por Mitch Lacey. Proprietário da Mitch Lacey & Associates, Inc, uma empresa de consultoria especializada em adoções e melhorias baseadas em Agile e Scrum.

Janeiro de 2012.

Aplica-se a

Gerenciamento do Ciclo de Vida de Aplicativos; Team Foundation Server

Neste artigo:

Introdução
Previsão versus compromisso
O que é planejamento de sprint?
Como ser bem-sucedido?
Problemas comuns
- Cenário: A equipe não pode se comprometer com todas as histórias que o proprietário do produto solicita.
- Cenário: O proprietário do produto não vem preparado.
- Cenário: O tempo para a Parte 1 é excedido.
- Cenário: O tempo para a Parte 2 é excedido.
- Cenário: O proprietário do produto não está disponível.
- Cenário: A equipe não tem os critérios de aceitação necessários.
- Cenário: O proprietário do produto não sabe o que significa concluído.
- Cenário: O ScrumMaster ou o proprietário do produto está calculando/influenciando as estimativas ou o trabalho da equipe.

Não planejamos. Usamos o Scrum, ou seja, apenas executamos.

Ouço isso o tempo todo. As pessoas pensam que no Scrum e no Agile não existe planejamento, estimativa, reuniões, ou seja, não existe nada! Isso está longe de ser verdade. Em um projeto Agile, realizamos planejamentos em diversos níveis: plano diário ou levantamento diário, planos semanais (sprint ou iteração, lista de pendências), plano de liberação (a lista de pendências do produto) e possivelmente muitos outros.

Vamos nos concentrar no planejamento de um sprint.

Previsão versus compromisso

No verão de 2011, Ken Schwaber e Jeff Sutherland revisaram o seu Guia do Scrum. Com essa revisão, eles removeram um comportamento já bem estabelecido associado ao Scrum, que é o compromisso da equipe em relação ao proprietário do produto e os clientes. O compromisso foi substituído pela previsão. Eles dizem que as equipes podem prever seu trabalho, mas não se comprometer com ele.

Embora compreenda a lógica deles, prefiro ficar com o compromisso pelas seguintes razões:

Comprometer-se com algo coloca a equipe em uma mentalidade diferente de quando algo é previsto. Quando uma equipe faz previsões, está implícito que não cumprir tudo o que foi prometido é um comportamento aceitável. Embora as equipes possam aprender com as previsões, o que, consequentemente, resulta em menos variação nas estimativas, acho que as equipes que fazem previsão demoram mais para reduzir a variação se comparadas às equipes que se comprometem.
A previsão, ou estimativa, é apropriada para a lista de pendências do produto. No entanto, quando as equipes transferem as histórias da lista de pendências do produto para a lista de pendências do sprint e as decompõem, elas adicionam outro nível de granularidade e descobrem pequenos detalhes que lhes permitem pensar “podemos nos comprometer com isso?” Com a previsão, a equipe corre o risco de entrar em um estado de morosidade que leva seus membros a pensar: "Como precisamos apenas fazer a previsão, tudo bem se alguma coisa ficar para trás, uma vez que podemos tentar solucionar depois".

Em uma situação mais ilustrativa, imagine se você dissesse para a sua esposa, marido, parceiro ou parceira: "Prevejo que estaremos juntos por dez anos" em comparação com "Estou comprometido com você". Acho que assim dá pra perceber melhor.

No final das contas, o Scrum está relacionado a ter bom senso. Sugiro experimentar tanto a abordagem de compromisso quanto a de previsão. Tudo está relacionado à aprendizagem, e não às palavras que você usa, portanto, seja inteligente, experimente ambas as abordagens e use a que for melhor para você, sua equipe e sua empresa.

O que é planejamento de sprint?

Realizamos uma reunião de planejamento de sprint para planejar o que a equipe vai criar no próximo sprint e como isso será feito. Apesar de a chamarmos de reunião de planejamento de sprint, o que ocorre na verdade é composto por duas partes bem diferentes. A Parte 1 concentra-se no que a equipe está sendo solicitada a criar e tem a participação tanto do proprietário do produto quanto da equipe. A Parte 2 concentra-se em como a equipe pretende criar a funcionalidade desejada. Embora toda a equipe precise participar da Parte 2, a participação do proprietário do produto é opcional. Se, por qualquer motivo, o proprietário do produto não participar da Parte 2, ele deverá ficar disponível caso surjam dúvidas.

Na Parte 1 da reunião de planejamento de sprint, o proprietário do produto tem a oportunidade de descrever um conjunto desejado de histórias para a equipe. Essa é uma sessão aprofundada da parte o que das histórias. O proprietário do produto apresenta as histórias, mostra como as coisas interagem e navega pela interface. Além disso, ele pode examinar a infraestrutura ou os elementos arquitetônicos. O objetivo é encher os membros da equipe com informações suficientes para que comecem a ter ideia de como criar a funcionalidade. A equipe fará uma série de perguntas para coletar informações para a reunião do como. Entre as perguntas estão:

"Qual é o critério de aceitação de todas essas histórias?"
"Quais fontes de dados você acha que estamos usando?"
"Como deve ser a interface neste componente?"

Durante a Parte 2 da reunião de planejamento de sprint, a equipe volta a sua atenção para a criação da lista de pendências do sprint, ou seja, a lista de histórias e as tarefas necessárias a serem concluídas durante o sprint. Para criar a lista de pendências, a equipe decompõe cada história que o proprietário do produto solicitou no nível de tarefa e, para cada tarefa, uma estimativa de horas é determinada. No final da Parte 2, a equipe decide as histórias com as quais ela se compromete a concluir durante o sprint.

Juntas, as duas partes da reunião de planejamento de sprint podem levar de duas a oito horas. A regra básica que uso é que cada parte deve usar uma hora para cada semana de duração do sprint. Isso significa que, se estou executando sprints de uma semana, a reunião terá um total de duas horas (uma hora para a Parte 1 e uma hora para a Parte 2). Por outro lado, se estiver executando sprints de quatro semanas, a reunião terá um total de oito horas (quatro horas para a Parte 1 e quatro horas para a Parte 2).

Como ser bem-sucedido?

Somente haverá sucesso se a equipe sair da reunião de planejamento de sprint com o compromisso de concluir uma lista de histórias. No entanto, fazer com que a equipe chegue ao ponto em que cada membro se sinta confortável ao assumir esse compromisso requer um pouco de pré-planejamento e facilitação.

O proprietário do produto tem um único trabalho durante o planejamento de sprint: comparecer à reunião e ser capaz de descrever um conjunto desejado de histórias. O objetivo da equipe é entender as histórias do ponto de vista do proprietário do produto para poder compartilhar de sua visão. O ScrumMaster deve garantir que a equipe faça uma quantidade suficiente de perguntas e capture todos os dados resultantes, incluindo os critérios de aceitação, esboços e quaisquer suposições. O ScrumMaster também deve informar ao proprietário do produto que a equipe poderá ter mais perguntas após começar a decompor as perguntas em tarefas. Embora o proprietário do produto apresente histórias cujos totais de pontos correspondem aproximadamente à velocidade do histórico da equipe, a equipe decide se poderá, de fato, assumir todas as histórias em determinado sprint com base no que aprendeu nas Partes 1 e 2 da reunião de planejamento de sprint.

Após a equipe obter todas as informações do proprietário do produto, ela deverá decompor as histórias em tarefas e criar uma lista de pendências do sprint, a qual captura todas as histórias, notas, critérios de aceitação, tarefas e estimativas de um sprint específico. Embora existam muitas maneiras de fazer isso, emprego o método a seguir, o qual aproveita todas as ideias dos membros da equipe e faz com que todos participem na decomposição das tarefas.

Após lerem uma história, o ScrumMaster ou o facilitador da reunião perguntam: "Todo mundo entendeu?" A equipe deve entender, uma vez que acabou de discutir o produto com o proprietário. Se alguém da equipe não entender, reveja a história por algum tempo, fazendo as perguntas necessárias ao proprietário do produto.
Em seguida, peça a cada membro da equipe que pegue um adesivo. Peça a cada membro da equipe que escreva uma única tarefa em cada adesivo e coloque-o no meio da mesa.
- Conforme cada adesivo é colocado sobre a mesa, a pessoa que o coloca anuncia a tarefa. Portanto, se alguém escrever "atualizar procedimento armazenado", essa pessoa lerá essa frase em voz alta. Isso é importante porque estimulará ideias e fará com que os outros digam: "Sim, precisamos atualizar a fonte de dados". Nesse momento, alguém escreverá em um adesivo "atualizar fonte de dados", dirá em voz alta e o colocará no meio da mesa. Esse brainstorm realmente funciona para revelar todas as tarefas associadas. Não se preocupe com tarefas repetidas por enquanto. Usar todos os adesivos geralmente leva de cinco a dez minutos por história.
Quando todos os adesivos estiverem sobre a mesa, é hora de classificá-los. Coloque-os todos em um mural, dê um passo para trás e olhe – você terá um monte de adesivos! Comece ao identificar todos os repetidos e sobreponha os que parecem duplicados. Depois, procure as tarefas que parecem combinar, seja porque são semelhantes ou porque dependem uma da outra. Por exemplo, se dois adesivos tiverem uma relação semelhante, coloque-os juntos, mas desloque-os um pouco, como mostra a figura abaixo:

Se duas tarefas estiverem tão intimamente relacionadas a ponto de serem quase idênticas, sobreponha-as quase que totalmente, como mostrado abaixo:

Ao classificar os adesivos, a equipe pode selecionar a lista de tarefas e visualizar as relações entre as que restam.
Após classificar as tarefas, será hora de estimar. Uso a técnica de planejamento de pôquer, ou Planning Poker, para a estimativa das tarefas, com uma diferença: os números nas cartas representam horas em vez de pontos. Faço isso porque as pessoas tendem a ficar muito presas a detalhes desnecessários com relação a horas, especialmente em grandes tarefas. Há uma boa razão para essa apreensão. Muitas vezes, as empresas usam a estimativa como uma forma de contestar a equipe. "Você disse que levaria 8 horas e levou 12. O que há de errado?" ou "Você disse que levaria 8 horas e demorou apenas 4. Você está exagerando as suas estimativas".

Da mesma forma que as cartas ajudam a manter as estimativas de pontos das histórias abstratas, o uso de cartas para estimar as tarefas permite que a equipe tenha liberdade de ter um conjunto de números fixos para escolher, sendo forçados, ao mesmo tempo, a fazer uma escolha. Isso também elimina discussões acaloradas sobre se a tarefa deve ser estimada em 6, 6,5 ou 7 horas.

Seja qual for a estimativa final, lembre-se que a estimativa é feita pela equipe e deve ser usada pela equipe apenas para ajudar a aumentar a sua confiança e determinar se é possível realizar o trabalho que o proprietário do produto pediu, com base na velocidade. As estimativas das tarefas não são métricas e não devem ser usadas como tal. Nunca use as estimativas como uma arma contra a equipe.
Agora que as tarefas foram estimadas, a equipe deve determinar se tem a capacidade de assumir mais trabalho. Para tal, você precisa conhecer a capacidade da equipe, o total de horas que a equipe tem disponível durante o sprint. Se você tiver uma equipe com dedicação total, será fácil determinar a capacidade, mas será mais difícil se você tiver uma equipe composta de pessoas que trabalham em meio período no projeto, dividindo o seu tempo entre vários projetos. Peça a todos para anotar o número de horas que cada um pode trabalhar no projeto por dia (ou o total por sprint). Junte todos os números para obter o número total de horas disponíveis para a equipe. Digamos que a capacidade da equipe é de 200 horas. Se a soma das tarefas de uma história for estimada em 30 horas, pergunte à equipe: "Podemos pegar mais trabalho?" Nesta fase inicial, a resposta obviamente será sim.

Como você tem mais capacidade, passe para a próxima história e repita os passos de um a cinco.

(Para obter informações sobre como realizar essa tarefa usando o Team Foundation Server, consulte Colaborar [redirecionado].)

Vai chegar um momento que você achará difícil responder à pergunta: "Podemos pegar mais trabalho?" Isso ocorre porque você está se aproximando da capacidade da equipe. À medida que trabalhar no processo, considere não usar a capacidade total do sprint. Se você enche um copo com água até a borda, é muito provável que a derramará. O mesmo ocorre com os sprints. Se as horas estimadas consumirem todo o tempo disponível e uma nova tarefa for identificada no final do sprint, haverá derramamento. É preciso deixar espaço para tarefas emergentes.

Ao considerar o compromisso do sprint, ajudará se você considerar dados retrospectivos de sprints passados. A equipe está tendo de trabalhar mais de forma sistemática? Talvez a equipe possa se comprometer mais durante o planejamento do sprint. A equipe sistematicamente não está conseguindo terminar todo o trabalho de um sprint? A equipe terá de ser mais conservadora com seus compromissos até tratar da causa raiz dos sprints não concluídos.

Uma maneira de colocar um número na questão "até que ponto encher o copo" é considerar o crescimento do tamanho do plano. O crescimento do tamanho do plano mede como as horas reais são gastas em comparação com as estimativas iniciais. Digamos, por exemplo, que nossa equipe tenha uma capacidade de 200 horas disponíveis. A equipe se compromete com o que acredita que durará 190 horas baseado nas estimativas. No final do sprint, a equipe calcula que as histórias tomaram 240 horas reais de trabalho, resultando em um crescimento do tamanho do plano de 20%.

Uma equipe que se depara com essa discrepância deve passar algum tempo durante a retrospectiva investigando os motivos:

Muitas tarefas são descobertas durante a execução que não foram identificadas durante o planejamento?
A equipe está subestimando suas tarefas com base no conjunto de habilidades atual?
A equipe superestimou sua capacidade?
E assim por diante.

A equipe também deve considerar o crescimento do tamanho do plano durante a próxima reunião de planejamento do sprint para determinar se pode se comprometer com uma história. Voltando ao nosso exemplo, se a equipe ainda estimar uma capacidade de 200 horas, deverá subtrair 20% do limite para compensar o crescimento "esperado" do tamanho do plano com base em dados históricos. Em outras palavras, pelo menos para este sprint e para evitar derramamentos, quando a equipe chegar a 160 horas é preciso declarar capacidade máxima.

Considere que o crescimento do tamanho do plano é uma maneira de quantificar o limite de capacidade que um sprint deve ter. Perceba, porém, que o objetivo não é exatamente igualar a capacidade. Pelo contrário, é permitir que a equipe sinta-se confiante em se comprometer com um número adequado de histórias, o qual possa impulsionar a equipe sem sobrecarregá-la. O crescimento do tamanho do plano é apenas uma maneira de determinar aproximadamente a capacidade do próximo sprint se todos os outros fatores continuarem iguais.

Quando todas as histórias forem estimadas ou a totalidade do tempo for consumido pelas histórias, procure ao proprietário do produto e compartilhe a lista de pendências do sprint com a qual a equipe se comprometeu a entregar. O sprint começa agora, portanto, ao trabalho!

Problemas comuns

Em meus anos de consultoria com equipes para ajudá-las a adotar o Scrum, vi muitos dos mesmos problemas que impedem o sucesso do planejamento de sprints. Embora o planejamento de sprint pareça simples, as equipes iniciantes no Scrum tendem a ter dificuldades. Muitos desses problemas e suas possíveis soluções são detalhados nesta seção.

Cenário: A equipe não pode se comprometer com todas as histórias que o proprietário do produto solicita.

Você deve esperar que isso aconteça de vez em quando. Contanto que equipe possa voltar no compromisso com os dados das etapas quatro e cinco descritas anteriormente neste tópico, o proprietário do produto deve ficar satisfeito. Fique atento para garantir que o não comprometimento não seja resultado de exagero em estimativas ou grandes tarefas. O ScrumMaster deve desafiar o que parecem ser estimativas excessivamente conservadoras para garantir que sejam precisas. O proprietário do produto deve questionar qualquer tarefa que tenha uma estimativa de dois dígitos. Qualquer tarefa estimada em mais de dois dias de trabalho deve ser dividida em tarefas menores e reestimadas. Isso se aplica a todos os projetos, mas é essencial para as equipes que executam sprints de uma ou duas semanas.

Cenário: O proprietário do produto não vem preparado.

Um dos valores do Scrum é o respeito. É desrespeitoso vir a uma reunião despreparado. Dessa forma, o que uma equipe deve fazer se o proprietário do produto aparecer sem as informações necessárias à equipe? Embora uma opção seja adiar a reunião até que o proprietário do produto esteja pronto, isso só incentiva esse comportamento – evite isso. Outra opção é cancelar o sprint. Embora isso possa funcionar, é algo extremo.

Acho que a melhor solução é dividi-la em duas partes. Primeiro, a lista de pendências do produto deve ter uma certa ordem de prioridade. Assim, se o proprietário do produto não tiver um determinado conjunto de histórias, tanto a equipe quanto o proprietário do produto somente poderão discutir as histórias em ordem de prioridade até chegar a um ponto em que acreditam estar dentro ou além da capacidade. Com isso, a equipe pode decidir sobre o compromisso exato durante a Parte 2 da reunião como de costume.

Após a reunião, o ScrumMaster deve trabalhar para entender por que o proprietário do produto não estava preparado. Se o problema foi falta de comprometimento, o ScrumMaster pode educar o proprietário do produto sobre a importância de comparecer à reunião preparado com um conjunto de histórias. Se, por outro lado, o problema foi que o proprietário do produto não conseguiu se preparar, talvez porque a equipe não o ajudou na preparação, o ScrumMaster deve ajudá-lo a resolver esses problemas também.

Cenário: O tempo para a Parte 1 é excedido.

Outro valor do Scrum é o foco. Se o tempo para a Parte 1 da reunião estiver acabando, trata-se de um sintoma de falta de foco. Às vezes, o proprietário do produto não tem foco por falta de preparação, priorização ou tenta explicar muitas histórias. Outras vezes, a falta de foco pode ser provocada porque a equipe desviou as conversas sobre "o que" com detalhes sobre "como".

O ScrumMaster deve ajudar na condução, insistindo que o proprietário do produto guarde as histórias que não possam ser totalmente explicadas e que a equipe mantenha as discussões de implementação detalhadas fora da Parte 1. Uma solução simples para uma discussão sem foco é usar um cronômetro.

Cenário: O tempo para a Parte 2 é excedido.

Novamente, foco. Se você tiver uma equipe que fala muito, às vezes, ter disciplina para limitar as discussões é tudo o que é necessário para trazer a reunião de volta à pauta. Traga um cronômetro e limite as conversas entre as estimativas das tarefas para um ou dois minutos. O objetivo é a exatidão, mas não com 100% de precisão.

Outras vezes, a falta de foco durante a Parte 2 é um sintoma de falta de preparação da lista de pendências do produto durante a execução do sprint. A preparação é o momento em que a equipe pode pensar nas histórias futuras e trabalhar com o proprietário do produto para adicionar histórias ou picos para especificar as direções de design ou tratar das questões arquitetônicas. Sem uma preparação regular da lista de pendências do produto, o planejamento da lista de pendências do sprint torna-se difícil e penoso.

Cenário: O proprietário do produto não está disponível.

Se o proprietário do produto não puder participar da reunião por qualquer motivo e não indicou nenhum representante, aja como se o proprietário do produto tivesse chegado à reunião despreparado. Trabalhe com os principais itens e comprometa-se com eles o melhor que puder. Você pode ser tentado a mudar o horário da reunião para acomodar a agenda do proprietário do produto. Não faça isso. Mudar o horário da reunião acomoda a necessidade de um em detrimento de muitos. Não vale a pena.

Cenário: A equipe não tem os critérios de aceitação necessários.

Sempre aconselho as equipes a perguntarem ao proprietário do produto durante a Parte 1: "Qual é o critério de aceitação para isso?" ou "O que precisamos fazer para que você aceite o trabalho?" Se isso estiver faltando na Parte 2, ao determinar as tarefas, a equipe não terá ideia de como concluir a história. Se a equipe precisar adivinhar, com base no que ouviu na Parte 1, correrá o risco de o proprietário do produto decidir, no final do sprint, que a história não está concluída. Solicite os critérios de aceitação desde o início de cada história. ScrumMasters – treine seus proprietários de produto para fornecer esses dados.

Cenário: O proprietário do produto não sabe o que significa concluído.

Assim como a equipe quer os critérios de aceitação, o proprietário do produto merece uma descrição atualizada do que a equipe quer dizer com "a história foi concluída". Essa lista de conclusão deve ser sempre publicada, atualizada e disponibilizada ao proprietário do produto de forma destacada. Uma lista de conclusão desatualizada dificulta o planejamento, porque não há o entendimento comum de como será a conclusão. Certifique-se de que a atualização da lista de conclusão seja uma parte de cada análise ou retrospectiva do sprint.

Cenário: O ScrumMaster ou o proprietário do produto está calculando/influenciando as estimativas ou o trabalho da equipe.

O proprietário do produto é bem-vindo na Parte 2 da reunião, mas sua função deve se limitar a esclarecer um requisito ou tratar de uma questão específica. O proprietário do produto nunca deve interferir na discussão da equipe sobre como implementar uma história e não deve ter nenhuma influência na estimativa de uma tarefa. O proprietário do produto tem de confiar na equipe para fazer o trabalho.

Se o proprietário do produto não agir em conformidade com essas diretrizes, o ScrumMaster deverá treiná-lo para exercer uma função mais apropriada. Se o proprietário do produto se recusar a aceitar uma função mais passiva, o ScrumMaster tem autoridade para pedir ao proprietário do produto para sair.

O planejamento de sprint não precisa ser um desafio. Trabalhar em conjunto para responder à pergunta "Com o que podemos nos comprometer?", normalmente é divertido e uma oportunidade para toda a equipe de Scrum estabelecer o espírito de camaradagem. Lembre-se, se você acha que suas reuniões são muito longas, deve ser provavelmente problemas na causa raiz. Se você é o ScrumMaster, mantenha a reunião focada, garantindo que o proprietário do produto e a equipe preparem a lista de pendências do produto. Ajude o proprietário do produto a preparar os critérios de aceitação das histórias antes da reunião. Por fim, ajude a manter o proprietário do produto e a equipe concentrados na tarefa que têm em mãos, determinando com o que podem se comprometer.