スプリントのタスクを受け入れ条件単位で書く

TL;DR

• スプリントバックログアイテム（よくスプリントのタスクとか言われるもの）を、受け入れ条件の粒度で書くとよいことがチラホラあったという話

背景

• スプリントのタスクを考えるときに、安易に設計・開発・テスト、とかしがち
• 一方で、この切り方で行くと、今作ってるものが方向性あってるっけ？とか、いらないもんまで作ってない？みたいな検査をしたくても、取り返しがつかない
• 結果、PBI が完成してから、過不足に気づいたりして、ムダに悩まされる

何をやるか

• スプリントプランニングのトピック３の際に、スプリントバックログアイテムを、各プロダクトバックログの受け入れ条件（Acceptance Criteria）ごとに作成する
• デイリースクラムでは、スプリントバックログアイテムの進捗を動いている状態で検査する（ミニデモ）

効果

• 計画時に、「なぜやるのか」「何をやるのか・やらなくていいのか」「何がコアバリューなのか」を理解してから作り始めることができる
• 一番コアな部分から作るので、設計がしっかりしやすい（ダメなときはダメ）
• 朝会でインクリメントを見ることができるし、そのうえで、追加の実装の要否やこれでもう十分かも、といった議論ができるようになった
• 詳細な実装タスクにしていないので、モブが加速して WIP が下がる。結果として実装中の会話が増え創発性が向上して想定より良いものができる
  • PR で今更言われても、、、になったりしない
  • WIP PR だと会話量が少なくて創発的というほどでもない

デメリット

• 何をやれば実現できるか、の検討をリードできる人が欠席しているとリスクが高い
  • いままでは計画の日だけ気にしていたとの声
    • いろいろ複雑な背景がありそうなのでふりかえりを加速するしかねえなと
      • ふりかえりも毎日やればいいか