Muitas vezes é difícil delimitar prioridades, principalmente quando tudo parece ser indispensável. No Scrum, ao definir uma Sprint Backlog, como você classifica as prioridades? Os erros de produção, a evolução do software ou as refatorações tomam o topo da lista? Existe alguma regra para categorizar os itens do Backlog? Bom, vamos discutir sobre isso!
O que parece ser mais importante? A correção do erro que ocorre ao cadastrar um novo fornecedor ou a implementação da nova funcionalidade que permite a validação do XML de Notas Fiscais? Ambas parecem ser essenciais para o cliente! Embora a decisão seja complicada, existem alguns parâmetros que talvez possam ser úteis para simplificá-la.

Imagem via Shutterstock
Primeiro, é necessário refletir sobre o objetivo da Sprint, no qual muitas vezes passa despercebido pela equipe. Para isso, reflita sobre a pergunta: o objetivo é estabilizar o software (corrigindo os bugs), fornecer novos recursos (lançamento de novas funcionalidades) ou aplicar manutenções para contemplar requisitos não-funcionais, como segurança, usabilidade e desempenho? A partir do momento em que o objetivo é encontrado, priorizar os itens se torna mais fácil.
Porém, em algumas situações, o objetivo abrange, simultaneamente, as correções e as evoluções. Imagine que foi acordada a implementação de uma nova funcionalidade de controle de movimentações bancárias para o departamento financeiro, mas, ao mesmo tempo, há um erro no módulo contábil relacionado ao cálculo de impostos tributários, prejudicando a produtividade do setor. Para encontrar a prioridade mais crítica, uma das alternativas é utilizar a política do impedimento: qual dos dois itens impedirá a utilidade do software? Bom, o controle bancário é importante, mas é provável que o departamento contábil esteja praticamente paralisado enquanto o erro no cálculo de impostos não é corrigido, e isso é ruim! A prioridade, neste cenário, se refere à continuidade do negócio do cliente, portanto, o erro se destaca e deve ser corrigido. Por outro lado, caso fosse possível contornar o erro no módulo contábil (o que tecnicamente chamamos de workaround), o controle bancário para o financeiro poderia receber uma atenção maior.
Em segundo lugar, não devemos nos esquecer de um dos principais paradigmas do Desenvolvimento Ágil: entregar valor. Se você possui uma lista de itens que devem ser priorizados, discuta com a equipe sobre quais deles irão resultar em um incremento com maior valor para o cliente. Observar os itens com a perspectiva do usuário ao invés de uma perspectiva técnica pode ajudar a definir as prioridades. Para isso, levante a questão: “O que o cliente espera do próximo incremento?” – certamente, funcionalidades úteis para o negócio! Aproveitando o ensejo, lembre-se de que comentei brevemente sobre Engenharia de Valor no artigo sobre o Agile 2014.
É importante mencionar que o conceito de valor do incremento pode mudar conforme o tempo, logo, nem sempre o que foi decidido na Sprint anterior será adequado para a Sprint atual. Isso significa que você não deve utilizar os mesmos parâmetros de prioridade repetidamente. O valor do incremento deve ser “recalculado” à medida que novas regras, tecnologias e fatores externos surgem na realidade do projeto.A questão do valor nos leva à definição de produto potencialmente utilizável. A qualidade do que será entregue para o cliente depende justamente dessa categorização de prioridades. De nada adianta, por exemplo, lançar uma nova funcionalidade e, dias depois, receber uma série de reclamações devido à uma falha no código. Além de ferir a utilidade, essa funcionalidade se tornará mais um item de correção para a próxima Sprint, aumentando novamente a dificuldade em priorizar os itens.
Vale realçar que, naturalmente, se novos bugs forem introduzidos no software, ele não será mais potencialmente utilizável. O advérbio “potencialmente”, neste contexto, indica que o sistema de informação deve atuar como recurso fundamental para as operações do cliente.
Em terceiro lugar, em caso de dúvidas, a delimitação de prioridades pode ser discutida com o próprio cliente, ou, na sua ausência, com o Product Owner. O cliente conhece bem os critérios de sobrevivência do seu próprio negócio e pode fornecer informações relevantes para a elaboração do Sprint Backlog. Talvez um erro de produção pode não demandar tanta atenção quanto uma refatoração que irá melhorar o desempenho de uma funcionalidade já existente. O cliente, que convive diariamente com o andamento do negócio e com a utilização do software, é a melhor pessoa para fornecer essa orientação.
Para fechar o artigo, vou deixar uma frase que ouvi no seriado “The Blacklist”:
“We don’t need to work harder. We just need to work smarter.”
(Não precisamos trabalhar com mais esforço. Só Precisamos trabalhar com mais inteligência.)
Aplique essa frase durante a definição de Sprints. Não é preciso ficar até altas horas concluindo tarefas que, no final das contas, não irão gerar um valor considerável para o cliente. Em vez disso, identifique itens potenciais para o próximo incremento. Se estes itens forem apropriadamente avaliados, não haverá insatisfação do cliente, como também não haverá desmotivação da equipe.
Abraços!
Obs: The Blacklist é uma grande série. Vale a pena assistir!
Publicado originalmente em Blog Subrotina
6 Comentários
Parabéns pelo artigo André! Me fez parar para pensar em como estamos levando os Sprints na nossa empresa
Opa, obrigado pelo comentário, Diego! Espero que lhe ajude no trabalho!
Grande abraço!
Meu caro, ótimo seu artigo, essa experiência repassada e compartilhada contribui muito para quem quer seguir ou se deparar em projetos que utilizarão scrum, parabéns!
Olá, Lielson!
Obrigado pelo feedback sobre o artigo! A intenção é essa mesmo: compartilhar o conhecimento para um benefício coletivo!
Abraços!
parabéns pelo artigo. e a frasedo the blacklist citada realmente é um ótimo inicio para reflexão.
Olá, Daiane!
Sim, enquanto fazia o esboço do artigo, essa frase do seriado me veio imediatamente à mente. Realmente é algo para refletir.
Obrigado!