Durante as últimas semanas li vários artigos de blog sobre o tópico: Burndown Chart e esta semana quero apresentar-vos um pequeno sumário do que fui encontrando. Espero que gostem. Um Burndown chart é uma ferramenta muito comum e útil, geralmente usada em reuniões stand-up (não só) para avaliar quanto trabalho foi finalizado numa atribuição.
[sc_pathway pathway_title="The Agile Transformation Roadmap" pathway_description="Do you want to do an Agile Transformation but you do not know where to start? This roadmap will help you! The Agile Transformation Roadmap was created based in several years of Agile transformations operated in Europe!" pathway_button_text="DOWNLOAD THE ROADMAP" pathway_button_url="https://agiletransformationmastery.com/agile-transformation-roadmap-en?utm_source=ADAPT_Methodology&utm_medium=CTA%20Box&utm_content=Burndown Chart&utm_campaign=Agile%20Transformation%20Roadmap" /]
Pessoalmente, gosto, em vez disso, de o usar como uma ferramenta de previsão, pois dá-nos uma pequena ideia de como nos estamos a sair no Sprint actual.
O formato simples e visualmente atractivo é usado por muitos praticantes Agile, porque pode ser facilmente entendido por todos os membros da equipa.
Burndown charts são usados para medir quanto trabalho foi finalizado num projecto, durante um período de tempo específico, e depois comparar com a quantidade de tempo ainda disponível para completar o mesmo.
Definem, assim, o que é realizado durante cada iteração versus a quantidade de trabalho planeada.
Os gráficos são uma ferramenta altamente útil para monitorizar trabalho finalizado e trabalho que ainda precisa de ser feito durante períodos de tempo específicos. No entanto, por muito úteis que sejam, têm as suas limitações.
Não podem, por exemplo, clara ou efetivamente medir o trabalho que ainda está em progresso; só podem medir o que já foi finalizado.
Em baixo está um exemplo de um burndown chart. Demonstra o trabalho finalizado versus o trabalho que pode ser entregue em cada iteração.
Atentando ao gráfico, pode ver que o lado esquerdo mostra o esforço total, enquanto o lado direito mostra a velocidade da equipa. Este gráfico também fornece a seguinte informação:
Embora este gráfico seja muito claro e fácil de seguir, não é necessariamente realista.
Um verdadeiro burndown chart não teria linhas direitas a mostrar períodos de tempo, porque a equipa nunca vai completar as suas tarefas à mesma velocidade ou no mesmo período de tempo.
Os Burndown charts são altamente efectivos e têm muitos pontos fortes. Embora, usar um gráfico também tenha os seus contras ou pontos fracos.
Os prós em usar um burndown chart são:
Os contras de usar um burndown chart incluem:
As equipas que têm projectos agressivos, baseados em períodos de tempo irrealistas ou sobreinflaccionados, podem ficar facilmente desapontadas, ou perder a sua motivação, quando o projecto não corre da melhor forma.
A equipa também pode desmoralizar, se sentir que está a ser micro-gerida. Qualquer informação que não seja comtemplada no burnout chart deve ser abordada numa reunião SCRUM, para a equipa ter uma imagem clara de como o projecto está a avançar.
Para criar e usar um burndown chart efectivamente, a equipa tem primeiro de implementar uma separação de tarefas. Tal geralmente acontece numa reunião de planeamento sprint.
Cada tarefa identificada na divisão de tarefas deve ter uma quantidade de tempo alocada, designada para finalizar a tarefa. Idealmente 12 horas é a melhor quantidade de tempo. Isto pode ser dividido em dois dias de seis horas.
Uma vez feita a divisão de tarefas, a equipa pode criar e conspirar o seu burndown chart. Se a equipa assume que todas as tarefas serão finalizadas à mesma velocidade, então as suas ideias devem reflectir o seu progresso consistente.
Há muitas ferramentas Agile disponíveis com algumas funcionalidades built-in de burndown chart. Algumas destas ferramentas são: Rally, RTC, Version One e Mingle.
Se não tem nenhum desses programas, pode usar um excel spreadsheet para criar um burndown chart. No spreadsheet, coloque as datas de sprint no eixo X e os restantes esforços no eixo Y.
Incluí um exemplo de um burndown chart ideal em baixo:
Neste exemplo, o sprint é 2 semanas; a equipa tem sete membros que trabalham 6 horas por dia num total de 420 horas. Como pode ver, o total de horas para o sprint completo são mostrados no eixo Y.
A linha vermelha mostra que o progresso ideal de trabalho deveria ser durante o sprint. Se assumirmos que não vão haver problemas ou atrasos, todas as tarefas devem ser finalizadas no final do sprint.
O seguinte exemplo demonstra burndown to chart the team’s progress during the sprint:
Pode ver que a linha vermelha mostra o progresso que foi finalizado, enquanto que a linha azul mostra o esforço restante necessário para completar o projecto.
Projectos Scrum podem lançar burndown charts, para seguirem o seu progresso. O Scrum Master é responsável por actualizar o lançamento no final de cada exercício sprint.
Neste gráfico, o eixo horizontal mostra cada sprint enquanto que o trabalho restante é mostrado no eixo vertical. As equipas podem usar qualquer método que escolherem para mostrar a quantidade de trabalho restante incluindo story points, dias da equipa e dias ideais.
Um exemplo de lançamento burndown pode ser visto em baixo:
Neste exemplo, o gráfico mostra que a equipa começou com 360 story points. Para completar com sucesso o seu projecto, nos seis sprints planeados, a equipa terá de ter em média 60 story points por cada sprint.
Este exemplo também mostra que, num primeiro sprint, a equipa usou 90 story points com 270 remanescentes. O segundo sprint correu bem também.
No entanto, como pode ver no gráfico, algo aconteceu durante o terceiro sprint e a equipa queimou os seus story points. Depois de resolvidos os problemas no terceiro sprint, o projecto correu bem nos restantes sprints.
Existem algumas razões pelas quais as equipas podem queimar os seus story points, incluindo trabalho extra para o projecto, fazendo mudanças no período de tempo, ou ajustando estimativas de trabalho. Uma vez que estes sejam reavaliados, o projecto deve começar a correr bem novamente.
O lançamento de burndown charts entre equipas, porque trabalham com uma variedade de situações. Contudo, não funcionam bem em projectos em que ocorrem muitas mudanças. Estes projectos funcionam melhor com uma forma alternativa ao lançamento do burndown chart.
Estes erros comuns cometidos pelas equipas agile podem conduzir a informação enganadora nos burndown charts:
Existem alguns projectos onde as equipas têm múltiplas stories mas só uma função genérica. Os burndown charts podem ser enganadores nessas circunstâncias porque adicionar tarefas extra vai resultar no número errado de horas totais.
Seguir o progresso com o tempo incorrecto também é enganador.
Se houver demasiadas tarefas criadas num projecto, torna-se muito difícil para equipa segui-las de forma consistente. As tarefas devem ser pequenas o suficiente para que sejam finalizadas em 12 horas.
Tarefas morosas não podem ser avaliadas apropriadamente num cronograma diário; as equipas não podem avaliar quanto trabalho ainda resta.
Este é um dos erros mais comuns cometidos pelas equipas. Para evitar cair neste erro, as equipas devem re-estimar as suas tarefas, ao final de cada dia, e actualizar quanto mais tempo será necessário para terminar a tarefa.
As equipas devem actualizar as medidas do ‘esforço restante’ nos seus burndown charts todos os dias. Se as equipas se atrasarem nesta tarefa, o seu burndown chart poderá não ser exacto.
Há dois tipos de gráfico diferentes que são usados para medir o tempo num projecto Scrum: burndown e burnup. Burndown charts medem quanto trabalho resta num projecto. Por outro lado, burnup charts, medem a quantidade de trabalho que já foi finalizado e o total de trabalho que foi feito.
As equipas terão a vida facilitada, ao decidir que tipo de gráfico vão usar no seu projecto, se olharem primeiro para a meta do mesmo.
Por exemplo, se o seu objetivo é manter o projecto vivo, apresentando informação a um cliente, ou se o Scrum Master está a tentar motivar a equipa, um burnup chart será uma melhor opção. Mas se o Scrum Master quer saber mais ou compreender o que se está a passar no projecto, o burndown chart é, em dúvida, a melhor escolha.
Outra diferença entre burndown e burnup charts é que um é simplista, enquando o outro dá informação. Burndown charts são simples: uma linha tende para zero quando a equipa completa o projecto.
São facilmente compreendidos por todos na equipa e não requerem uma explicação longa. No entanto, os burndown não nos contam a história toda. Muitas vezes, escondem certa informação como os efeitos do scope creeping. Tal ocorre sempre que é adicionado ou removido trabalho de um projecto. Todos os praticantes de Agile e membros das equipas devem estar familiarizados com o scope creeping.
Este ocorre quando os clientes adicionam funcionalidades extra ao projecto ou eliminam tarefas para que o projecto seja finalizado a tempo. Um burndown chart não pode mostrar estas mudanças, mas um burnup chart pode.
Os Burnup charts usam duas grelhas separadas para seguir o trabalho que foi finalizado e a quantidade total de trabalho já feita. A linha de trabalho feito pode fornecer informação vital à equipa sobre o porquê deste projecto não estar finalizado.
Algumas razões incluem: o trabalho está muito lento; muitas novas tarefas foram adicionadas ou houve outros problemas dentro do projecto.
Os Burnup Chats são a melhor escolha para usar na reunião para Scrum Masters que se reúnem regularmente com a sua equipa ou clientes. É mais fácil mostrar o progresso semanal da equipa com um burnup chart. Este tipo de gráfico também vai mostrar ao grupo qualquer teste ou problemas que adicionaram mais trabalho durante a semana.
Scope creeps não são benéficos para projectos de software. São mudanças ou crescimento incontrolado de um projecto. Quando os alargamentos de âmbito estão a afectar o projecto, os burndown charts mostram pouco trabalho feito.
Contudo, burnup charts vão claramente expor o scope creep num projecto. Embora os scope creeps sejam prejudiciais para um projecto e um pesadelo para todas as equipas, também podem ser benéficos. Quando um scope creep é exposto, a equipa pode usá-lo para convencer os clientes a pararem de mudar ou de adicionar trabalho ao projecto.
Um projecto com fixed scope tem uma data de finalização para atingir todos os story points. Os fixed scopes só acontecem em situações limitadas. Para prjectos com prazos de fixed scope, os burnup charts não são úteis porque não dão mais informação do que os burndown charts.
Os Scrum Masters usam regularmente burndown charts e stand-ups diários como uma ferramenta de auto-organização com a sua equipa. Os burndown charts fornecem um resumo do trabalho da equipa. Mostra ao master e aos membros que trabalho completaram e que problemas enfrentam.
A informação fornecida no gráfico pode ser usada como dados introduzidos numa stand-up diária. Se uma equipa achar que se está a atrasar, há coisas que podem fazer para voltarem a encarreirar.
Podem:
Um de-scoping só deve ser feito em último caso. Toda e qualquer solução possível devem ser olhada em primeiro lugar, antes de dar este passo.
O propósito de usar um burndown chart num stand-up diário é fazer com que a equipa volte aos prazos novamente.
Durante as reuniões, é importante que o Scrum Master procure diferentes pistas: quão bem a equipa está a trabalhar junta, quem lidera, o nível de honestidade; colaboração e compromisso com cada projecto por parte de cada membro.
Os burndown charts fornecem um bom input em reuniões de sprint retrospective, porque as equipas podem ver as mudanças e olhar para a informação, no sentido de encontrar a causa real de cada problema ou atraso. Através de discussões entre a equipa e reuniões de brainstorming, as equipas podem analisar a informação e encontrar soluções.
Os burndown charts com as horas remanescentes são óptimos instrumentos para acompanhar a quantidade de tempo restante em cada tarefa. São fáceis de ler e mostram rapidamente à equipa se estão a tempo para completar os seus story points no final de cada sprint.
Ainda assim, como mais eficaz e fácil que um gráfico seja, muitas equipas ainda enfrentam um problema muito comum: a informação no gráfico parece enganar a equipa. Enquanto os gráficos mostram a equipa no ponto em cada sprint, a realidade é muito diferente. Isto acontece, porque tendemos a aceitar, muitas vezes, o mito “Planeie o trabalho, trabalhe o plano”, sem nos esforçarmos na finalização das tarefas.
É mais fácil planear o projecto, mas para o completar, é preciso que a equipa trabalhe nele.
Como pode saber se isto está a acontecer na sua equipa? Aqui estão alguns sinais:
Para evitar que isto aconteça na sua equipa, é importante concentrar-se na primeira directiva. Use software que possa completar burndown charts no sprint. Foque-se nas stories completas como métrica primária. Adicione um burndown chart completo para ajudar a recuperar o foco da sua equipa.
Os burndown charts com as horas remanescentes nunca devem ser descartados porque são uma ferramenta valiosa que pode ajudar a equipa a organizar o trabalho que ainda precisa de ser feito.
Pode usar estas ferramentas para manter a equipa focada na situação presente do projecto; não em mitos passados ou falsas esperanças.
A evolution4all é especializada em ajudar empresas a reinventarem-se para ficarem rápidas, fléxiveis, modernas e inovativas como as startups! Se estiver interessado no terceiro pilar do ADAPT METHODOLOGY™ - especificamente a parte da Agilidade pode ver os nossos serviços: Consultoria Agile e Formação Agile. Se estiver interassado em desenvolver-se como um líder moderno, é capaz de estar interessado no nosso acelerador: Digital Leadership Accelerator.
[sc_pathway pathway_title="The Agile Transformation Roadmap" pathway_description="Do you want to do an Agile Transformation but you do not know where to start? This roadmap will help you! The Agile Transformation Roadmap was created based in several years of Agile transformations operated in Europe!" pathway_button_text="DOWNLOAD THE ROADMAP" pathway_button_url="https://agiletransformationmastery.com/agile-transformation-roadmap-en?utm_source=ADAPT_Methodology&utm_medium=CTA%20Box&utm_content=Burndown Chart&utm_campaign=Agile%20Transformation%20Roadmap" /]