Em alguns times que estão começando a usar Scrum é comum perceber que o refinamento do backlog acontece durante a planning, ou seja, todas as histórias da sprint são explicadas, entendidas, iteradas, estimadas e fatiadas durante a cerimônia.
Isso pode trazer alguns problemas.
Planning muito longa ou rasa: Deixar todo o entendimento das novas histórias para uma única reunião pode estender muito o tempo da reunião, caso:
- Muitas dúvidas precisem ser tiradas.
- Critérios de aceitação serem combinados.
- Histórias grandes precisem ser fatiadas.
- O time ainda não conheça o real valor de negócio para cada história.
Em um cenário pior, o tempo da planning não é comprometido, mas sua qualidade sim, e os itens acima são feitos de forma muito rasa ou completamente ignorados.
Algumas histórias travarem com indefinições: Como uma consequência de uma planning rasa, o time pode sofrer com isso durante a sprint. Descobrindo grandes buracos na definição das histórias, que caso dependam de uma decisão externa travam o fluxo de desenvolvimento de uma forma que comprometa o objetivo da sprint.
Uma pré-seleção ser feita sem a visão de ROI: Para ter uma noção clara de ROI (Return on Investment) para cada história é preciso saber o quanto estamos investindo nela. É comum que o valor do investimento seja o esforço estimado pelo time, mas se o time não conhece ainda as próximas histórias no backlog significa que o PO precisou fazer uma pré-seleção do backlog sem olhar o ROI, e trazer esses itens para a planning. Com isso temos poucas garantias de que não teria algum outro item no backlog com o ROI mais alto do que essas que o PO trouxe.
Backlog desestruturado: Outro risco seria não ter um backlog bem estruturado, com as histórias no topo sendo fatias finas, conforme a visão do horizonte para o backlog. Na pré-seleção do PO pode acontecer que uma das histórias tenha um esforço enorme, incompatível com o tamanho da sprint por exemplo.
Refinamento do Backlog
Uma prática que muitos times utilizam como solução é fazer um refinamento durante a sprint sempre que necessário. Ela não é uma regra oficial no scrum guide, mas é uma reunião que ajuda a ter uma planning eficiente e um backlog bem mantido e priorizado.
A frequência desta reunião não precisa estar casada com o ciclo do scrum, e idealmente é feita sob demanda para que o time não caia no caso de refinar itens a menos e nem itens a mais. O número ideal de itens refinados certamente vai depender do seu contexto e a experimentação deve prevalecer.
Se existem algumas dessas disfunções no seu time, você acha que vale experimentar fazer um refinamento separado da planning?