Como lidar com as expectativas do projeto através do BURN UP
Fazer uma transformação ágil em uma empresa acostumada com o controle de entregas através de projetos (PMI) gera uma mudança de paradigma muito significativa, especialmente quando se trata do controle sobre previsto e realizado.
Como lidar com as expectativas dos stakeholders e líderes de projeto, acostumados com planejamentos a longo prazo e acompanhamento baseado em cronograma, atividades e horas, numa perspectiva de time ágil?
Entre algumas opções, temos os gráficos de acompanhamento CFD, Burn down e Burnup que permitem dar visibilidade sobre o andamento do trabalho que está sendo realizado pelo time.
Iniciamos um novo projeto em Jun/17 e fizemos um Story Mapping das funcionalidades esperadas pelos usuários. No final, saímos com 35 histórias de usuário mapeadas e uma data alvo para a entrega final (dez/17).
Bem, logo na primeira sprint, o Vladson Fontes da Silva Freire sugeriu que fizéssemos o controle com o gráfico de burn up. No início, fiquei meio desconfiada daquilo gerar uma pressão desnecessária para o time. Mas entendi que seria válido dar visibilidade da evolução do projeto para a organização.
O gráfico de release BURN UP
O gráfico de release de Burn up é formado basicamente por duas linhas:
- Uma linha mostra o trabalho total (backlog) previsto para a release (ex: histórias de usuários ou total de story points);
- A outra linha mostra os itens prontos a cada sprint. Sendo assim, no final de cada sprint a quantidade de trabalho realizado aumenta, aproximando-se da linha do total previsto.
Também colocamos uma linha ideal que determina a velocidade esperada de entregas por sprint. Para cálculo da linha ideal dividimos o total de histórias pela quantidade de sprints até a data alvo. Avaliamos se esta projeção estava coerente com velocidade média histórica do time.
Lidando com expectativas
O acompanhamento do trabalho pelo Burn up foi útil para dar visibilidade do andamento do trabalho para os stakeholders, mostrando o ritmo de entregas. Além disso, foi usado para negociar prioridades com a entrada de novas histórias ao longo do projeto, mostrando a velocidade do time x o prazo esperado.
Como foi um dos primeiros projetos feitos pelo time ágil, a transparência no acompanhamento estabeleceu uma relação de confiança entre o time e o líder do projeto.
Ao final de cada sprint, apresentávamos a evolução do burn up na reunião de review. A partir do gráfico, discutíamos em conjunto sobre a evolução do projeto, repriorizações e estratégias de recuperação quando necessário.
A visibilidade sobre o andamento também manteve o time engajado e com um ritmo sustentável de entregas, sem esforço adicional e correria para cumprir a meta.
#ficaadica
Depende muito de cada time, empresa, contexto como usar o gráfico de burn up. Neste caso, fizemos um Burn up de releases de um projeto, mas também pode ser feito um burn up para acompanhamento de sprint ou MVP.
A linha ideal também é opcional e nem todos os times concordam em usá-la.
Enfim, usar o burn up como acompanhamento de projetos foi uma boa experiência neste período de transição ágil, onde há muitas incertezas sobre como acompanhar o andamento do trabalho sem gerar controle desnecessário.
Ahhh!! Antes que eu esqueça: O burn up também pode ser usado para acompanhar aquele projeto pessoal, qualquer tipo de trabalho ou meta em diferentes áreas de atuação!
Espero ter ajudado!
Siga o Makers.Co no Facebook e no Medium para acompanhar os próximos posts ;)
