スプリントゴールはユーザーへのリリースレター。自慢したくなるインクリメントを生み出そう ─ ”とはいえ”シリーズ #11「スプリントバックログ編」（後編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第11回のテーマは「スプリントバックログ」です。
後編では、スプリントゴールの設定やチームでの向き合い方についてお話します。

前編はこちら

チームを成長させるスプリントバックログとスプリントゴールの作り方 ─ ”とはいえ”シリーズ #11「スプリントバックログ編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにア…

redjourney.jp

スプリントゴールが「XXのタスクをする」になりがち

中村：
スプリントゴールがどんなものであればいいのか、スクラムガイドにもはっきりとは書かれていないんですよね。

書籍やいろんな方の発表、トレーニングの中で話をすることが多い内容かなと思います。

新井：
スクラムガイドの中で関連しそうなのは、「スプリントゴール（なぜ）」「スプリントゴールはスプリントの唯一の目的である」という辺りでしょうか。

「GOAL」という単語自体もキーワードですよね。GOAL＝「徒競走のゴールテープが張られているところ」みたいなニュアンスでとらえられると、「XXのタスクをする」というのとはちょっと違ってくるんじゃないかな。

「クラウチングスタートをする」「1つ目のハードルを超える」っていうとただのタスクになっちゃうけど、そうじゃなくて「100m先のゴールテープ」のことを表現しているのが「スプリントゴール」です。

中村：
ユーザーに届けるリリースレターを出すとしたら、どんなタイトルにする？　と問いかけてみてもいいかもしれません。

「タスクが全部終わりました」とはさすがに書かないですよね（笑）。「ECサイトで使える支払い方法が増えました」とか、そういう表現をするはずです。

そんな風に「ユーザーにとって何かができるようになる」という表現ができるといいんじゃないでしょうか。

新井：
エンジニアにしか分からないタスクや機能のことを言っても、ユーザーにはまったく伝わらないことも多いですからね。

それと、細かいタスクを見ていると、日々の活動がミクロな視点でしかとらえられなくなってしまいます。

「自分たちはレンガを積んでいるんじゃなくて、大聖堂を作っているんだ」っていう風に、俯瞰して、大きなビジョンやゴールを踏まえた上で手前にある直近のタスクをやる、という構造でとらえられるといいですね。

中村：
プロダクトゴールとの関連性も大事です。

以前、スプリントレビュー編でお話しましたが、スクラムガイドにはチームはスプリントレビューで「プロダクトゴールに対する進捗について話し合う」とあります。

スプリントゴールはプロダクトゴールに対する途中経過ですから、やはりタスクだけではないはずですよね。

※参照
スプリントレビュー、ステークホルダーやユーザーとどう関わればいい？─ “とはいえ”シリーズ #1「スプリントレビュー編」（前編）

スプリントレビュー、どんな風に進めればいい？─ “とはいえ”シリーズ #1「スプリントレビュー編」（後編）

新井：
始まったばかりのチームでは、その辺りを伝えるのが難しいかもしれませんね。

中村：
私はよくワークを取り入れています。個々のタスクが終わったタイミングで、その結果プロダクトがどうなっているのか、ユーザーに1〜2行くらいで伝えるとしたら何を伝えるのかを、みんなで付箋に書いてみるんです。

新井：
いいですね。

中村：
いろんな伝えたいことが出てくるので、みんなで会話するきっかけになります。

新井：
「これ使ってみてよ！」という感じで、自分たちの仕事を自慢してほしいですよね。

中村：
新井さんはよく「自慢しようよ」と言っていますけど、本当にそういうことですよね。
「こういうことができるようになったから触ってみて！」と、ちゃんと伝えられるようにしなくては。

新井：
自慢という言葉だと、エンジニアの人たちにとってはおこがましい感じがあるのか「そうでしゃばるもんじゃないだろう」と受け取られることもあるんですけど、プチ自慢でもいいんです（笑）。

ユーザーが喜んでくれるもの、そう信じられるものを、スプリントごとに作っていきたいですよね。

スプリントゴールにも受け入れ基準が必要？

参加者コメント：
バックログは受け入れ基準が大事とのことでしたが、スプリントゴール自体にも受け入れ基準を明示したりするのでしょうか？

中村：
受け入れ基準という言葉は使いませんが、スプリントゴールが達成できたかどうかは明確に分かる方がいいですね。

例えば、「ECサイトで支払い方法が増える」というスプリントゴールなら、実際にその方法で購入ができればOKなので、達成できたことは明確ですよね。

新井：
チームの合意事項になっている場合など、達成度がみんなに分かるのであれば短いセンテンスでもいいと思います。

数値的な表現や修飾語を加えた方が分かりやすいと思うなら、括弧書きで加えてもいいんじゃないでしょうか。ただ、3個も4個も並列に書くということはないですね。

中村：
とてもいい質問でしたね。ありがとうございます。

スプリントゴールが1つに絞れない

中村：
1つのチームがプロダクトを2つ持っていたり、プロダクトは1つでも大きなテーマが2つ同時に関わっていたり、といったケースでスプリントゴールを同時に複数設定しているチームの話はよく耳にします。

新井：
結構よくあるケースかもしれませんね。

中村：
最近は、2つあってもいいけど一旦どちらに集中するかを決めるようにお伝えすることが多いです。

初めに集中して取り組む方を決めて、仮に3日目くらいにそれが終われば「おかわり」のスプリントゴールを立ててもいいですよね。

新井：
両方とも終わらないというのは避けたいですよね。

中村：
何もインクリメントを生み出さないことが一番困ります。

新井：
どちらかにフォーカスしていきましょうということは、私もいろんなところで伝えているかな。

中村：
根本的な原因は、チームの外側にあるかもしれませんね。

本当は別のチームが単独で持った方がいいプロダクトを抱え込んでしまっているとか、ステークホルダーがたくさんいすぎてプレッシャーがかかっているとか、プロダクトオーナーが不在気味でチームが決められない状態になっているとか。

チームを取り巻く環境や状況に目を向けてみるのも良いのかなと思います。

新井：
見えている問題点の背景にどんな理由があるのか、しがらみまで紐解いていくと、また違ったアイディアが出てくるかもしれませんね。

中村：
本当に50:50で優先度が決められないなら、サイコロを振って決めちゃえばいいですよ（笑）。

新井：
そうですね（笑）。「おかわり」の制度がチーム内で言語化できていると、先にこっちをやって終わったら次こっち、みたいなことが気軽にできるのでいいと思います。

もし、スプリントゴールを達成できないことが続くようなら、1個に絞ってとにかく終わらせていく。お客様へ価値を届けていく、インクリメントを作る方にフォーカスしてほしいですね。

中村：
大事なことですね。