ユーザーストーリー
顧客やユーザーができるようになりたいことをまとめた文章
要求
新しい機能を望む人(多くの場合、そのシステムの顧客)の視点で見た機能についての短く、シンプルな説明
productのWhyからWhatを意識することができるようになる
受け入れ条件を併せて書いておくと良いらしい
テンプレート例
<ユーザーのタイプ>として、<理由>のために<ゴールの達成>がほしい
<ユーザーのタイプ>として、私は<背景>のため、<ペインとゲイン>を解決するために、<ソリューション>がほしい
受け入れ条件
そのユーザーストーリーが満たされているかどうか判断するためのもの
「仕様」と何が違うんだ #??
/mrsekut-book-4798166391/198
ユーザーストーリーマッピング
ユースケースで見るのは具体的
「ユーザーストーリー」は「課題」でも「解決策」でもないよなmrsekut.icon
抽象度が異なる
課題でも解決策でもないのに、全部一律でユーザーストーリーというフォーマットで起票するのが意味不明なのだろう
例えば、細かいエラーに対する対応とか
短期的にはユーザに大きな影響があるわけではないが、バグ対応として起票したい
この起票時にわざわざユーザーストーリーのフォーマットにする必要がない
https://www.cresco.co.jp/blog/entry/14387/
『ユーザーストーリーマッピング』
/mrsekut-book-4798166391/197
https://tech.uzabase.com/entry/2022/01/31/124104