Não são poucas as equipes ou empresas que cometem o equívoco de trabalhar com iterações sem que elas estejam contextualizadas. Apesar da ilusão de ser ágil trabalhando com iterações, pouco muda no resultado desse esforço. Continua-se criando um grande batch (incremento) que será promovido a algum ambiente mais estável daqui a algum tempo, e continua-se trabalhando em tarefas sem saber exatamente que problema se está resolvendo.
Pra resolver este problema quando trabalhamos com iterações em projetos, existe o conceito de release. Uma release, assim como uma iteração, é um timebox. Para criar este timebox, a maioria das empresas divide o ano em 4 partes iguais, criando assim releases de 1 trimestre. Dentro destas releases, aglomeram-se as iterações, que são contextualizadas pelo objetivo daquela release. Ou seja, a principal pergunta que vai nortear o trabalho de uma release é: que problema queremos resolver com esta release? Ou seja, que problema queremos resolver neste trimestre?
A resposta a esta pergunta vai nortear a geração do que chamamos de MVP (Minimum Viable Product) para solucionar o problema. Este MVP vai nos ajudar a escolher as features que precisaremos desenvolver durante aquela release para resolver o problema em questão.
Para auxiliar neste processo existem inúmeras ferramentas e canvas disponíveis. O SAFe, por exemplo, propõe um processo de planejamento de um ART (Agile Release Train), inclusive buscando sincronizar o trabalho de diversas equipes. Em um ambiente mais simples, dentro de um projeto de 1 equipe, pode-se usar um release roadmap para organizar uma release e dar a visibilidade necessária à equipe sobre seu MVP e o problema que ele resolve.
O autor e product manager Roman Pichler sugere o template acima para organizar um release. Repare que ele contém todas as informações necessárias para direcionar uma equipe durante um trimestre, como a data de lançamento final do produto gerado, o objetivo da release, as funcionalidades envolvidas e até métricas para acompanhar o sucesso do produto gerado.
Lembre-se: não basta criar iterações (ou sprints), aglomerar requisitos, partir para o desenvolvimento e apenas repetir este processo indefinidamente. É importante contextualizar não só a sua equipe com ferramentas como as propostas acima, como também contextualizar a sua organização sobre os seus releases. Uma ocasião como essa pode ajudar na comunicação com outras equipes que podem ser dependentes do produto da sua equipe, criando uma janela de oportunidade para que estas equipes que dependem do seu produto exponham suas necessidades antes que você planeje a sua release e parta para o desenvolvimento do MVP. 😉
