O Backlog nada mais é do que uma planilha na qual são listados todos os requisitos do projeto em ordem decrescente de prioridade (das tarefas mais importantes para as menos).
É indispensável que toda equipe tenha logo no início do projeto um Backlog bem definido para que todos consigam visualizar não apenas o que estará sendo realizado no momento presente, mas também fazer uma projeção de quais as responsabilidades que virão.
É necessário ressaltar que a planilha Backlog não é uma ferramenta de gestão interna do grupo, mas um instrumento responsável por orientar tanto aqueles que estão dentro da produção como os que estão fora dela, que é o caso do cliente com o qual a equipe tem cooperado.
É fundamental que o cliente e o time estejam na mesma página quanto às expectativas e execução do projeto para que possam juntos elaborar soluções que sejam eficazes e superem o esperado.
Lembrando que, como todos os elementos do Scrum, o Backlog também se adapta a mudanças. Uma coisa é certa: haverá mudanças nos requisitos conforme as Sprints forem sendo realizadas!
Adaptando
Pense em uma longa viagem de carro de cerca de 10h de duração. Digamos que o indivíduo iniciou sua viagem às 12h e decidiu usar roupas mais leves devido ao calor do horário. Porém, com o passar do tempo o Sol foi se pondo e a temperatura foi esfriando, passando a fazer mais sentido para o viajante o uso de roupas mais pesadas para se esquentar.
Assim é com o decorrer do projeto. Conforme ele se desenrola, alguns pontos antes estabelecidos vão perdendo o sentido, fazendo-se necessárias mudanças que fazem mais sentido na situação.
Além do Backlog geral do produto, outra planilha essencial para a gestão de tarefas e responsabilidades é a planilha de Backlog da Sprint. Ela possui a mesma essência da planilha geral, mas com algumas identificações e especificações a mais para que que haja a execução por completo das tarefas designadas.
Nessa planilha, todos os requisitos são descritos por meio do que chamamos de User Stories. Essas tem a função de explicar o requisito no formato de um desejo feito por alguém sem o conhecimento técnico, mas que expõe qual a expectativa do usuário em relação ao produto que ele irá dispor futuramente.
O formato padrão de uma US bem formulada precisa ter as seguinte informações:
| Individuo que expressa desejo | Ação/Elemento que desejo interagir | Porquê/Motivo da funcionalidade, o que ela irá agregar à experiência |
|---|---|---|
| Eu, como usuário aluno da plataforma, | desejo uma página de contato com os professores, | para que possa tirar minhas dúvidas quanto ao conteúdo lecionado |
Para que uma tarefa esteja apta para ser adicionada ao Backlog da Sprint, ela precisará passar antes pelo crivo do Definition of Ready (DoR), a Definição de Pronto, a qual possui o papel de qualificar se uma certa tarefa já poderá ser produzida ou se ainda há alguma pendência que impossibilita sua execução no momento.
Outro quesito que deve ser expresso no Backlog da Sprint é a Estimativa de Esforço das tarefas.
Nesse campo será exposto qual é, segundo a perspectiva do grupo, o tempo necessário para realização da determinada tarefa em função da dificuldade que ela possui para ser concretizada.
Em seguida, são colocados o respectivo requisito do Backlog do Produto que define aquela US e o seu critério de aceitação, sendo esse último uma das partes principais dessa planilha. Ele é o responsável por indicar o que chamamos de Definition of Done (DoD), ou Definição de Feito. Com base nesse critério, o grupo avalia se o requisito pode ser classificado como concluído ou não.
