Medindo o progresso de projetos Scrum com Burndown chart

porLuis Augusto Moretto

Medindo o progresso de projetos Scrum com Burndown chart

monitoriacontroleOs métodos e as práticas ágeis são extremamente efetivos e eficazes. Produzem resultados de qualidade em curto espaço de tempo comparado ao modelo em cascata e outras abordagens tradicionais de desenvolvimento de software.

Estes resultados são sempre orientados a geração de valor para o cliente ao final de cada Sprint do projeto. Ou seja a expectativa é software funcionando e agregando valor na organização cliente.

Para alcançar estes resultados, é primordial medir e controlar o progresso do Sprint. Alem da questão do gerenciamento, existe uma complexidade inerente que é a introdução de novos requisitos frequentemente a cada Sprint (na engenharia civil ninguém pede para mover o prédio 1cm para o lado após a construção da fundação…Entretanto falando de software a evolução é contínua).

Sendo assim surge um problema para atender ao custo prazo e qualidade associados ao Sprint:

 

“Como monitorar  e controlar o progresso dos Sprints de projetos ágeis com a metodologia Scrum de forma transparente?”




Na engenharia de software clássica, cada projeto é composto de milestones ou marcos. Estes marcos servem para mensurar o progresso do projeto, fazendo um comparativo do que foi planejado x o realizado em termos de desenvolvimento.

Uma métrica para estimar o esforço são os Use case points.  Lembrando que o esforço é uma métrica dada pela capacidade homem/hora (um pouco Taylorista….) O problema é que para usar está métrica, é necessário ter todos os casos de uso do sistema documentados e detalhados para se analisar a complexidade!

No Scrum, todas as user stories são descritas em uma única sentença simples. Neste contexto como monitorar e controlar os Sprints?

Bom aqui vamos reforçar a importância dos Daily meetings para que você entenda a dinâmica.

É no encontro diário onde a equipe aponta as tarefas que foram realizadas no dia anterior. Sendo assim cada membro da equipe da seu depoimento compartilhando com o time seu progresso. Neste mesmo momento é que o membro seleciona a tarefa em que tem maior aptidão para realizar durante o dia. Com estas informações o Scrum Master atualiza o Burndown chart diariamente.

Abrindo um paralelo, nenhum projeto atrasa 1 mes de uma vez. O atraso é decorrente da somatória de vários dias de atraso. No Scrum se durante a reunião diária for apontado algum impedimento isto será avaliado, assim como o seu risco, de forma que o Sprint seja realizado dentro do prazo. Se for um problema impactante a equipe se reúne e discute as medidas a serem tomadas em conjuntos para dirimir o problema.

Como criar um Burndown Chart

scrum_burndown_ideal

Sprint planejado com 420 horas no burndownchart

O primeiro passo é fazer o planejamento e divisão das tarefas do Sprint. Isso é realizado na reunião de planejamento do Sprint e utiliza uma técnica chamada de planning poker. Cada tarefa deve ter horas associadas.

O tempo de uma tarefa é sempre analisado usando uma sequência Fibonnaci (0,1, 1, 2, 3, 5, 8, 13, 21, 34….). Ou seja uma tarefa deve ter no mínimo 3 horas e no máximo 6, de forma que possa ser realizada em um dia.

Se a tarefa tem mais de 6 horas deve ser analisada e sub-dividida. Caso a tarefa tenha menos de 2 horas esta deve ser vinculada a outra tarefa associada. Este processo é realizado pelo time junto com o Scrum master de forma a compartilhar e gerar colaboração em torno do Sprint.

Uma vez que a divisão de tarefas foi realizada, o gráfico burn-down ideal é traçado. O ideal reflete o progresso assumindo que todas as tarefas serão concluídas dentro o sprint a uma taxa uniforme.

Para saber quantos pontos e a capacidade produtiva de um time para um determinado Sprint, leva-se em consideração as seguintes variáreis:

  • Sprint Duração – 2 semanas (10 dias úteis)
  • Equipe – 7 membros
  • Horas / dia – 6
  • Capacidade Total – 420 horas

Ou seja para um equipe de 7 membros, trabalhando 6 horas por dia no projeto cada, durante 10 dias podemos executar um total de 420 horas de desenvolvimento. Portanto na reunião de planejamento do Sprint esse parâmetro deve ser levado em consideração.

Atualizando o Burndownchart no Daily Meeting

O progresso realizado pela equipe de desenvolvimento deverá sempre estar próximo do progresso planejado. Esta linha se inicia no mesmo ponto de origem do progresso ideal, mas o seu progresso é dado a partir da queima dos story points. A reta será traçada a partir do produto do esforço realizado x tempo gasto. Assim diariamente após a equipe mover as tarefas da coluna de “doing” para “done”, o Scrum Master calcula o total de pontos realizados e atualiza o Burndown chart conforme abaixo.

image

Burndown chart: Realizado x Planejado

Faça o download da planilha no Google Drive

Gostou? curta nossa página e cadastre seu email para receber novidades!