Equipes ágeis algumas vezes apresentam dificuldades com o planejamento de tarefas puramente técnicas, tais como aquelas relacionadas a dívida técnica. Essas tarefas não tem valor direto para o usuário do sistema, mas precisam ser feitas para entregar o software funcionando. Devemos criar histórias de usuário para lidar com tarefas técnicas e dívida técnica?
No artigo "Como um desenvolvedor… não é uma história de usuário", Bill Wake fala sobre histórias de usuário que ele encontrou que não tinham valor para o cliente. Como exemplo, ele menciona a história de usuário "Como um desenvolvedor, tenho que configurar o Jenkins para que nós tenhamos integração contínua". Bill explica porquê ele acredita que não devemos chamá-las de histórias de usuário:
O meu argumento não é que essas atividades não são boas ou importantes de serem feitas (elas são para a equipe), mas pensar nelas como histórias de usuário enganam a equipe e seus clientes. Escrever algo na forma de uma história de usuário, quando não está relacionado com os usuários do sistema, perde-se o real sentido.
Sua opinião é que nós devemos chamá-las de tarefas ao invés de histórias de usuário. Aplicando o pensamento lean, ele as considera como desperdício.
A partir dessa perspectiva, pensamento lean, muitas dessas tarefas que as equipes fazem podem ser consideradas um tipo de desperdício, mas nós não sabemos como desenvolver software de forma eficiente sem realizá-las. Equipes lean falam sobre esse tipo de desperdício como "Sem-Valor-Agregado, mas necessário": o trabalho que nós fazemos porquê precisamos.
Bill sugere sermos críticos em histórias de usuário onde o papel é descrito como " alguém do desenvolvimento", ao invés de um usuário do software. Tente reformular tais histórias de usuário como um comportamento funcional ou uma característica de qualidade e reformulá-la, se isso não for possível, então considere como uma tarefa. As tarefas estão no quadro para a equipe acompanhar, mas não devem ser colocadas no backlog como histórias de usuário, já que não estão entregando valor.
(...) reconheça que seu time, em algum momento, só terá tarefas. Você decide como acompanhar as atividades internamente, mas não as trate ou acompanhe como progresso direto no sistema que está sendo desenvolvido.
Mattias Marschall fornece uma solução para lidar com tarefas técnicas no backlog, em seu artigo "Como traduzir o valor de negócio de itens que são tecnicamente importantes". Ele começa explicando como ele observa o relacionamento entre histórias de usuário e tarefas técnicas.
...histórias de usuário devem descrever o que um usuário quer que o sistema faça. Tarefas puramente técnicas devem geralmente ser implementadas como parte de uma história de usuário.
Mas e as tarefas técnicas que não são diretamente relacionadas a uma história de usuário específica? Mattias sugere colocá-las no backlog do produto.
Para ser capaz de colocar atividades técnicas no backlog do produto para priorização, basta criar uma história de usuário para cada uma delas. Mas, isso não é trapacear? Não, se você conseguir responder às seguintes perguntas:
1. Quem é o beneficiado com o resultado?
2. Por que essa tarefa é necessária?
Com essa solução, você pode ter todas as tarefas técnicas cobertas por histórias de usuário no backlog, como parte de uma história de usuário para um cliente ou com uma história de usuário especificamente para tarefas técnicas:
Se você é capaz de formular suas tarefas técnicas como uma espécie de história de usuário, os interessados serão capazes de entender a necessidade de priorizá-las, juntamente com outras histórias de usuário.
Bastian Buch explica em seu artigo "Passos efetivos para reduzir a dívida técnica: uma abordagem ágil", em que os desenvolvedores e o product owner podem ter opiniões diferentes sobre tarefas técnicas que estão relacionadas com a dívida técnica:
Os desenvolvedores conhecem a dívida técnica e estão cientes de que é importante encarar esse problema. O product owner muitas vezes não entende a necessidade e os benefícios de reduzir a dívida técnica e não consideram ou permitem que projetos ou histórias técnicas façam parte de seu backlog e do plano de release.
Ele sugere que o product owner deva assumir a responsabilidade de reduzir a dívida técnica. Os membros da equipe devem discutir a dívida técnica com o product owner, além de trabalharem juntos para priorizarem corretamente o product backlog:
A equipe deve lembrar o product owner que ele é parte da equipe: sua dor é a dor da equipe e vice-versa. Ele não é o cliente ou empregador da equipe, mas um especialista no assunto, além de gerente e analista de requisitos do produto provindo de diferentes interessados.
A equipe se responsabiliza, perante o product owner, que o crescimento do produto continuará sendo a parte mais importante, não apenas em um curto espaço de tempo (desempenho), assim como no longo prazo.
Bastiam propõe que nós devemos reunir os problemas técnicos em histórias de usuário, estimar o esforço necessário para resolvê-los e verificar os benefícios que a resolução traria. Ele denomina os benefícios de "pagamento", já que resolver o problema reduz a dívida técnica:
(...) nós criamos histórias marcadas como "itens de dívida técnica" para cada tarefa que nós definimos. Para podermos priorizar esses itens e obtermos as conclusões corretas, nós criamos um gráfico para visualizar como os esforços se relacionam com o pagamento e vice-versa.
Deixar as coisas visíveis ajudam o product owner e a equipe a reduzir a dívida técnica de forma colaborativa.
Com a visualização da dívida técnica e a descoberta de um plano de pagamento possível, a equipe pode ficar concentrada nos passos mais importantes. Um importante efeito colateral: Essa visão também é uma ótima ferramenta para trabalhar com o product owner e outros interessados porque dá a eles uma boa transparência em relação a dívida técnica.