ネガティブユーザーストーリーをフォーマットするにはどうすればよいですか？

正式なユーザーストーリースタイルに従います。

として<user>、私は<goal>そうしたいです<benefit>。

私たちのチームは、システムの所有者がユーザーにマイナスの影響を与える何かをしたいという要望がある場合、表現することに困難を感じました。

任意の例として、所有者がメールをチェックするたびにシステムが顧客に請求することを望んでいるとしましょう。

ユーザーストーリーの正式なスタイルに従って、次のように記述します。

顧客として、システム所有者が収入を増やすことができるように、メールをチェックするたびに請求されたいと思います。

明らかに、顧客は請求されることを望んでいません。物語は読みにくくなり、言語は事実を妨げています。

要件はどのように異なる形で記述できますか？

お金を払うことが顧客に悪影響を与えた場合、彼らはそのサービスを使用しません。心配しないでください。また、ユーザーは（通常）システムの所有者を支援したいのでお金を払っていませんが、代わりにサービスを求めているため、実際の例は次のようになります。

顧客として、サービスXを交換できるように、メールを確認するたびに料金を請求したいと思います。

また、ユーザーストーリーは、エンドカスタマーだけでなく、すべてのユーザーロールの観点から書かれています。システム所有者の観点から、これを別のユーザーロールとして作成することを検討してください。

システム所有者として、私は顧客がメールをチェックするたびに課金されるようにして、私の収入を増やします。

一般的なアドバイス：ユーザーストーリーのポジティブな部分に焦点を当て、それを考えすぎないでください。彼らはシンプルでなければなりません。ユーザーストーリーが非常に否定的で、それを回避する方法がない場合、問題はシステムの概念にあり、その場合、カードに何を書いても問題ありません。

<user>エンドユーザーである必要はありません-それは簡単にビジネスの所有者/システム所有者であることができます。

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

ある種の方法論要件を満たすためのユーザーストーリーは存在しません。それらは、チームが何をしているか、なぜ彼らがしているのか、そして誰がその恩恵を受けるのかを明確にするためだけに存在します。言葉をひねって意味を曖昧にしたり、ストーリーがどのように見えるかについてのいくつかの厳しい要件に適合させても、それはだれにも役立ちません。

それで、「誰がこの利益を得るのか」と「なぜこれを実装するのか」という質問に正直に答えてください。開発チームが仕事をするには、この情報が必要です。ストーリーがユーザーの視点から否定的であるとしても、それは貴重な情報です。

そうは言っても、あなたが説明することは、ストーリーというよりはユースケースのシナリオのように聞こえます。おそらく、これをより小さなピースに減らした場合、所有者と受益者が誰であるかがよりクリーンになる可能性があります。たとえば、電子メールをチェックするための課金機能にはいくつかのコンポーネントがあります。少なくとも、UIコンポーネントとバックエンドコンポーネント、そしておそらくビジネスルールがあります。

機能を次のストーリーに分解できます。

メールサービスのプロバイダーとして、お金を稼いでサービスの提供と強化を継続できるように、読んだメールごとに料金を徴収したい

ユーザーとして、料金が徴収されるたびに料金を確認しなくてもメールを読むことができるように、メール料金の徴収が自動的に行われるようにして、私の経験をより楽しくしています。

ユーザーとして、利用規約と料金の金額を簡単に確認できるようにして、請求される料金を理解できるようにして、自分のお金の価値を得ていると確信できるようにします。

ユーザーとして、このサービスを利用できる余裕があるように、電子メールを読むための収集料金を小さくしたい

システム所有者はこの話を開始しないので、システム所有者の観点からそれを書くのは間違っているように見えることに同意します。しかし、ユーザーが望んでいることではなく、ユーザーが何を期待しているかについて話す必要があるとは思いません。

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

支払いプランの概要をユーザーに説明したので、ユーザーは請求されると予想します。