A História de Usuário está incompleta ou o time não está pronto? Descrever a necessidade ou a solução

Na última segunda-feira, publiquei o artigo sobre critérios relevantes para avaliar e melhorar a saúde das histórias de usuário. Recebi bons feedbacks sobre o assunto. Entretanto surgiram dúvidas e algumas reclamações sobre a definição da Necessidade. No artigo, escrevi “A necessidade deve ter o ponto de vista do usuário do produto e descreve o que ele precisa. Não detalha, no entanto, como será a solução”. Alguns gestores de produto disseram que se chegarem no seu time, sem descrever a solução, o time reclama dizendo que a história está incompleta.

Para deixar claro, utilizo o exemplo que apresentei no artigo. O recomendado seria algo como: 

O que alguns times esperam: 

Eu, enquanto Geovana Gestora, preciso de um relatório na ferramenta de BI com informações sobre idade,  renda, tamanho da população e a presença de concorrentes de bairros da cidade X para saber em quais locais podemos abrir uma nova filial. 

No primeiro exemplo, o Product Owner informa a necessidade e o time decide qual a melhor solução. Já no segundo, o Product Owner descreve exatamente a solução que ele quer que o time implemente.

Qual a forma correta de escrever a necessidade da história de usuário?

Depende. Existe uma relação que define quando você poderá utilizar uma ou a outra. Veja o gráfico abaixo

Aqui temos 2 variáveis. No Eixo Y, a maturidade do time e no Eixo X o Sentimento de Dono do Produto.  Para entender quando detalhar ou não a solução, observe a maturidade do time e o sentimento de dono.

Maturidade do Time

Quanto mais maduro for o time, mais ele tende a demandar autonomia sobre a solução. Essa maturidade costuma a ser composta pela evolução do conhecimento sobre:

• o problema que o produto resolve;
• o contexto em que a empresa opera; 
• os clientes que utilizam o produto;
• as ferramentas que eles devem usar;
• os membros do time;
• e os processos de trabalho.

Essa evolução demanda tempo e mudanças de pessoas-chave do time, podem causar algum ruído na melhoria. Sobre isso, veja o artigo Gestão de times: o mundo entrou no estágio de Forming, e agora?

Sentimento de Dono do Produto: 6 atitudes para fortalecê-lo

É possível que alguns membros do time acreditem erroneamente que por existir uma pessoa com o papel de Product Owner (Dono do Produto), eles não precisam ser parte responsável pela gestão do que estão construindo. Todavia, há uma frase que eu acho ser muito importante: 

“A gestão é importante demais para ser deixada apenas para o gestor”
Jurgen Appelo

Temos uma tendência prejudicial de agir como meros executores: “Pediram para eu fazer A, eu fiz A, e pronto”. Mas não deveria ser assim. Cada pessoa precisa reconhecer que cada incremento que realiza no produto ou serviço contribui diretamente para a construção do todo — elas não apenas entregam tarefas, elas moldam o próprio produto.

Para aumentar o sentimento de dono do produto:

🧭 1. Compartilhe o “porquê”, não só o “o quê”

A pior coisa do mundo é ter um time tarefeiro<<>>. Sem propósito ou objetivo. Sempre mencione o porquê eles estão fazendo. Quem eles ajudam e como ajudam.

🤝 2. Dê autonomia com responsabilidade

Evite chegar com soluções prontas, escute-os para que possam propor soluções técnicas e se tornem partícipes na construção do produto.

🎯 3. Envolva o time nas decisões de produto

Sempre que possível, convide o time para discussões de descoberta, priorização e até avaliação com os clientes. Participar da estratégia aumenta o compromisso com o resultado.

📢 4. Dê visibilidade e protagonismo

Não seja o preposto do time. Incentive os membros a apresentar entregas, liderar iniciativas e interagir com stakeholders. 

🙌 5. Reconheça atitudes de dono

Valorize publicamente quem se antecipa, questiona com foco no cliente ou melhora o que não foi pedido.

☮️ 6. O cliente não é o nosso inimigo

Alguns times têm uma postura de embate com o cliente. Qualquer mínimo feedback construtivo que o cliente dá é suficiente para iniciar ataques de fúria como se ele tivesse xingado a mãe de cada um. Não! Ele é o cliente e como tal deseja o melhor para ele e sua empresa ou time ou área. Essa briga com o cliente apenas reduz a vontade de ajudar e o sentimento de dono do time. Evite intrigas, piadinhas, deboche ou qualquer coisa que reforce essa inimizade. Lembre as pessoas de seu time que eles também são os clientes para alguém.

Com isso em mente, vejamos como adaptar o nível de detalhe das histórias conforme cada cenário.

Como fazer

Quadrante 1 — Baixa Maturidade / Baixo Sentimento de Dono

Aqui o protagonismo do Product Owner é altíssimo. O time está em formação e portanto precisará que você detalhe bastante a solução. Minha sugestão, comece escrevendo a história de usuário. Escreva a necessidade de forma clara  e não a funcionalidade (solução), porém você pode adicionar mais informações. Utilize campos adicionais como: Proposta de solução, modelo de tela e o que mais for importante. 

A grande dica é: Evite o erro do Big Design Up Front (BDUF), que é detalhar toda a solução antes mesmo de validar o problema. Adicione campos a sua história de usuário apenas se precisar.

Quadrante 2 — Baixa Maturidade do Time / Alto Sentimento de Dono 

O quadrante 2 é baixa Maturidade do Time e Alto Sentimento de Dono. Nesse ponto o time quer muito tomar as decisões sobre o produto, porém não tem maturidade para tal. Os campos adicionais servem para suporte e evitar que ideias loucas ganhem forma. O papel do Product Owner é mais de professor do time, ajudando-o a ganhar maturidade.

Nesse ponto você pode começar a tirar campos adicionais das histórias mais simples. 

Quadrante 3 — Alta Maturidade do Time / Baixo Sentimento de Dono 

Normalmente os times que se classificam aqui passaram por algum problema que está impedindo eles se apropriarem do produto. Discussão com clientes, foram excessivamente “protegidos”, sofreram punição ou alguma represália por alguma decisão no passado. 

Aqui o trabalho de Product Owner estará mais para um mentor auxiliando o time a resolver seus problemas e reduzir a dependência dele. Aqui a maioria dos campos adicionais da História de usuário podem ser removidos. No máximo permanece uma proposta de solução. 

Quadrante 4 — Alta Maturidade do Time / Alto Sentimento de Dono

Esse é o ponto ideal. O Product Owner desempenha o seu papel como um consultor da solução. Entre entrega a necessidade e o time propõe a solução. Daqui em diante, caso existam campos adicionais, eles são todos preenchidos pelo próprio time.

Conclusão

A forma como a necessidade é escrita em uma história de usuário depende do contexto do time. Times com baixa maturidade e baixo sentimento de dono precisam de mais direcionamento e até sugestões de solução. Já times maduros e com alto senso de responsabilidade devem receber apenas a necessidade, propondo a melhor solução por conta própria.

O papel do Product Owner é adaptar o nível de detalhe conforme o momento do time, sempre buscando desenvolver autonomia, propósito e protagonismo.

Lembre-se: boas histórias de usuário não são feitas apenas de bons formatos, mas de compreensão mútua entre quem propõe e quem constrói. E isso começa pela forma como escrevemos a necessidade. Dá uma olhada no nosso treinamento de 

Certified Product Owner (CSPO)

Espero ter ajudado e até a próxima.