Sprints reduzidas: Uma aplicação prática do manifesto ágil em projetos

Resumo:
Conduzir Sprints de duas semanas, não se limita a tão somente fragmentar em duas semanas uma Sprint que antes era de quatro semanas. Interações reduzidas auxiliam o Time de Scrum eo cliente na identificação de um “Objetivo de Negócio” essencial para cada momento, que dará o melhor retorno para o negócio dentro de no máximo duas semanas. A ênfase desta expertise está na capacidade do time em analisar, negociar e quebrar um “Objetivo de Negócio” (possivelmente uma macro história do backlog) em histórias menores para possibilitar uma sprint com entrega visando um único objetivo de negócio eminente.

Em Sprints de quatro semanas, Times de Scrum trabalham histórias com pontuações altas e diferentes objetivos de negócio, gerando incertezas, impedimentos , falta de foco e trabalho desnecessário.

Em Sprints menores, de duas semanas por exemplo, é extraído do backlog o objetivo de negócio, analisado e quebrado em histórias de baixa pontuação com suas respectivas tarefas, compondo um conjunto de atividades com um único objetivo que será o objetivo da Sprint, favorecendo a filosofia ágil que é a de fazer apenas o que é essencial para o momento.

Recebemos um feedback mais rápido do cliente, assim o Time de Scrum e o Cliente alinhados, perseguem juntos o que será mais importante para o próximo momento, seja uma melhoria na funcionalidade ou um novo objetivo, tudo na medida certa, evitando perdas com desenvolvimentos desnecessários, “maximizando o trabalho não realizado”, que provavelmente não agregaria valor.

Razão da boa prática:
O desafio de aplicar o manifesto ágil na prática utilizando sprints menores, traduz esta razão nos resultados comprovados, que podem ser por exemplo: Um grupo de pessoas (Time de Scrum e Cliente) com um discurso único, unidade de pensamentos e todos trabalhando para alcançar um único objetivo, com todos se sentem donos do problema e motivados.

Aumento significativo do foco, conhecimento sobre o que precisa ser feito em cada interação, comprometimento, menos riscos e incertezas e qualidade nas entregas.

Ao contrário do que se pensa, não há aumento de trabalho ou da participação do cliente e sim, a otimização deste tempo, as reuniões com o cliente ficam mais rápidas e objetivas, as priorizações mais fáceis e coerentes, permitindo feedbacks do cliente com maior frequência, maximizamos o trabalho não realizado, ou seja, desenvolvemos somente o que realmente é essencial e necessário para o momento do negócio.

Detalhes da boa prática:
Toda Sprint possui um “Objetivo de Negócio”, visão explicita sobre uma questão de negócio a ser resolvida, algo que o negócio deseja e pretende alcançar para obter os benefícios ou as vantagens esperadas para o momento.

Sem perceber, muitos times de Scrum pontuam e quebram em tarefas os “Objetivos de Negócio”, ao invés de fazerem isso com as “Histórias”. Quero dizer que um backlog com histórias de 40 pontos, 20 pontos e até de 13 pontos, podem na verdade possuir objetivos de negócios “disfarçados” de histórias. Esse equívoco é muito comum em Times de Scrum que utilizam a metodologia relativamente há pouco tempo. Histórias com altas pontuações escondem ricos, estimativas equivocadas devido a dificuldades intrínsecas, incertezas,
dificultam a analise de sistema, podem acarretar em baixas qualidades nas entregas e o principal de tudo, prejudica a maximização do trabalho não realizado.

Sprints de duas semanas nos auxiliam na identificação do “Objetivo de Negócio” priorizado para o momento, que geralmente pode estar no product backlog na forma de história, que precisa ser quebrada em outras histórias para se ter o entendimento sobre tudo necessário (em “Histórias”) para se atingir o “Objetivo de Negócio”. Logo, uma história de 20 pontos (provável Objetivo de Negócio) será quebrada por exemplo, em 4 histórias de 8, 5, 3 e 5, totalizando 21 pontos no backlog da Sprint de duas semanas, obtendo um feedback mais rápido do cliente, como realmente acorre com o projeto. Assim, com negociações e maior envolvimento entre TI e Negócio, atingimos sempre ao ponto, incrementando o que é essencial para o momento.

Se fossem quatro semanas na Sprint, fatalmente a Sprint seria preenchida com outros “Objetivos de Negócio” para completar a capacidade média produção do Time, de 40 pontos.

Este é um erro básico que acarreta na falta de foco derivado da falta de um objetivo único, menos unidade da equipe e o pior erro de todos, foge a filosofia de “maximizar o trabalho não realizado”, ou seja, histórias entrariam no backlog da Sprint para completar a capacidade produtiva do Time, o que em um cenário de Sprints de duas semanas talvez não fossem priorizadas para o próximo ciclo, como de fato foi presenciado por várias ocasiões quando adotamos trabalhar com Sprints curtas de duas semanas.

Em Sprints de duas semanas todos os envolvidos saberão dizer qual é o objetivo da Sprint.

Assim, um backlog pontuado com uma macro história de 20 pontos priorizada pelo cliente, possivelmente será observada na planning 1 como “Objetivo” (o cliente dá sinais sobre isso), que será quebrado em histórias pelo Time de Scrum, onde cada história atingirá no máximo 8 pontos como ocorre na prática. Na Planning 2, as histórias são quebradas em tarefas pelo Time e finalmente está montado o Backlog da Sprint, com suas histórias e tarefas visando atingir um único objetivo, para em duas semanas receber o feedback do cliente, que sempre norteia o trabalho para o que é mais essencial a fazer.

Entregas em produção são perfeitamente possíveis, quando se negocia conceitos funcionais que em produção já agregarão valor ao negócio. Mas para isto acontecer, é necessário um Time de Scrum experiente, com aptidões que permitam uma visão analítica dos problemas de negócio, capacidade de prospectar e propor soluções de TIC, devido ao conhecimento do negócio e domínio da solução sob todos os aspectos.

O sucesso com Sprints reduzidas, tem sido comprovado através do reconhecimento do negócio em avaliações periódicas do Time de Scrum e em medições do projeto, onde também percebemos a otimização do ROI no avanço físico do projeto.

Boa sorte com Sprints reduzidas!

[Crédito da Imagem: Sprints Reduzidas – ShutterStock]