The Scrum Framework — Segunda edição

Este capítulo mantém o contexto histórico e prático de ensino da segunda edição. O currículo da terceira edição também está disponível no índice abaixo.

---

Gráfico de burndown em Scrum para dominar o progresso ágil

À medida que o desenvolvimento de software evolui rapidamente no século XXI, transformar o caos em ordem tornou-se fundamental para o sucesso. Uma forma segura de ganhar controlo sobre o ciclo de vida do projeto é utilizar uma ferramenta aparentemente simples, mas muito poderosa: o gráfico de burndown. Muito valorizada em Scrum, um dos principais frameworks ágeis para concluir projetos complexos, esta representação gráfica pode transformar a sua abordagem à gestão de tarefas e prazos. Este artigo mostra como utilizar eficazmente o gráfico de burndown no contexto Scrum para alcançar ciclos de desenvolvimento de software fluidos. Entre e transforme o seu Sprint Planning numa ferramenta estratégica poderosa!

Um gráfico de burndown é uma ferramenta valiosa em Scrum para visualizar o progresso do trabalho ao longo do tempo. Ajuda as equipas a acompanhar o âmbito e o calendário e a comparar o trabalho planeado com o progresso real. Ao representar o trabalho restante em função do tempo, permite prever quando tudo estará concluído e tomar decisões informadas para assegurar entregas bem-sucedidas nos Sprints.

Definição de gráfico de burndown em Scrum: O gráfico de burndown Scrum é uma ferramenta visual de medição que mostra o trabalho restante ao longo do tempo, em comparação com uma tendência de referência para um Sprint ou lançamento. Ajuda a equipa a avaliar o progresso e adaptar o plano em direção ao resultado pretendido.

Compreender o gráfico de burndown em Scrum

Em Scrum, um gráfico de burndown representa visualmente o progresso da equipa ao longo do tempo em direção ao objetivo do Sprint. Criado no início de cada iteração, mede o trabalho por concluir em função do tempo. Assim, os membros veem quanto trabalho resta e podem ajustar o percurso para se manterem no rumo certo.

Imagine que trabalha num projeto de desenvolvimento de software com Scrum. Tem um Sprint de duas semanas com 80 horas de trabalho estimadas no Sprint Backlog. Depois do primeiro dia, está concluído trabalho anteriormente estimado em 20 horas. Se não tiver sido acrescentado ou reestimado trabalho, restam 60 horas. O gráfico representa essa estimativa real restante em comparação com a linha de referência.

Ao longo dos dias, se o progresso real corresponder ou superar estas previsões, tudo decorre bem. Se a equipa tiver dificuldades em acompanhar o ritmo ou estiver adiantada, poderão existir questões subjacentes a tratar. Por isso, acompanhar o gráfico de burndown pode impedir que possíveis dificuldades se tornem problemas mais graves no futuro.

Representação visual do trabalho em função do tempo

Uma vantagem importante do gráfico de burndown é a simplicidade e facilidade de utilização. Normalmente apresenta num eixo vertical o «trabalho restante», muitas vezes em story points ou horas, comparado com o tempo no eixo horizontal.

Pense na navegação com Google Maps para um destino desconhecido: o progresso é marcado por pontos de referência, juntamente com a localização atual e a distância estimada até ao destino.

A linha de tendência ideal (ITL) é uma referência reta que representa uma redução uniforme da estimativa inicial ao longo do período definido. O trabalho real não tem de a seguir exatamente. As circunstâncias variam e o progresso diverge habitualmente da ITL; os desvios podem indicar sobrestimação, complexidade subestimada nas tarefas ou bloqueios ao progresso.

Como podem as equipas aproximar a trajetória do gráfico da ITL e que aspeto tem um gráfico de burndown saudável? São alguns dos fundamentos que aprofundaremos na secção seguinte.

Como utilizar um gráfico de burndown

Um dos maiores benefícios do gráfico de burndown é fornecer informações atualizadas e exatas sobre o progresso do projeto. Um gráfico adequado permite acompanhar facilmente os objetivos, verificar desvios da inclinação ideal e descobrir problemas que dificultam a conclusão atempada das tarefas. Para o utilizar eficazmente, é necessário revê-lo e atualizá-lo constantemente, garantindo dados atuais.

Por exemplo, se durante um Sprint a equipa concluir tarefas mais lentamente do que o previsto devido a um desafio inesperado ou a requisitos de desenvolvimento mais complexos, o gráfico mostrará o desvio da linha de tendência ideal.

Ao rever o gráfico regularmente e identificar estas oscilações, pode tomar medidas corretivas proativamente com a equipa. Assim, o projeto não perde o rumo e adapta-se conforme necessário para manter o alinhamento com os objetivos.

• Segundo o 14.º relatório State of Agile da VersionOne, 83% dos inquiridos, que representam sobretudo equipas de software, afirmaram utilizar Scrum ou métodos Scrum híbridos, indicando a possível utilização generalizada de gráficos de burndown como um dos principais mecanismos de controlo.
• Um estudo publicado em «Information and Software Technology» analisou 160 Sprints de 16 projetos de desenvolvimento de software e concluiu que divergiam frequentemente da linha ideal de burndown, com um desvio médio de aproximadamente 25%.
• O mesmo estudo indicou que, apesar disso, cerca de 72% destes Sprints cumpriram os objetivos de conclusão, sugerindo que a análise regular e a adaptação apoiadas por ferramentas como os gráficos de burndown podem gerir os desvios com sucesso ao longo do tempo.
• O gráfico de burndown é valioso para acompanhar o progresso e identificar problemas que podem afetar a conclusão atempada. Permite acompanhar desvios da inclinação ideal e tomar medidas corretivas proativamente. A revisão e atualização regulares são fundamentais para garantir dados exatos e atuais.

Passos para criar um gráfico em Scrum

Criar um gráfico de burndown útil em Scrum exige algum planeamento prévio para que as equipas acompanhem eficazmente o progresso.

Pense na construção de uma casa. Antes de começar, os arquitetos têm de preparar plantas que orientem os construtores. Da mesma forma, antes de criar um gráfico de burndown, é necessário definir parâmetros específicos para trabalhar em direção a objetivos mensuráveis.

Antes de detalharmos a criação de um gráfico para desenvolvimento de software em Scrum, lembre-se de que existem várias opções para o gerar. Ferramentas online, como Process Canvas da Visual Paradigm, oferecem interfaces intuitivas e processos automatizados que facilitam ainda mais a tarefa.

Eis os passos gerais:

1. Determinar a duração do Sprint: O primeiro passo é determinar a duração dos Sprints, normalmente entre 1–4 semanas.
2. Identificar o Sprint Backlog: Um backlog define os itens que precisam de atenção em cada momento do desenvolvimento; o mesmo se aplica à criação de um gráfico de burndown. Identifique todos os itens a entregar em cada Sprint.
3. Determinar a velocidade: A velocidade corresponde à quantidade de trabalho concluído pela equipa num período definido. A velocidade histórica pode ajudar nas previsões, mas não é um pré-requisito para desenhar um gráfico de burndown e uma equipa nova pode ainda não a conhecer.
4. Conceber o gráfico de burndown: Com os dados acima, conceba um gráfico que agregue a informação e ofereça uma representação exata do progresso face aos objetivos.

Depois de o criar, lembre-se de o atualizar diariamente para acompanhar o progresso e rever regularmente como os dados correspondem aos objetivos finais do projeto.

Agora que sabe criar um gráfico de burndown em Scrum, vejamos como o utilizar para acompanhar o progresso.

Acompanhar o progresso através do gráfico de burndown

Na metodologia Scrum, as equipas utilizam o gráfico de burndown para acompanhar o progresso na conclusão de todos os itens de trabalho de um Sprint. Assim, sabem com exatidão quanto trabalho resta e podem adaptar a abordagem. O gráfico é atualizado diariamente com informações sobre tarefas concluídas e esforço restante, pelo que atualizações frequentes podem revelar padrões ao longo do tempo.

O ritmo de progresso de uma Scrum Team chama-se «velocidade». Expressa, por exemplo, a quantidade de story points concluídos por iteração. Uma regra importante é contar apenas histórias concluídas no fim da iteração. É rigorosamente proibido contar trabalho parcialmente terminado, como código sem os respetivos testes.

Após vários Sprints, uma equipa pode dispor de dados de velocidade suficientes para prever a conclusão, desde que o trabalho e as condições permaneçam suficientemente comparáveis. Se a velocidade for, por exemplo, de 30 story points e restarem 155, podemos prever cerca de 6 Sprints para concluir esse âmbito, assumindo que a velocidade e o âmbito se mantêm estáveis.

Por exemplo, imagine um Sprint de duas semanas em que uma equipa hipotética acompanha um volume de trabalho concluído de 100 story points por semana; esta taxa semanal não deve ser confundida com a velocidade por Sprint. Ao representar o progresso diário, a equipa pode verificar se está adiantada ou atrasada e tomar medidas corretivas quando necessário.

Com o acompanhamento estabelecido, é essencial compreender como ler e interpretar os dados do gráfico.

Interpretar os dados do gráfico de burndown

O eixo horizontal representa o tempo e o vertical mostra o trabalho restante em cada dia, idealmente reduzido a zero no fim do Sprint. A linha de tendência ideal serve de referência para a discussão; uma equipa saudável inspeciona o padrão real em vez de tentar forçar uma forma perfeita no gráfico.

Suponha um Sprint de dez dias úteis com 100 horas de trabalho total por concluir. No DIA 1, deverá esperar um ritmo ideal de redução de dez horas por dia.

Um desvio pode refletir alterações de âmbito, reestimativas, impedimentos ou o momento em que o trabalho é concluído. Uma linha acima da ideal significa normalmente mais trabalho restante do que o previsto; uma linha abaixo significa normalmente menos. Nenhum padrão prova, por si só, a existência de um problema. Discuta as causas e o Sprint Goal antes de decidir adaptar o plano.

Pense na leitura rápida de um livro: consegue ler e compreender, em média, 50 páginas por hora, mas repara que demora mais de 45 minutos a ler 20 páginas. Esse desvio indica que algo não está bem: ou o ritmo precisa de melhorar ou o livro exige atenção adicional.

Avaliar os objetivos do Sprint através do gráfico

O gráfico de burndown é uma ferramenta poderosa para avaliar se os objetivos do Sprint são exequíveis. Ajuda a equipa a acompanhar o progresso na conclusão das User Stories do Sprint Backlog. Visualizar o trabalho restante ao longo do tempo permite compreender claramente o esforço diário necessário para cumprir os objetivos definidos.

No desenvolvimento ágil de software, comprometer-se com um Sprint Goal sem saber se a equipa o pode cumprir dentro da iteração pode provocar atrasos, marcos não cumpridos e, em última análise, o insucesso do projeto.

Com um gráfico de burndown, pode identificar rapidamente quando é provável que os objetivos sejam cumpridos antes do fim do Sprint. Idealmente, ao rever padrões dos Sprints anteriores e comparar o progresso diário com esse histórico, as equipas podem corrigir proativamente o percurso para garantir bons resultados.

Compreender a gestão destes gráficos é igualmente essencial, pois têm vantagens e desvantagens no desenvolvimento de software.

Na realidade, porém, os itens do Scrum Product Backlog mudam durante o projeto. São acrescentadas histórias e outras são alteradas ou eliminadas. Num gráfico de burndown simples, não é possível distinguir a velocidade da Scrum Team das alterações de âmbito. Para refletir essa diferença, pode utilizar-se outro tipo de diagrama.

Vantagens e desvantagens dos gráficos de burndown na gestão de equipas ágeis e no desenvolvimento de software

Os gráficos de burndown estão entre as métricas mais utilizadas em Scrum, por serem formas simples e eficazes de visualizar o progresso e prever datas de conclusão. Mas, como qualquer ferramenta, têm vantagens e desvantagens.

Vantagens

Os gráficos de burndown dão transparência e informação sobre o trabalho restante em cada momento. A simplicidade e clareza da visualização ajudam a evitar a sobrecarga de informação, oferecendo ao mesmo tempo uma visão valiosa das atividades diárias.

Além disso, apoiam a responsabilidade coletiva ao tornar visível o trabalho restante e ajudar a equipa a discutir a carga de trabalho e os impedimentos. Um gráfico ao nível da equipa não identifica a velocidade ou produtividade de uma pessoa.

Desvantagens

Embora ofereçam benefícios concretos, os gráficos de burndown também têm possíveis desvantagens a considerar. Por exemplo:

• Podem criar uma impressão irrealista: consoante as estimativas anteriores sobre complexidade técnica, especificações do produto ou outros fatores que surjam no desenvolvimento, podem dar a impressão de um progresso global exponencial perto do fim do Sprint.
• Podem reduzir a eficiência: em certos casos, podem levar a acompanhamento excessivo por membros individuais. As atualizações criam interrupções e negligenciam outros aspetos da produtividade.
• Podem incentivar a microgestão: se forem utilizados incorretamente, podem tornar-se ferramentas de controlo de todos os pormenores pelos gestores. Isso pode reduzir a autonomia e a motivação e prejudicar as decisões.

Embora estas limitações sejam possíveis e não consequências inevitáveis da utilização, é essencial ponderar os riscos face aos benefícios de acompanhar projetos através desta métrica. O melhor é discuti-los com a equipa e adaptar a utilização ao contexto específico.

Aqui utiliza-se um gráfico de barras em vez de linhas. O tamanho de cada barra representa o trabalho total restante no início de cada Sprint. A velocidade da equipa é subtraída do topo, enquanto as alterações de âmbito modificam a base da barra.

Para maior exatidão, podemos também considerar a taxa de alteração do trabalho total. Mas devemos utilizar este modelo com cuidado: a taxa pode ser elevada no início do projeto e diminuir depois; esse padrão deve ser verificado, não presumido.

Com que frequência deve ser atualizado um gráfico de burndown num projeto Scrum?

O gráfico de burndown de um projeto Scrum deve ser atualizado diariamente. Assim, a equipa acompanha o progresso e identifica problemas ou bloqueios em tempo real. Isso permite decidir mais depressa e tomar medidas corretivas quando necessário, mantendo o projeto no rumo certo. As atualizações diárias também fornecem dados valiosos para analisar o desempenho da equipa e prever com exatidão as datas de conclusão.

Como ajuda um gráfico de burndown a gerir projetos Scrum?

O gráfico de burndown ajuda a gerir projetos Scrum ao representar visualmente o progresso do trabalho durante um Sprint. Acompanha o trabalho restante em função do tempo, permitindo ver se a equipa está no rumo certo para cumprir os objetivos. Ajuda a identificar problemas ou estrangulamentos e permite tomar as medidas necessárias para cumprir o calendário. As estatísticas de Sprints anteriores podem servir para prever o progresso futuro e tomar decisões informadas.

Que informações transmite um gráfico de burndown sobre o progresso do projeto?

O gráfico de burndown transmite informações valiosas sobre o progresso de um projeto Scrum de desenvolvimento de software. Mostra o trabalho restante em função do tempo e se a equipa está no rumo certo para concluir dentro do prazo. A inclinação da linha indica o ritmo de conclusão do trabalho, e os desvios do progresso esperado podem ser identificados e tratados prontamente. Além disso, ajuda as partes interessadas e os membros da equipa a identificar tendências, decidir de forma informada e ajustar estratégias quando necessário.

Existem ferramentas ou software específicos para criar gráficos de burndown em Scrum?

Sim, existem ferramentas e software específicos para criar gráficos de burndown em Scrum no desenvolvimento de software. Ferramentas como Jira e Microsoft Azure DevOps disponibilizam relatórios de burndown; um fluxo Trello pode utilizar um Power-Up ou integração adequado. Representam visualmente o trabalho restante ao longo do tempo, permitindo acompanhar o progresso e identificar desvios do plano. As estatísticas mostram que estas ferramentas melhoram a colaboração, facilitam a transparência e ajudam a tomar decisões baseadas em dados para entregar projetos com sucesso.

Existem boas práticas ou dicas para interpretar e utilizar eficazmente os dados de um gráfico de burndown em Scrum?

Sim, existem várias boas práticas. Primeiro, é importante atualizar o gráfico diariamente para acompanhar o progresso com exatidão. Além disso, a equipa deve inspecionar a tendência juntamente com o trabalho real e o Sprint Goal. Uma descida acentuada pode simplesmente refletir o registo conjunto de trabalho concluído, enquanto as alterações de âmbito devem ser visíveis e discutidas. Comparar o burndown real com o planeado ajuda ainda a identificar melhorias e ajustes para futuros Sprints. Estudos mostraram que as equipas que utilizam eficazmente estes gráficos alcançam maior produtividade e previsibilidade na entrega de projetos de software (fonte: Agile Alliance).

Recapitulação do gráfico de burndown em Scrum

Ao rever a essência do gráfico de burndown Scrum, torna-se evidente que esta ferramenta poderosa reúne vários elementos fundamentais da gestão ágil de projetos. O burndown do Sprint, um gráfico da linha de trabalho em função do tempo durante um Sprint, desempenha um papel essencial no acompanhamento dos Sprint Goals.

As estimativas de trabalho e os problemas contribuem para a forma do gráfico de burndown Scrum. O número de unidades estimadas para conclusão constitui a base desta representação visual, criando uma imagem dinâmica do progresso. O gestor de projetos, os Scrum Masters e os Product Owners são intervenientes importantes na utilização desta ferramenta para acompanhar o estado do projeto e reduzir possíveis riscos.

O Scrum Master, como facilitador, assegura que o gráfico de burndown cumpre o seu propósito num Sprint ágil. O Product Owner, representando o negócio e os clientes, acompanha-o para alinhar o projeto com os objetivos globais da empresa. O gráfico torna-se um modelo de transparência, permitindo comunicação e colaboração eficientes entre os membros da equipa.

Nas empresas que utilizam metodologias ágeis, o gráfico de burndown torna-se uma página valiosa da documentação de gestão de projetos. Abrange épicos e calendários, oferecendo uma visão completa da trajetória do projeto. Ajuda a acompanhar o progresso e destaca a diferença entre a conclusão estimada e a real, promovendo melhoria contínua.

Integrado em ferramentas de gestão de projetos como Jira e Trello, o gráfico alinha-se com o fluxo de trabalho e simplifica o acompanhamento. Torna-se um instrumento dinâmico, refletindo a soma dos esforços e a natureza evolutiva do projeto.

Em conclusão, o gráfico de burndown Scrum é uma referência de eficiência, representando visualmente o progresso, as estimativas e os possíveis riscos. Serve de modelo de colaboração e transparência, apoiando os negócios e produtos nas suas iniciativas ágeis. Quer o projeto envolva artigos, produtos de negócio ou iniciativas empresariais, o gráfico de burndown continua a ser um recurso indispensável para orientar as equipas até à conclusão bem-sucedida.