スクラムのデザイン要素を含むユーザーストーリー

私たちはスクラムワークフローを実装しており、ユーザーストーリー、つまり完了したとき、イテレーションなどに頭を回そうとしています。私たちがよく行うことの1つは、初期のイテレーション中にストーリーに取り組み、それを完全に機能させることですが、 "醜い"。プレーンなボタンを使用し、画像は使用せず、テキストのみを使用して、ボタンが適切に機能していることを示します。私たちはお客様を紹介し、その動作に満足していることを確認してから、通常は提供された画像を使用して、機能の設計を完成させ、完成させます。

この例では、機能的に完成したときにユーザーストーリーを完成させ、「ユーザーとしてxyzを視覚的に魅力的にしたい」という効果を示す2番目のユーザーストーリーを作成して、設計フェーズを処理しますか？または、設計要素を取得して完了できたら、ユーザーストーリーをプロジェクトの最初の反復から後の方に移動するだけでしょうか。その場合、最初の数回の反復で1つか2つのストーリーしか完了せず、最後の数回の反復でTONのストーリーを完了していることがわかります。

このシナリオをどのように処理しますか？

ユーザーストーリーは、ビジネスに価値を提供するものを表します。設計チームに実用的な機能を提供することは、ビジネスにとって価値がありますか？その場合は、次のようなユーザーストーリーを作成します。

デザインチームのメンバーとして、魅力的な最終的なビジュアルデザインを作成できるように、機能xの作業バージョンが必要です。

その最終的なビジュアルデザインを開発することにビジネス上の価値はありますか？ストーリーを作る：

お客様として、機能Xの視覚的なデザインを視覚的に魅力的で合理化し、製品の使用をより楽しくしたいと考えています。

私がやったことよりもストーリーをより深く考える必要がありますが、うまくいけば、それによって一般的な考えが得られます。

ストーリーは、顧客に提供される完全に完成した機能である必要はありません。ストーリーは、会社に価値を提供する何かを表します。時々、会社はそれ自身の顧客です。ストーリーの要点は、開発作業から誰が恩恵を受けるか、そして彼らがどのように恩恵を受けるかについて考えさせることです。