Conheça o processo Criar o Backlog do Sprint - SBOK SCRUMstudy

Conheça o Processo Criar o Backlog do Sprint no Gerenciamento Ágil de Projetos

Conheça o Processo Criar o Backlog do Sprint no Gerenciamento Ágil de Projetos

Neste artigo, apresentaremos o processo Criar o Backlog do Sprint, da fase “Planejar e Estimar” do Scrum de acordo com o Scrum Body of Knowledge, da SCRUMstudy. A fase “Planejar e Estimar” é composta por 5 processos.

Black Week Site Campus

Propósito do Processo Criar o Backlog da Sprint

Já conhecemos ao longo desta série de artigos o backlog do produto, que deve ser gerido pelo Dono do Produto e refinado ao longo do projeto. Este backlog vai ser criado no começo do projeto, na fase Iniciar. Logo após sua criação, iremos partir para o planejamento das entregas, ou releases, que serão encadeadas em Sprints e distribuídos em uma linha do tempo. Esta previsão, esta estimativa das entregas, pode ser feita pelo Dono do Produto em conjunto com a equipe de desenvolvimento. Contudo, é apenas uma estimativa. Quando é chegada a hora de iniciar cada Sprint, então a equipe de desenvolvimento e o Time Scrum como um todo se reúnem, mas apenas a equipe de desenvolvimento irá determinar o que pode ou não realizar na Sprint em planejamento.

O planejamento da Sprint toma então forma com a criação das tarefas e suas respectivas estimativas. Tendo estimado as tarefas e comprometido as mesmas dentro da equipe, cada uma com um dono, a equipe de desenvolvimento monta o backlog da Sprint – aquilo que será efetivamente desenvolvido naquela Sprint.

Este é o processo que estamos vendo agora, o processo que encerra a fase Planejar e Estimar. Criar o backlog da Sprint é uma responsabilidade da equipe de desenvolvimento com apoio do Dono do Produto e o Scrum Master. Este backlog não será uma criação nova, mas sim uma abstração do backlog do produto. Ele representa uma porção do backlog do produto que será então executada, construída, pela equipe de desenvolvimento.

Vamos conhecer o processo?

Conheça o Processo Criar o Backlog do Sprint no Gerenciamento Ágil de Projetos

Entradas

Time Central do Scrum*

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Entrada obrigatória neste processo!

Lista de Tarefas de Esforço Estimado*

Já descrito no artigo sobre o processo Estimar as Tarefas, clique aqui para conferir.

Entrada obrigatória neste processo!

Lista de Tarefas*

Já descrito no artigo sobre o processo Estimar as Tarefas, clique aqui para conferir.

Entrada obrigatória neste processo!

Duração do Sprint*

Já descrito no artigo sobre o processo Conduzir o Planejamento da Release, clique aqui para conferir.

Entrada obrigatória neste processo!

Velocidade do Sprint Anterior

Diferente da duração da Sprint, que pode variar de 1 até 6 semanas, a velocidade é a capacidade produtiva do time de desenvolvimento enquanto em uma Sprint. Para saber a velocidade da Sprint, é preciso saber sua duração – entrada obrigatória neste processo – e a quantidade de trabalho realizada. A quantidade de trabalho pode ser medida em pontos. Quando estimando um épico, história de usuário ou tarefa, a equipe geralmente cria parâmetros para fazer estas estimativas na forma de pontos. Assim, é possível determinar o número de pontos (podem ser convertidos em horas de trabalho, por exemplo) que a equipe é capaz de entregar em uma única Sprint.

Desta forma, se a equipe entregou 100 pontos na Sprint anterior, por exemplo, esta deve ser a velocidade considerada. Com esta velocidade é possível criar o backlog da próxima Sprint. A primeira Sprint terá uma velocidade estimada, enquanto as seguintes poderão contar com a velocidade real da equipe. Esta velocidade determinará a quantidade de trabalho que a equipe poderá realizar na Sprint em planejamento.

Dependências

Já descrito no artigo sobre o processo Criar as Tarefas, clique aqui para conferir.

Calendário do Time

O calendário aqui refere-se a disponibilidade do time de forma geral: férias programadas, afastamentos, eventos importantes, feriados e assim por diante. É importante considerar o calendário do time quando criando o backlog da Sprint pois se o time tem uma velocidade de 100 pontos, por exemplo, e é composto por 10 pessoas, podemos estimar que cada pessoa produz 10 pontos dentro de uma Sprint. Assim, com uma pessoa a menos o time não poderá ter um backlog maior do que 90 pontos.

Ferramentas

Reuniões de Planejamento do Sprint*

Já descrito no artigo sobre o processo Criar as Tarefas, clique aqui para conferir.

Vamos convencionar aqui que a mesma reunião na qual foi planejada a Sprint e as tarefas será também criado o backlog da Sprint, pois não há a necessidade de ainda outra reunião. Isso porque a reunião de planejamento de Sprint é um evento time-boxed (com tempo limitado) que deve ser respeitado para que de fato o time esteja utilizando Scrum.

Ferramenta obrigatória neste processo!

Ferramentas de Acompanhamento do Sprint

De acordo com o SBOK:

É importante controlar o andamento de um Sprint, e saber o que falta para o Time Scrum completar as tarefas do Backlog do Sprint. Uma variedade de ferramentas podem ser usadas para monitorar o trabalho em um Sprint, mas uma das mais comuns é o Scrumboard, também conhecido como quadro de tarefas ou gráfico de progresso. O Scrumboard é dividido nas seguintes seções: para Fazer (muitas vezes referido como o Trabalho Não Iniciado), Trabalho Em Andamento, e o Trabalho Concluído. Post-its representam cada tarefa, ou Histórias de Usuário são colocadas na categoria apropriada para refletir o status do trabalho. Sendo movidas para a próxima categoria de acordo com o progresso do trabalho.

Veja uma imagem de um Scrumboard:

Conheça o Processo Criar o Backlog do Sprint no Gerenciamento Ágil de Projetos

Medidas de Acompanhamento do Sprint

Medidas utilizadas em projetos Scrum incluem: a velocidade, o valor do negócio entregue, e o número de histórias.

Velocidade—representa o número de Histórias de Usuário, ou número de funcionalidades entregues em um único Sprint.

Valor do negócio entregue—mede o valor das Histórias de Usuário entregues, a partir da perspectiva do negócio.

Número de histórias —refere-se a quantidade de Histórias de Usuário que são entregues como parte de um único Sprint. Pode ser expresso em termos de contagem simples ou contagem ponderada

Saídas

Backlog do Sprint*

O backlog da Sprint é como o backlog do produto, mas direcionado para a Sprint em pauta. Sua construção é de responsabilidade da equipe de desenvolvimento em parceria com o Dono do Produto e o Scrum Master. Só a equipe de desenvolvimento pode determinar quanto trabalho pode realizar ao longo de uma Sprint e só a equipe pode criar as tarefas e estimar sua duração. Este backlog será então executado durante a Sprint. Caso as histórias de usuário e tarefas não possam ser construídas ao longo de uma Sprint, elas retornam para o backlog do produto até um novo planejamento de Sprint.

Os produtos criados, ou incrementos de produtos, serão revisados pelo Dono do Produto ao término da Sprint e podem ser inclusive avaliadas pelo cliente. Se atenderem os critérios de pronto e os critérios de aceitação previamente definidos, poderão ser liberados e entregues. Uma vez entregues e aceitas, deixarão o backlog do produto e não voltarão ao backlog de Sprints futuras.

Ainda, de acordo com o SBOK:

Uma vez que o Backlog do Sprint seja finalizado e comprometido pelo Time Scrum, as Histórias de Usuário novas não devem ser adicionadas; no entanto, as tarefas das Histórias de Usuário comprometidas que podem ter sido perdidas ou negligenciadas, podem precisar serem adicionadas. Se novos requisitos surgirem durante o Sprint, eles serão adicionados no Backlog Priorizado do Produto geral e incluídos em um futuro Sprint.

Saída obrigatória neste processo!

Gráfico de Burndown do Sprint*

Pesquisando na internet, encontrei um modelo simples no site http://www.scrum-institute.org de Gráfico de Burndown do Sprint:

Avaliando este modelo simples, percebemos que no eixe vertical temos o total de pontos estimados para a Sprint em pauta. Isso significa que naquela Sprint, a equipe de desenvolvimento estima que pode desenvolver 80 pontos. Estes 80 pontos vão ser resultado da análise de Sprints anteriores e também da experiência do time, assim como disponibilidade de profissionais para a Sprint em pauta. Com o passar do tempo e o andamento do trabalho, os pontos vão sendo realizados ou não.

Podemos ver no eixo horizontal o total de dias determinado para aquela Sprint. Em vermelho, podemos ver o trabalho ideal e em cinza vemos o que foi efetivamente realizado dia-a-dia. Assim, com este gráfico, podemos estimar quanto tempo o trabalho vai requerer e se precisamos acelerar os esforços ou até se podemos respirar um pouco. Interessante, não? Este gráfico é uma forma de controlar o trabalho do time e oferecer visibilidade, transparência, para todos envolvidos no projeto.

Saída obrigatória neste processo!

Clique aqui e veja uma aula sobre os Princípios do Scrum do nosso curso Formação SCRUMStudy preparatório para as certificações SDC, SMC & SPOC – faça esta aula gratuitamente e aprenda mais!


#
Compartilhe!
Fale com o Site Campus

Tags: , , , ,