回答:
例はユーザーストーリーとして数えることができますが、非常に重要な部分、つまり、ストーリーが実装されたときにユーザーが達成したい目標が欠けています。
この目標は自明かもしれませんが、とにかく書き留めてください。
ユーザーストーリーの形式は
As a <user>
I want <feature>
So that <goal>
目標の部分は、開発者が正しい決定を下すのに役立つため、重要です。
2番目の例には、2つの非常に異なる目標があり、異なる設計につながる可能性があります。
最初のケースでは、簡単なレベルがあれば十分ですが、2番目のケースでは、特定のセルに特定の数値を配置する必要がある/してはならない理由をユーザーに案内する必要があります。
バートが目標に関して述べた良い点に加えて、私は「アジャイル」の部分に焦点を当てたいと思います。あなたが持っているのはユーザーストーリーですが、それらはスペクトルの「エピック」側のはるか上にあり、開発にはまだ役に立ちません。
私が見ているように、新しい製品や機能を最初に計画するときは、通常、上記のようなストーリーから始めて、何を構築したいのかについての良い感覚を得てから、これらの種類の「叙事詩」を壊し始めます"開発のために直接実行可能な一連のストーリーができるまで、ストーリーをどんどん小さくしていきます。特に、テスト駆動開発(TDD)を実践する場合は、各ユーザーストーリーが少数のテストケースに自然に変換できるレベルの粒度にしたいとします(ただし、それぞれはまだ複雑かもしれません)。
このようなより実用的なストーリーの例は次のとおりです。
詳細については、Alex Cowanによる次の優れた投稿をお勧めします: Your Best Agile User Story。