Concluímos o Sprint Backlog antes do prazo! E agora?

Em times bem sucedidos e Sprints bem definidas, algumas vezes é possível que as funcionalidades da Sprint Backlog sejam concluídas antes do término do prazo. Logo, imagine que, em uma Sprint de 30 dias, a equipe consiga finalizar as atividades em 27 dias com sucesso. O que fazer nos 3 dias restantes?
Pois bem, o objetivo deste artigo é apresentar algumas sugestões para aproveitar esse tempo, que eu diria, valioso!

Introdução

Antes que você me pergunte, concluir o backlog antes do prazo é possível, sim! Ao selecionar as user stories para a Sprint Backlog, não temos uma exatidão do tempo que será necessário para implementá-las. É por isso que trabalhamos com estimativas. Às vezes, uma determinada funcionalidade pode demorar o dobro ou o triplo do tempo estimado. Por outro lado, também é possível que uma implementação tenha sido “superestimada”, ou seja, é concluída na metade do tempo. Portanto, se houverem muitas user stories superestimadas, é provável que a Sprint Backlog seja finalizada antes do prazo.

Os dias restantes podem ser utilizados para várias atividades, no entanto, o ideal é tirar proveito deste tempo ao máximo. Confira a lista de sugestões a seguir e identifique quais delas podem ser empregadas na empresa em que você trabalha. Para facilitar o entendimento, utilizarei o cenário dos 3 dias restantes como exemplo.

1) Escolher uma funcionalidade do Product Backlog e implementá-la

Uma boa forma de aproveitar o tempo de sobra é selecionar uma funcionalidade que ainda não foi implementada. A vantagem é que as atividades dessa funcionalidade em particular poderão ser distribuídas entre toda a equipe. Enquanto um desenvolvedor estiver implementando, outros podem adiantar os testes automatizados e a documentação. Como resultado, o software terá uma funcionalidade adicional que, até então, não estava vinculada ao incremento atual do software. O cliente ficaria surpreso, hein? 🙂

Entretanto, é importante destacar que essa opção só é adequada se houver uma funcionalidade pequena na Product Backlog, na qual seja possível implementá-la nos 3 dias restantes. Caso contrário, essa funcionalidade pode comprometer a próxima Sprint. Aí não adianta nada, rsrs.

2) Conhecer as user stories da próxima Sprint

Os 3 dias podem ser utilizados para estudar a analisar o que virá pela frente. Se houverem funcionalidades complexas na próxima Sprint, é uma boa oportunidade para trabalhar nas estimativas, conhecer melhor a regra de negócio e preparar a equipe para implementá-las. Só o fato de descobrir as unidades de código que serão modificadas e os locais do software que serão afetados já é um grande benefício, além de adiantar possíveis imprevistos. Em alguns contextos, isso é chamado de “precipitação dos desafios técnicos”.

Ocasionalmente, essa opção pode resultar novamente em um período de sobra na próxima Sprint. Se acontecer sempre, será ótimo!

3) Conversar com o Product Owner sobre funcionalidades de alto valor

Essa sugestão é um complemento do item acima, porém, vista de outra perspectiva. Algumas vezes, a funcionalidade mais complexa não é necessariamente a mais importante. Portanto, uma boa ideia é discutir com o Product Owner sobre as funcionalidades de maior prioridade e analisá-las. Quanto mais a equipe estiver preparada para essas funcionalidades, maiores serão as chances de implementá-las com sucesso e, talvez, mais rápido!

4) Pagar a dívida técnica e aprimorar a qualidade

Caso o software tenha códigos duplicados, acoplamentos pesados ou dependências desnecessárias, agora é uma boa hora para minimizar estes problemas! Aplicar as práticas do Clean Code, princípios SOLID e Design Patterns pode ser útil para pagar a dívida técnica existente no software. Mas, cuidado: essas refatorações devem ser devidamente estudadas antes de colocadas em prática. Não queremos que uma refatoração dessa natureza traga novos problemas, não é?

Ainda neste contexto, pode-se trabalhar na qualidade do software em geral, principalmente envolvendo requisitos não funcionais, como usabilidade, desempenho e confiabilidade. Sabe aquela tela que os usuários vivem reclamando que está lenta e difícil de usar? Aproveite este tempo para solucionar este incômodo de uma vez por todas!

5) Testes exploratórios

Execute o software e teste-o por algumas horas para descobrir possíveis bugs. Caso encontrar algum, aproveite para corrigi-lo ou deixar a equipe consciente de que ele existe. Essa atividade pode evitar uma futura notificação de erro por parte do cliente.

6) Atualizar, instalar ou aprender novas ferramentas

Talvez você já se encontrou na seguinte situação ao conhecer uma ferramenta: “Nossa, esse software parece ser excelente e pode aumentar a minha produtividade”, porém, não tem tempo de instalar e testá-lo, não é? Comigo também acontece isso, haha.

O tempo de sobra pode ser útil para explorar novas ferramentas ou atualizar as já existentes. Muitas vezes, essas ferramentas trazem recursos que são desconhecidos, mas que podem ser altamente produtivos. A propósito, em breve vou elaborar um artigo sobre algumas ferramentas que têm me ajudado muito ultimamente.

7) Coding Dojo

Essa ideia foi sugerida pelo Diego Garcia, um grande profissional na área de desenvolvimento de software. Obrigado, Diego!

Coding Dojos são atividades de programação que têm como objetivo melhorar as habilidades e o conhecimento da equipe no âmbito técnico. Através de um processo de Brainstorming, a equipe discute melhores formas de resolver determinados desafios, também chamados de “Kata”. Com a experiência adquirida, os desenvolvedores podem replicar o aprendizado nas próximas Sprints durante as atividades de codificação. Particularmente, eu acho essa atividade bastante interessante, inclusive pelo fato de “nivelar” o conhecimento entre a equipe.

8) Ajudar outras equipes

Essa é uma sugestão solidária! 🙂

Caso a empresa tenha duas ou mais equipes de desenvolvimento, elas podem se ajudar neste tempo de sobra. Os desenvolvedores podem ser alocados durante os 3 dias restantes para exercer atividades básicas ou adicionais em equipes que estão com o backlog em cima do prazo ou atrasado. Esse espírito de colaboração é o que traz maturidade para equipes ágeis. No entanto, deixo um adendo: essa sugestão deve ser empregada somente quando viável. Se for preciso que o desenvolvedor da outra equipe interrompa as atividades para prestar orientação, esqueça. O objetivo não é atrasar ainda mais a outra equipe.

Antes de encerrar o artigo, vale fazer uma ressalva. Caso as funcionalidades de uma Sprint sejam concluídas sempre antes do prazo, recomenda-se revisar a velocidade da equipe. Talvez o número de funcionalidades selecionadas esteja abaixo do que a equipe realmente pode realizar. Neste caso, considere adicionar mais algumas funcionalidades nas próximas Sprints e verificar o desempenho da equipe.

Leitores, obrigado pela atenção e até a próxima semana!