Scrum
Software II:
SCRUM na prática Ricardo de Sousa Britto rbritto@ufpi.edu.br Construindo Product Backlog
}
}
}
O product backlog é o coração do Scrum.
É basicamente uma lista de requisitos, estórias, que o cliente deseja, descritas utilizando a terminologia do cliente.
A abordagem apresentada aqui considera os seguintes campos para cada estória:
◦
◦
◦
◦
◦
◦
ID
Nome
Importância
Estimativa inicial
Como demonstrar
Notas
ID
Uma
identificação única, apenas um número com auto-incremento.
Serve para evitar a perda de controle sobre as estórias quando nós mudamos seus nomes.
Nome
Um
nome curto e descritivo para a estória. Por exemplo, “Ver o histórico de transações”. Deve ser suficientemente claro
Normalmente de 2 a 10 palavras.
Importância
A
pontuação de importância dessa estória para o product owner.
Por exemplo 10 ou 150.
Mais pontos = mais importante.
Pode ser visto também como nível de prioridade da estória.
Estimativa Inicial
}
}
As estimativas iniciais da equipe sobre quanto tempo é necessário para implementar aquela estória, se comparada a outras estórias.
A unidade é pontos por estória e geralmente corresponde mais ou menos a “relação homem/ dias” ideal.
◦
Após quantos dias vocês apresentarão uma implementação pronta, demonstrável e testada?
◦
3 pessoas levam 4 dias = 12 pontos por estória.
O importante não é ter estimativas absolutamente precisas, mas sim obter estimativas relativas corretas.
Ao invés de dizer que 2 pontos siguinificam 2 dias é preferível saber que 2 pontos representam menos tempo que 4 pontos.
Como Demonstrar
Uma
descrição em alto nível de como a estória será demonstrada na apresentação do sprint.
Isso é uma simples especificação de teste.
Faça isso, então faça aquilo e então isso deverá acontecer.
Se
TDD é utilizado, essa