Come formattare le storie utente negative?

Se i soldi pagati incidevano negativamente sui clienti, non avrebbero usato quel servizio. Non preoccuparti di questo. Inoltre, gli utenti non pagano (solitamente) denaro perché vogliono aiutare i proprietari dei sistemi, ma perché desiderano un servizio in cambio, quindi il tuo esempio dovrebbe essere proprio così:

As a customer, I want to be charged every time I check my email so that I can get service X in exchange.

Inoltre, le storie degli utenti sono scritte dalla prospettiva di tutti i ruoli degli utenti, non solo dei clienti finali. Considera di scrivere questo dal punto di vista del proprietario del sistema come un altro ruolo utente:

As a system owner, I want customers to be charged every time they check their email so that I increase my revenue.

Un consiglio generale: concentrati sulla parte positiva della storia dell'utente e non pensarci troppo. Dovrebbero essere semplici. Se la storia dell'utente è molto negativa, senza un modo per evitarlo, allora il problema è relativo alla concezione del sistema, e in quel caso non importa molto quello che scrivi sulle tue carte.

Il <user> non deve essere l'utente finale - può facilmente essere il proprietario dell'attività / il proprietario del sistema:

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

Le storie degli utenti non esistono per soddisfare una sorta di requisito metodologico. Esistono solo per chiarire cosa sta facendo una squadra, perché stanno facendo e chi ne beneficia. Se si distorcono le parole per oscurare il significato o si adattano a requisiti stringenti per ciò che una storia dovrebbe avere, non serve a nessuno.

Quindi rispondi alla domanda "chi fa questo vantaggio" e "perché stiamo implementando questo" onestamente. Il tuo team di sviluppo ha bisogno di queste informazioni per svolgere il proprio lavoro. Anche se la storia è negativa dal punto di vista dell'utente, si tratta di informazioni preziose.

Detto questo, ciò che descrivi sembra più uno scenario d'uso piuttosto che una storia. Forse se lo riducessi a pezzi più piccoli potrebbe essere più pulito chi sono i proprietari e i beneficiari. Ad esempio, la funzione di addebito per il controllo della posta elettronica ha diversi componenti. Per lo meno c'è un componente dell'interfaccia utente e un componente back-end, e forse una regola aziendale.

Potresti suddividere la tua funzionalità in queste storie:

Come fornitore di un servizio di posta elettronica, Voglio riscuotere una tassa per ogni e-mail in lettura in modo che io possa guadagnare denaro e continuare a fornire e migliorare il servizio

Come utente, voglio che la riscossione della commissione di posta elettronica avvenga automaticamente in modo da poter leggere la mia e-mail senza dover riconoscere ogni tariffa così come viene raccolta in modo che la mia esperienza sia più piacevole.

Come utente, desidero essere in grado di rivedere facilmente i termini del servizio e gli importi delle tariffe in modo da comprendere le commissioni addebitate in modo da poter essere sicuro di ottenere i miei guadagni.

Come utente, Voglio che la tassa di incasso per leggere le e-mail sia piccola così posso permettermi di usare questo servizio

Sono d'accordo sul fatto che la scrittura in termini di proprietario del sistema sembri sbagliata, perché il proprietario del sistema non avvia questa storia - l'utente lo fa, quando controlla la sua posta elettronica. Ma non penso che tu abbia bisogno di parlare in termini di ciò che l'utente vuole, ma piuttosto di cosa si aspettano che accada.

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

L'utente si aspetta un addebito perché hai delineato il piano di pagamento a loro.