Conheça o processo usado para gerenciar os esforços de desenvolvimento de produto em Agile Development 2.0, como criar um produto ou acompanhar um sprint ou versão.

Definir produtos

Um produto pode ser um conjunto de recursos ou funcionalidades oferecidos aos usuários. Cada produto pode ter um proprietário que mantém o pipeline de trabalho, como épicos e histórias, para o produto. Esses itens de trabalho podem ser associados a um tema, que está relacionado a um objetivo de negócios.

Consulte Criar um produto no Agile Development 2.0.

Criar épicos e histórias

Os épicos contêm requisitos de alto nível para seus produtos, que você pode usar para dividir em histórias gerenciáveis. Ao criar épicos e histórias em Agile Development 2.0, você pode associá-los a um produto.

Consulte Criar um épico no Agile Development 2.0 e Criar uma história no Agile Development 2.0.

Criar versões

Algumas organizações têm um intervalo de tempo fixo para disponibilizar seus produtos ao mercado, que é conhecido como versão. Uma versão tem uma data de início e término, durante as quais várias iterações de desenvolvimento são concluídas. Por exemplo, você pode ter programações trimestrais ou semestrais para lançar novos aplicativos ou aprimoramentos em aplicativos existentes.

Depois de criar uma versão em Agile Development 2.0, você pode associar produtos, épicos e histórias a ela. Consulte Criar uma versão no Agile Development 2.0.

Criar backlog personalizado

Um backlog personalizado pode ser criado definindo critérios de filtro. Por exemplo, um backlog personalizado pode ser uma combinação de histórias, defeitos e incidentes, enquanto o outro backlog personalizado pode ser uma combinação de histórias e incidentes. Dessa forma, você pode criar quantos backlogs personalizados forem necessários.

Veja Criar um backlog personalizado no Agile Development 2.0

Criar grupos de atribuição

Crie um grupo de atribuição e adicione membros a ele. Para cada membro do grupo, defina o número de pontos da história que eles podem concluir em um sprint. No nível do grupo, a soma dos pontos da história de todos os membros do grupo determina a capacidade do grupo.

Veja Como criar um grupo de atribuição no Agile Development 2.0

Criar sprints

Um sprint é o intervalo de tempo no qual a equipe de desenvolvimento entrega uma ou mais histórias. Um sprint pode ter qualquer tamanho, mas normalmente leva entre uma e quatro semanas para ser concluído. O scrum master cria o número de sprints necessários para o grupo e esses sprints são usados pelos membros do grupo para concluir o trabalho necessário para uma versão futura. No entanto, todos os sprints de uma versão devem estar dentro das datas de início e término da versão.

Planejar atividades de sprint

Antes do início de um sprint, o grupo e o scrum master decidem quais histórias do backlog podem confirmar para concluir em um sprint. As histórias de um sprint podem ser selecionadas com base na prioridade. O scrum master deve garantir que o esforço (total de pontos da história) necessário para concluir as histórias corresponda à capacidade do grupo.

Ao planejar seus sprints, você pode usar os relatórios de velocidade como orientação para estimar a quantidade de trabalho que o grupo pode concluir no próximo sprint. O painel do Agile 2.0 Team fornece relatório de histórico de velocidade e relatório de velocidade por tipo.

• Histórico de velocidade: obtenha informações sobre a velocidade geral da equipe nos últimos 10 sprints. Analise se a equipe está alcançando uma velocidade estável e previsível e está cumprindo os compromissos.
• Velocidade por tipo: analise como a velocidade da sua equipe muda ao longo do tempo e compare a carga de trabalho estratégica da equipe com a operacional ou outros tipos de carga de trabalho.

Para obter mais informações sobre como planejar seus sprints, consulte Planeje suas atividades de sprint no Agile Development 2.0.

Acompanhar o andamento do sprint

O scrum master gerencia os esforços da equipe de sprint, fornece relatórios de andamento e remove todos os bloqueadores que a equipe encontra. Os membros da equipe atualizam os registros da história e realizam reuniões diárias para discutir seu progresso e comunicar as preocupações ao scrum master e aos proprietários do produto.

Espera-se que a equipe conclua todas as histórias confirmadas para um sprint. O scrum master espera que as histórias sejam totalmente testadas e estejam prontas para lançamento, de acordo com os critérios de aceitação.

O ideal é que as histórias confirmadas e o escopo de um sprint específico não sejam alterados enquanto o sprint estiver em andamento. Agile Development 2.0 fornece a flexibilidade para atualizar conforme necessário e adaptar às mudanças de prioridades. No entanto, as histórias devem ser adicionadas ou removidas de um sprint somente após uma discussão entre o grupo, o scrum master e o product owner.

Você pode usar o painel do Sprint do Agile 2.0 com relatórios como gráficos de burnup e burndown para rastrear o andamento da equipe em um sprint.

Acompanhar o andamento da versão

O responsável pelo produto rastreia o andamento da versão e verifica se a equipe está concluindo histórias no ritmo necessário para atingir o objetivo da versão.

Você pode usar o painel da versão Agile 2.0 com relatórios como burnup, burndown e gráficos de tempo de ciclo para rastrear o andamento da equipe de uma versão.