Como formatar histórias negativas de usuários?

Seguindo o estilo formal da história do usuário:

Como <user>, eu quero <goal>isso <benefit>.

Nossa equipe encontrou dificuldades em expressar coisas onde há um desejo dos proprietários do sistema de fazer algo que afeta negativamente o usuário.

Como um exemplo arbitrário, digamos que o proprietário queira que o sistema carregue os clientes toda vez que verificarem seus emails.

Seguindo o estilo formal das histórias de usuários, você pode escrever da seguinte maneira:

Como cliente, quero ser cobrado toda vez que verifico meu email para que o proprietário do sistema possa aumentar sua receita.

Obviamente, o cliente não deseja ser cobrado; a história se torna chocante de ler e a linguagem está atrapalhando os fatos.

Como o requisito pode ser escrito de maneira diferente?

Se o pagamento afetasse negativamente os clientes, eles não usariam esse serviço. Não se preocupe com isso. Além disso, os usuários (geralmente) não pagam dinheiro porque querem ajudar os proprietários do sistema, mas porque desejam algum serviço em troca, portanto, seu exemplo deve ser assim:

Como cliente, quero ser cobrado toda vez que verifico meu e-mail para poder obter o serviço X em troca.

Além disso, as histórias do usuário são escritas da perspectiva de todas as funções do usuário, não apenas dos clientes finais. Considere escrever este da perspectiva do proprietário do sistema como outra função de usuário:

Como proprietário do sistema, quero que os clientes sejam cobrados toda vez que verificam seus emails para aumentar minha receita.

Um conselho geral: concentre-se na parte positiva da história do usuário e não pense demais nela. Eles devem ser simples. Se a história do usuário é muito negativa, sem uma maneira de evitá-la, o problema está na concepção do sistema e, nesse caso, não importa realmente o que você escreve em seus cartões.

O <user>usuário não precisa ser o usuário final - ele pode ser facilmente o proprietário da empresa / proprietário do sistema:

As a system owner
I want to charge customers
So that the business can pay my programmers

As histórias de usuário não existem para atender a algum tipo de requisito de metodologia. Eles existem apenas para esclarecer o que uma equipe está fazendo, por que está fazendo e quem se beneficia com isso. Se você torce as palavras para obscurecer o significado ou se encaixa em algum requisito estrito para a aparência de uma história, ela não serve para ninguém.

Então responda a pergunta "quem faz esse benefício" e "por que estamos implementando isso" honestamente. Sua equipe de desenvolvimento precisa dessas informações para fazer seu trabalho. Mesmo que a história seja negativa do ponto de vista do usuário, são informações valiosas.

Dito isto, o que você descreve parece mais um cenário de caso de uso do que uma história. Talvez se você reduzi-lo a pedaços menores, talvez seja mais claro quem são os proprietários e os beneficiários. Por exemplo, o recurso de cobrança pela verificação de e-mail possui vários componentes. No mínimo, há um componente de interface do usuário e um componente de back-end, e talvez uma regra de negócios.

Você pode dividir seu recurso nessas histórias:

Como provedor de um serviço de e-mail, desejo cobrar uma taxa por cada e-mail lido, para que eu possa ganhar dinheiro e continuar a fornecer e aprimorar o serviço

Como usuário, desejo que a cobrança da taxa de e-mail ocorra automaticamente para que eu possa ler meu e-mail sem precisar reconhecer cada taxa à medida que ela é cobrada, para que minha experiência seja mais agradável.

Como usuário, desejo poder revisar facilmente os termos de serviço e os valores das taxas, para entender as taxas cobradas, para que eu possa me sentir confiante de que estou obtendo o valor do meu dinheiro.

Como usuário, desejo que a taxa de cobrança para a leitura de e-mails seja pequena, para que eu possa usar esse serviço

Concordo que escrevê-lo em termos de proprietário do sistema parece errado, porque o proprietário do sistema não inicia esta história - o usuário inicia quando verifica o email. Mas não acho que você precise falar em termos do que o usuário deseja, mas do que ele espera que aconteça.

As a customer
When I check my email
I should be charged
So I continue to recieve Service X

O usuário espera ser cobrado porque você descreveu seu plano de pagamento para ele.