この場合のタスクに固有のユーザーストーリーの書き方
私たちはユーザーストーリーを取り上げる予定です
プレーヤーとして、ゲームマップを表示して、チームの現在の順位を知りたい
スプリントは2週間です。 2週間でHTMLのみを完成させることができます。コンテンツデザインのリソースが不足しているため、このユーザーストーリーは完成するまでに4〜6週間かかります。
このユーザーストーリーを変更して、HTMLの完了をこのユーザーストーリーの完了と見なし、次のスプリントでこのユーザーストーリーの統合を行う必要があるようにするにはどうすればよいですか？
HTML用と統合、テスト、バグ修正などのための2つの異なるユーザーストーリーを作成することは可能ですか？
すべてのストーリーと同様に、必要なもの、その目的、およびなぜ必要なのかを考えてください。ユーザーはエンドユーザーである必要はありません。ストーリーを書くことの最終目標はあなたとあなたのチームを助けることであることを忘れないでください。本の定義に合ったストーリーを作ることでボーナスポイントを獲得することはできません。ストーリーを細かく分割して、チームが集中できるようにします。
たとえば、フロントエンドストーリー：
ゲームマップを作成する開発者として、マップを表示できるようにHTMLマークアップを作成する必要があります。
...そしてバックエンドストーリー
ゲームマップを作成する開発者として、マップに表示できるように、ゲームデータのフェッチをサポートするバックエンドAPIが必要です。
...おそらくデザインストーリー
ゲームマップを作成する開発者として、ユーザーがマップを楽しんで使用できるように、開発するスタイルシートを完成させる必要があります。
...等々。
あなたの質問はより大きな問題を隠していると思います：コンテンツデザインの人々の欠如（人々のリソースとは呼ばないでください、それは彼らを非個人化します）はあなたのチームが開発サイロで働いていることを示しているようです。
最近のプロジェクトで私は同じことが起こりました。フロントエンダー、インテグレーター、バックエンダーがありました。
私は悪夢でした。フロントエンダーは常に忙しかったが、インテグレーターは忙しくなく、バックエンダーは最初に何を終えるべきかわからなかった。ある時点で40以上の未完成のストーリーがあり、何も完成していませんでした（チームの問題のほかに、他のパーティが完成するまで延々と待たなければなりませんでした）。
お客様に進捗状況を示すためだけに、ストーリーの完成を見積もる必要がありました。あなたの質問は私にこれを思い出させました。はい、モックアップを顧客に見せることはできましたが、モックアップを使用できない限り（完成、完全に文書化、テスト、承認）、モックアップは彼にとって価値がありませんでした。
あなたへの私のアドバイス：コンテンツデザインの人々が物語の仕事を始めているとき、彼らに他の何人かとプログラムをペアにしてもらいましょう。最初は時間がかかるかもしれませんが、長期的には間違いなく努力する価値があるかもしれません。多くの場合、知識の20％で、作業の80％を実行できます。現在のコンテンツデザイナーにプレッシャーをかけ、チーム内の流れを改善することができます。