Dando continuidade a série FAQ Scrum, hoje falaremos de Histórias e Product Backlog. No post Aprendendo os termos Scrum – Glossário, nós já aprendemos a definição desses dois termos, mas não nos custa relembrar:
“Histórias – São itens do Product Backlog que representam parte do produto a ser implementado. As Histórias devem conter uma descrição detalhada do que deve ser implementado.”
“Product Backlog – Lista de itens, ou Histórias, que devem ser implementados para a criação do produto desejado ou desenvolvimento do projeto.”
Ok, mas como funciona essa coisa de História e Product Backlog na realidade?
Vamos começar pelas Histórias:
Como dito acima, elas representam uma parte do produto a ser implementado, uma necessidade que foi levantada e que o Product Owner (PO)* do projeto deseja que seja implementada. Geralmente, as Histórias são levantadas durante uma reunião entre equipe, Scrum Master e PO e não existe nenhum nível de granularidade pré-estabelecido para elas. Uma história pode descrever desde a alteração de um label na tela até a criação de uma nova funcionalidade do sistema. O importante é verificar se o que deve ser implementado ao realizar aquela história foi realmente compreendido pela equipe.
É possível que em algumas Histórias a equipe sinta a necessidade de dividir o trabalho previsto para que se tenha maior controle do que deve ser feito. Não há problemas. Durante a reunião, a equipe pode e deve sugerir ao PO que determinada história seja dividida em várias ou tenha sua descrição alterada. A função da equipe não é apenas desenvolver a funcionalidade desejada, mas também encontrar, junto com o PO, a melhor maneira de concluir as Histórias levantadas.
Agora vamos falar do Product Backlog:
Todas as Histórias levantadas pelo PO compõem o Product Backlog. Nele estão listadas todas as necessidades já identificadas para o projeto, ordenadas por prioridade pelo PO. É importante ressaltar que o Product Backlog nunca está completo, ele se atualiza a medida que o desenvolvimento do projeto vai avançando e novas necessidades são encontradas. A cada iteração do projeto, é possível que novas Histórias entrem no Product Backlog e novas prioridades sejam estabelecidas.
Antes de iniciar o desenvolvimento, cada história deve ser dividida em tarefas. Cada tarefa deve representar um passo, que deve ser concluído em até 1 dia de trabalho, para finalizar a funcionalidade contemplada naquela história. Um ponto importante a ser considerado ao estabelecer as tarefas de uma história é que, idealmente, toda a equipe deve trabalhar no desenvolvimento dela. Dessa forma, todos podem compartilhar o conhecimento relacionado àquela história e a produtividade da equipe também aumenta.
E na sua equipe? Os conceitos de História e Product Backlog já estão bem compreendidos? Aproveite para assistir ao tutorial sobre Product Backlog da Universidade Scrum.
* Para saber mais sobre os papéis do Scrum, veja o post Quais são os papéis do Scrum? – FAQ Scrum
