generated at
イテレーション計画づくり

直近のイテレーションの内容に応じて、プロダクトオーナーが新しいイテレーションで達成すべき優先度の高い作業を決定
リリース計画づくりと同様、満足条件の検討から始める
イテレーションにおける満足条件は、フィーチャーとそのテスト (受け入れテスト) として表現される
注意点ややると良いこと
タスクの担当者は決めない
チームが一丸となって取り組むため
新しいイテレーションの優先順位づけは、イテレーションが始まる数日前に終わらせると良い
イテレーションレビューとイテレーション計画づくりを同じ日に開催しやすくなる
プロジェクトに関する会議はタスクに含める
不確実なことが多くてタスク分解が困難であればスパイクを使ったりする
保守サポートの作業の負荷も考慮する必要がある
事前にわかっているバグ修正ではなく、突発的な問い合わせ対応など
2 つの手法のうち、筆者のおすすめはコミットメント駆動
2 つの手法
ベロシティ駆動
過去のベロシティを基にベロシティを見積り、イテレーションの対象とするストーリーを決める
コミットメント駆動
ベロシティ駆動とほぼ同じだが、タスクを見積もったうえで、対象のストーリーのリリースを確約できるかチームに尋ねる
「タスク完了の確約」 ではなく、「リリースの確約」 である (タスクの漏れは当然ありうる)
ベロシティはイテレーションにおいては重要ではない (見積りとしては荒い)