これなに
スクラム開発を続けていると、Sprint Planningの場でこんな状況に遭遇したことはないでしょうか。
- リファインメントが追いついておらず、Storyの妥当性がチームで判断できない
- POが「このStoryで合っているのか」を答えられない状態のままチケットが並んでいる
- 結果として、Planningで「結局何をスプリントに入れるか」が決まらない
先日、自分が関わっているスクラムチームでまさにこの状況になりました。
そのときチームから「いったんスプリント期間を短くして、準備ができ次第Planningをやり直そう」という提案が出たのですが、自分はそれに対して「スプリント期間は変えない」という選択をチームに提案しました。
この記事では、なぜスプリント期間を変えなかったのか、その代わりにどう乗り切ったのか、そしてそもそも根本原因はどこにあったのかを整理して書いていきます。スクラムマスター的な立ち回りの一例として、未来の自分や同じ状況に陥った誰かの参考になれば嬉しいです。
何が起きていたか
事情を整理するとこんな感じでした。
- Sprint Planning時点で、リファインメントが十分に進んでいないStoryがいくつかあった
- 技術的な実装可否の検討がStoryデザインの時点で済んでいなかったため、POとしても「このStoryが妥当か」を判断できない状態だった
- 当然、Planningで「これをスプリントに入れる」という合意が取りづらい
要するに、スプリントを開始するための前提条件が十分に揃っていないというやつです。
チームから出た「スプリントを短くしよう」という提案
このとき、チーム内から自然に出た提案が「スプリント期間をいったん短くして、準備が整い次第、改めてPlanningをやり直そう」というものでした。
これは一見、合理的に思えます。準備ができていないものを無理にスプリントに突っ込んでもうまくいかないし、リズムを少し崩してでも仕切り直したほうが健全に見える。
ただ、自分はこの提案に対して「スプリント期間は変えない」という方針を提案しました。
なぜスプリント期間を変えなかったのか
理由は一つで、スプリントが固定長であること自体に価値があるからです。
Scrum Guide 2020 では、Sprintは固定長のイベントとして定義されています。なぜ固定長なのかというと、
- 検査と適応のサイクルが一定のリズムで回ることで、予測可能性が生まれる
- リズムが安定しているから、ベロシティや傾向が比較できるようになる
- 「準備不足だから今回は短く」を許容すると、その判断自体が常態化していく
ここで一番怖いのは、最後の点です。
「準備不足だからスプリントを短くする」を一度許容すると、根本原因であるリファインメントプロセスの弱さが、スプリント長の調整によって覆い隠されてしまいます。本来であれば「なぜ準備が間に合わなかったのか」を直視すべき場面で、表面的な対処で乗り切れてしまうため、問題が見えなくなるのです。
これは個人的には、スクラムにおいてかなり危険なパターンだと考えています。
実際にどう乗り切ったか
スプリント期間を変えない代わりに、チームと合意した戦略は次のような形でした。
- 準備が整っている、実装可能なタスクレベルのチケットでスプリントを開始する
- 準備ができたチケットからBacklogの先頭に持ってくる
- チームに余裕があれば、先頭から順に取って対応する
完璧な姿ではありませんが、リズムを維持しつつ、開発を止めない、というバランスを取った形です。
ここで大事だったのは、「これは応急処置である」という認識をチーム全体で共有したことです。準備済みチケットをBacklog先頭に持ってくる運用は、本来であればPOが価値の高さで並べるべきBacklogの順序を、便宜上「準備できた順」に変えていることになります。これを定常化させると、いわゆる feature factory 的な状態に陥ります。
なので、「今回のスプリントはこのやり方で乗り切るが、根本原因にはレトロで向き合う」という共通認識を持って開始しました。
でも本当の問題はそこじゃなかった
リファインメント不足という現象に対して、その場の対応はできました。ただ、本当に向き合うべきはその背景にある根本原因です。
今回のケースで根本原因として見えていたのは、 「実装可否を検討せずにStoryをデザインしている」 という点でした。
- POはユーザー価値の観点でStoryを書く
- でも技術的な実現可否までは検討できていない
- 結果、Refinementの場で初めて技術的な課題が大量に出てくる
- POとしては技術課題が解消されるまで「このStoryでいいのか」を判断できない
- Refinementが収束しないままPlanningを迎える
これはPOの責任というよりは、Storyデザインのプロセス自体に技術視点が組み込まれていないという構造の問題です。
既に動いていた対策と次のスプリントへの仮説
実はこの根本原因については、前々回のレトロで既に対策が議論されており、1週間前から動き始めていました。
具体的には、組織上のDevelopersの実質的なリーダー（スクラム上は存在しない役割ですが、組織構造上は存在）が、POと一緒にStoryを事前にデザインすることで、技術的な課題や疑問点をRefinementの前にある程度拾っておく、という取り組みです。
これによって、Refinementは「ゼロから技術検討する場」ではなく、「事前にデザインされたものをチーム全体で確認・調整する場」になることを期待しています。
そして今回開始したスプリントでは、この対策を経たStoryチケットがSprint Backlog Itemとして含まれています。つまり、 「今回のスプリントの結果が、前々回のレトロで決めた対策の効果検証になる」 という構造になっています。
完璧ではないものの、振り返ってみると経験的プロセスとしては良い状態だなと思います。
- 問題を観測（リファインメント不足）
- 仮説を立てて対策を設計（Story事前デザインの分担）
- 実装（運用）
- 次のスプリントで効果を検証
Scrum Guide が言うところの「経験主義（empiricism）」を、レトロを起点に実際に回せている感触があります。
この対策のリスクと今後の課題
ただ、現状の対策にも構造的なリスクはあります。
「組織上のリーダーがPOと一緒にStoryを事前デザインする」というアプローチは、短期的には機能しますが、長期的には次のようなアンチパターンに陥る可能性があります。
- 知識の一点集中：技術判断がそのリーダー1人に集約され、他のDevelopersがStoryの背景や技術的トレードオフを理解しないまま実装する状態になる
- 「設計する人」と「実装する人」の分離：Refinementが「事前に決まったものを共有する場」に変質し、Developers全体の当事者意識が下がる
- リーダー不在時の脆弱性：その方が休んだり離脱したりすると、Refinementの質が一気に元に戻る
スクラムでは Developers は accountability を共有する一つの単位として扱われ、内部にヒエラルキーや専門役割を持たないのが原則です。なので、このリーダー依存の構造は、いずれチームとしての仕組みに昇華していく必要があります。
具体的には、
- 事前デザインの内容を、Refinementで他Developersがレビュー・反論できる場として運用する
- 将来的に、PO伴走役をDevelopers間でローテーションする
- 技術判断のプロセス自体を可視化して、属人性を下げる
このあたりが次の課題になりそうです。
まとめ
今回の話で個人的に大事だったポイントを整理すると、こんな感じです。
- スプリント期間は固定長であること自体に価値があるので、準備不足を理由に変えるのは避けたい
- 準備不足は応急処置で乗り切ってよいが、「これは応急処置である」という共通認識をチームで持つこと
- 表面的な現象（リファインメント不足）の裏にある根本原因（Storyデザインプロセスに技術視点が欠けている）に向き合うこと
- 対策を打ったら、次のスプリントを効果検証の機会として明示的に位置づけること
- 個人の力量に依存した解決は応急処置として有効でも、いずれチームとしての仕組みに昇華させていくこと
スクラムマスターの仕事って「イベントを開催する」とか「ルールを守らせる」みたいなところに目が行きがちですが、本質的にはこういう 「チームが経験的プロセスを回せる状態を維持する」 ことなんだろうな、というのを今回改めて感じました。
最後に
今回の記事は、自分自身のスクラムマスターとしての立ち回りを振り返るためにも書きました。
「スプリント期間を短くしよう」という提案は、その場では合理的に聞こえますし、自分も最初は「それでもいいかも」と一瞬思いました。ただ、そこで一歩立ち止まって「リズムを崩すことのリスク」を考えられたのは、スクラムガイドの勉強や日々のスクラム実践で積み重ねてきたものが効いたなと思います。
スクラムって本当に「シンプルだが習得が難しい」フレームワークだと改めて感じる出来事でした。同じような状況に遭遇している方の参考になれば嬉しいです。