先週、はじめてスプリント計画ミーティングをファシリテーションする機会がありました。事前に本を読んで準備したつもりでしたが、実際にやってみると想定外のことだらけ。この記事はそのリアルな記録です。
やったこと
- スプリント期間：2週間
- チーム：開発3名・デザイン1名・自分（PM）
- ゴール：ユーザー登録フローの改善
ミーティング前に、バックログをざっと整理してストーリーポイントを仮置きしておきました。ここまでは順調。
失敗①：ベロシティを把握していなかった
最初の計画なのでベロシティのデータがありません。「何ポイント入れるか」の判断基準がなく、メンバーが「これ2週間で終わる？」と不安そうな顔をしていました。
次回の改善： 初回はチームと一緒に「このタスクは何時間かかりそう？」を積み上げ方式で見積もる。ベロシティは2〜3スプリント後に参考にする。
失敗②：タスクの粒度がバラバラだった
「ログイン画面を作る」（推定3日）と「エラーメッセージのコピーを修正」（推定30分）が同じバックログに並んでいた。
計画ミーティング中に「これって分解できない？」という話になり、30分の予定が1時間以上かかりました。
次回の改善： 計画ミーティング前にタスクを1〜2日以内に収まる粒度に分解しておく。これがリファインメントの役割だったと後から理解。
失敗③：「完了の定義（DoD）」を決めていなかった
スプリント終わりのレビューで「これ完了なの？」という会話が発生。開発側は「コードはできてる」、自分は「ユーザーテストまで終わってほしい」という認識のズレ。
次回の改善： スプリント開始前に「完了＝○○の状態」をチームで合意しておく。
気づいたこと
計画ミーティングは「タスクを割り振る場」ではなく「チームで共通認識を作る場」だと実感しました。
本で読んだときは「なるほど」と思っていたことが、実際にやってみると全然できていない。この感覚が一番の学びだった気がします。
次のスプリントでやること
- バックログの粒度を事前に整える
- DoD（完了の定義）をチームで合意する
- タイムボックスを守る（ミーティングは2時間以内）
また次のスプリントが終わったら振り返りを書きます。
この記事は個人の学習記録です。正解ではなく試行錯誤の過程を記録しています。
タグ