Os items no backlog têm um título técnico e pouca descrição ↩
Se você tratar desenvolvedores como anotadores de pedidos, o tempo de entrega pode aumentar, a qualidade diminuir e a inovação ser desencorajada. A criatividade dos times é prejudicada se disserem exatamente o que deve ser feito.
O que pode ser feito?
Explique os desafios do negócio para os times. Escreva as histórias para garantir que qualquer pessoa que leia o backlog possa entender o problema. Melhore a comunicação entre cliente e time de desenvolvimento e reduza a necessidade de tradução.
O time não é um time ↩
Um dos benefícios de construir um time multifuncional alinhado ao produto é dar ao time todas as ferramentas necessárias para entregar valor e mantê-lo focado nos mesmos objetivos. Quando o pessoal não está
trabalhando, pensando e celebrando como um time, é porque eles têm objetivos diferentes e competem entre si.
O que pode ser feito? ↩
Reduza a quantidade de trabalho em progresso, filtrando propriamente todos as requisições em um único backlog ordenado. Um bom P.O é a chave para isso. Trabalhe para construir e crescer o time de dentro para fora. É um problema humano. Um Scrum Master será de extrema necessidade pra executar essa tarefa.
O time não sabe se está no caminho certo para terminar uma grande release ↩
É comum ouvir que quem faz SCRUM não tem datas, mas isso é aceitar achismos. Certamente alguém na empresa vai querer saber o progresso do trabalho. É importante saber se um projeto está atingindo marcos importantes.
O que pode ser feito? ↩
É possível planejar releases se o backlog for refinado regularmente. Foque em construir conhecimento, criar descrições claras e medir a velocidade dos times. Escreva itens no backlog na forma de user stories, então escreva bons critérios de aceite e aplique o modelo INVEST.
Quando um time entende bem os problemas que está tentando resolver, pode entregar soluções em ordem importância.
