Burndown de Versão
Examinando o relatório de burndown de versão, você pode entender rapidamente como sua equipe apresentou os itens da lista de pendências e controlar a quantidade de trabalho a equipe deve executar para concluir uma versão do produto.
Dica
Esse relatório requer que a coleção do projeto da equipe, que contém o projeto da equipe, tenha sido provisionada com o SQL Server Reporting Services.Esse relatório não está disponível se .png "Report"){kind=icon}
relatórios não aparece quando você abrir Team Explorer e expanda o nó do seu projeto de equipe.
Permissões necessárias
Para exibir o relatório, você deve ser atribuído ou pertencer a um grupo que recebeu o navegador função no Reporting Services. Para obter mais informações, consulte Conceder permissões para exibir ou criar relatórios no TFS.
Dados no relatório
Como mostra a ilustração a seguir, um gráfico de burndown de versão mostra quanto trabalho resta no início de cada sprint em uma versão. A origem dos dados brutos é a lista de pendências de produto. Cada sprint atribuído ao projeto de equipe ou equipe aparece ao longo do eixo horizontal. O eixo vertical indica a soma de todo o esforço de todos os itens da lista de pendências ativa no início de cada sprint. Conforme a equipe atualiza o estado dos itens da lista de pendências para Concluído, o esforço restante diminui. A quantidade de esforço estimado no eixo vertical é qualquer unidade que sua equipe de scrum tenha decidido usar (por exemplo, pontos de história, tamanho ou horas).
.png "Release burndown chart")
Você pode filtrar o relatório selecionando o caminho de liberação ou área.
Atividades necessárias para acompanhar o burndown de versão
Para o gráfico de burndown ser útil e preciso, sua equipe deve executar as seguintes atividades para acompanhar itens de trabalho:
Especifique o número de versões para acompanhar e definir as datas de início e término para cada sprint.
Definir bugs e itens de lista de pendências de produto e atribui cada um sprint ou iteração. (Iteração campo). Certifique-se de que todos os itens da lista de pendências são atribuídos ao caminho de área ou subárea de sua equipe.
No início de uma versão, estimar o esforço para cada item da lista de pendências de produto e cada um bug que sua equipe trabalhará em.
Durante o sprint ou ao final de cada sprint, para cada item da lista de pendências de produto e cada bug que a equipe concluiu, alterar o estado para feito.
Interpretando o relatório
Você pode revisar o relatório para determinar o progresso que sua equipe fez em uma versão e responder às seguintes perguntas:
Quanto trabalho ainda resta na versão?
Rapidez sua equipe está trabalhando através de lista de pendências de produto?
Consulte também
Conceitos
Adicionar e modificar área e caminhos de iteração