Release Planning é uma das boas práticas que aplicamos na Metodologia Ágil.
Trata-se de uma reunião de planejamento de alto nível que abrange a iteração dos Sprints futuros ( ex: Sprints num período de 2 meses). Nessa reunião temos visão a longo prazo do que será feito, quais recursos serão implementados e quando serão concluídas.
Como o próprio nome já diz, planejamos as entregas que vão ocorrer ao longo do projeto e monitoramos o progresso do mesmo ( onde estamos e para onde vamos ).
Para criar um Release Planning você precisará dos seguintes itens:
1) Datas de início e fim dos Sprints;
2) Product Backlog escrito e priorizado;
3) Velocidade Média do Time ( envolve quantidade de pessoas no projeto );
No item 1, o Scrum Master fica responsável por essa atividade. Ele deve planejar o Release Planning, levantando as datas de início/fim dos Sprints futuros, os feriados e férias existentes em cada iteração. Além disso, ele facilita a reunião, expondo e explicando todas as informações no quadro (conforme a figura acima do texto).
O item 2, fica com Product Owner (PO), que deverá colocar em cada post it, as histórias que precisam ser entregues em determinadas datas (de acordo com a estratégia de lançamento do produto). O PO detalha a história, para poder explicar ao time o que realmente deseja que seja entregue em cada item. O Time conversa sobre o desenvolvimento da história e estima cada uma delas ( pode usar Fibonacci ou PMG). O Time organiza as histórias nos Sprints avaliando dependência técnica e o PO reorganiza, alinhando as entregas necessárias até haver um consenso.
Eh finalmente, o item 3 diz respeito ao Time, a velocidade média de pontos que o Time faz por Sprint. Esses dados costumam ficar expostos nos quadros. Mas o Scrum Master sempre sabe a média de pontos que o Time costuma atingir.
É importante termos a velocidade média do Time, porque se for necessário fazer uma entrega rápida e que demande muito esforço, precisamos aumentar o número de pessoas do Time. Ou montarmos um Time de “seniors” para não haver atraso na entrega.
Reparem que os projetos sempre vão trabalhar com os 3 eixos: Tempo, Esforço e Custo! Esses itens são essenciais para o projeto! Se faltar um deles, o projeto tende a fracassar.
E quanto as pessoas? Pessoas é um recurso importante, certo?
Errado por um único aspecto. PESSOAS NÂO SÃO RECURSOS!!!!! Recurso é mesa, cadeira, notebook. Temos que PARAR de tratar nossos funcionários como objetos, pois eles pensam, trabalham e tem opinião. Pessoas contribuem para evolução do seu produto!
Pessoas estão contidas em todos os eixos e processos de um projeto. Sem elas, seria impossível fazermos algo!
Bom… Depois de ter todos esses itens, você poderá agendar sua reunião de Release Planning, envolvendo todo o Time (PO, SM, Dev´s, Designers, etc).
Geralmente, as reuniões de Release Planning duram de 2h a 4h. Mas esse tempo não é parâmetro, pois pode variar de acordo com a quantidade de histórias e Sprints que você planejará.
As reuniões de Release Planning costumam ser “bem animadas” (para não dizer agitadas…rs), porque confrontamos a visão de negócio do PO com a visão técnica do Time. Até encontrarmos um alinhamento entre os interesses de ambos, demora um pouco. Mas sempre se resolve. O mais importante é mante é calma e não levar a discussão para o lado pessoal.
O Scrum Master pode e deve ajudar nesse momento, atuando como: mediador nas discussões, facilitador expondo as soluções nos quadros, lembrando de fatos importantes que podem impactar a entrega do produto, etc.
Resumindo, o Release Planning é uma pratica de muito valor quando bem aplicada. Gera excelente resultados para todos do Time.
Mas gostaria de lembrar que, qualquer alteração no Product Backlog, pode impactar todo planejamento dos Sprints feito no Release Planning. Caso isso aconteça, é necessário fazermos um novo Release Planning, ou seja, avaliar quais as histórias foram alteradas, se o valor estimado continuará o mesmo e se irá impactar a data de entrega. Se você não parar o Time para reavaliar as mudanças ocorridas, você não entrega seu produto de forma satisfatória.
Espero ter colaborado mais uma vez com vocês!
Então vamos praticar pessoal!
Até mais!
Muito bom Annelise!
Oi Frederico!
Que bom que gostou! A intenção é disseminar conhecimento e praticas, tanto voltadas para Agilidade quanto para Coaching.
Muito obrigada!
Abs
Oi, Annelise! 2 ?: quando vc faz, dentro da sprint, a release planning? ou isso é trabalho do PO, que usa um tempinho do Devteam pra estimar e SM pra facilitar? E outra: se a ideia é nao termos tanta inspeção pra nao atrapalhar o flow e ja temos, alem das cerimonias scrum, o gromming, nao seria o release planning aquele material util apenas no sprint planning pra definir o Sprint bklog? Grato!
Olá Hudson! Vamos la… O Release Planning é uma cerimônia de planejamento que fazemos de vez enquando para atualizamos nosso roadmap e nossos releases. Eu costumo fazer de 3 em 3 meses e apenas revisitar para lembrar com o time. No início levamos 1 dia para fazer um Release Planning por não termos prática. Mas com o passar do tempo conseguimos minimizar esse tempo para uma tarde. O Release Planning não é um trabalho só do PO, pois o time precisa dizer se tem dependências técnicas que viabilizam ou não o desenvolvimento. Os usuários precisam dizer em quanto tempo querem a funcionalidade. Logo é uma reunião que negociamos negócio, desenvolvimento e entrega. Quanto a visão de o Release Planning atrapalhar é equivocada, porque só ajuda! Depois que vc sai com 3 meses de desenvolvimento planejado, fica mais facil quebrar e detalhar as funcionalidades tanto no grooming quanto no planning. E muita das vezes, de tanto falarmos nos assuntos e sabermos o que realmente é necessário fazer, o grooming fica obsoleto. Então tudo é processo de aprendizado meu amigo! Espero ter ajudado! Bom trabalho e obrigada por ter deixado sua duvida 🙂