Digamos que você tenha um quadro kanban como o seguinte:

Então, no meio do seu sprint, o P.O. descobre que as features D e E foram lançadas por um concorrente e que vocês estão perdendo usuários por isso. Pensando nisso, a P.O. decide despriorizar a história C. Isso seria apenas um exemplo de como um card pode ser despriorizado no meio do seu desenvolvimento. Mas, e agora, o que acontece com a história C?

Para responder isso, deixe-me fazer um paralelo com uma companhia de perfumes a base de álcool.

Na coluna de backlog, a companhia tem a garrafa pronta mas sem fluído algum. Quando a garrafa começa a ser enchida, o card é passado para “in progress”. Após a garrafa estar cheia, ela é lacrada e o card vai para “done”.

O que acontece então se outro perfume tem sua prioridade elevada a um nível maior do que o que está sendo abastecido? Bom, como sabemos, fluídos com base em álcool são voláteis e, com o tempo, evamporam totalmente, sendo necessário que se reabasteça o recipiente.

O mesmo acontece com uma história e seu código. Com o tempo, o código que compõe tal história se torna obsoleto e desnecessário, perdendo o valor que tinha outrora. Neste caso, o que fazer com a história despriorizada depende dos seguintes pontos:

• Quanto tempo a história C continuará no mesmo estágio?
  • Se a história permanece muito tempo no mesmo estágio, alguma parte do trabalho já feito pode se tornar desnecessário, portanto, você poderia apenas removê-la da coluna e colocá-la de volta ao backlog, já que algum refinamento pode ser necessário para que essa história seja desenvolvida novamente.
  • Se a história vai ficar por um curto período de tempo em tal coluna, você pode optar por deixá-la lá e, quando sua hora chegar, pode continuar aproveitando o que já havia sido desenvolvido.
• Qual o valor que a história C vai gerar quando pronta?
  Digamos que o retorno gerado pelo desenvolvimento de tal feature seja pequeno. Será que vale a pena pausar seu desenvolvimento e ter o risco de investir ainda mais dinheiro no seu desenvolvimento em outro momento? O retorno gerado será maior do que o tempo total de desenvolvimento gasto?

Para que isso seja verdade, o seguinte precisa acontecer (observado na imagem abaixo):

• $ gasto com o desenvolvimento inicial + $ gasto com o resto do desenvolvimento < retorno da história C
  • A quantia gasta com o resto do desenvolvimento aumentará com o tempo, já que o desenvolvimento feito anteriormente vai perdendo valor.
• Caso o retorno seja menor do que o gasto, é melhor ignorar a funcionalidade. No entanto estes cálculos não são tão simples como parecem… Você precisa levar em conta riscos, aumento na receita, aumento no número de usuários, etc… Então tenha cuidado com essa ação.

Portanto, baseado no que já foi dito, você pode ter as seguintes ações a respeito do card C:

• Mantenha-o na coluna “in progress” e recomece o trabalho quando sua prioridade for retomada
  Essa pausa será rápida e não afetará o desenvolvimento da feature. Neste caso é importante deixar visível de alguma forma no quadro que essa história está “bloqueada” por motivos de priorização.

• Ponha-o na coluna de backlog novamente, e recomece quando necessário
  A pausa será longa e o card precisará de um novo refinamento.

• Termine-o primeiro, antes de começar outra história
  O card está quase pronto e, caso você pare seu desenvolvimento, quando pronto, seu valor será menor do que o gasto no seu desenvolvimento.

• Cancele o seu desenvolvimento
  A história está muito longe de ser terminada, e seu valor final é muito pequeno para pagar o tempo que ela ficará pausada.

É importante também notar que isso NÃO deve ser algo comum em seu processo. Se coisas como essa estão acontecendo frequentemente, você pode precisar melhorar suas priorizações!

O que acha do que foi discutido aqui? Deixe seus comentários abaixo! 🙂