薄く作る
詰め込みすぎると逆に計画が脆くなってしまうということが多々ある
must ではなくても、他が全部終わったら優先順位の高いものからやってプロダクトの品質を上げたり試したい施策を増やしたりしていきたい
結果として、mustではないものが"希望した"期間に出来上がることもある
落とす・落とさないの議論や調整にもコストがかかるので、できればないものベースで積み上げて行くほうがトータルコストが低い(=できることが増える)
(これは状況によりけりなのですが、) "must" とは言っても「薄く作る」ことで、多少素朴な作りにはなってしまうのですが実装コストを減らしつつビジネスとしてやりたいことは最低限実施できる、という進め方もあり、これが上手くハマるとまるで開発ペースが上がっているかのように見えることがある
薄く、の度合いは大変むずかしい(ドメイン知識が必要)ですが、ユーザーストーリーを分けられると「薄く作る」という選択肢を議論の俎上に上げられるかな…という感覚があります 「仕様」「要件定義」「イシューの『やりたいこと』などを詳細化すればするほど、不要な「厚み」が出てくる傾向がある、という肌感がある 2分割の反復開発、二回目の方、 強くてニューゲーム みたいで気持ち良さそう