nishida スプリントゴールに直接関係しないことも入れていい？
新井：
スクラムガイドにも書いてありますが、スプリントバックログはチームが自分たちで管理するためのものなので、自分たちがやらなきゃいけないことであれば、きちんと入れておくべきだと思います。
スプリントゴールに直接関係しないからといって、サービス残業するわけにはいきませんよね。
中村：
私もスプリントバックログに入れて管理するのがいいと思いますが、割合としては8:2とか7:3とか、それくらいかな。
5:5にまでなっちゃうようだと、集中が削がれる感じがしますね。
新井：
その割合が変わるとしたら、背景にきっと何かがあるんですよね。
例えばゴールデンウィークの谷間とか、メンバーが集まらなくてスプリントが思うようにできなさそうなら、思い切ってイレギュラースプリントにしてしまって、そういう技術的負債を一気に返すというのもいいんじゃないでしょうか。モブプログラミングをテスト的にやってみるとかね。
中村：
6個のうち1個くらいは、スプリントゴールに直接関係しないものでもいいんじゃないでしょうか。
新井：
それだって誰かがやらなくちゃいけないことだし、緊急で対処しなくちゃいけないこともあるので、きちんと自分たちで見える化して管理していきたいですね。
Message from coaches
- スプリントゴールに直接関係なくても、チームがやらなくてはならないことは自分たちで管理できるようにスプリントバックログに入れて見える化しておこう。
- 割合としては20〜30%が理想。それ以上増えるときは、背景にある原因を探ってみよう。
- 連休の合間などを使って技術的負債（スプリントゴールには直接関係ないけどやらなきゃいけないこと）を一気に片付けるのもおすすめ。
プロダクトオーナーが一方的にスプリントゴールを宣言しがち
中村：
「次のスプリントのスプリントゴールはこれです！」と言ってプロダクトオーナーが一方的に宣言してしまう。とはいえ、スクラムガイドには具体的な方法は書かれていないんですよね。
新井：
プロダクトオーナーにはビジネス的な責任がありますから、プロダクトゴールにせよスプリントゴールにせよ、プロダクトオーナーの意思が濃く反映されていることは多いと思います。
ただ、そこで議論をしなくていいというわけではないし、こっちの方がやりやすいとか、こうする方がいいとか、コミュニケーションの往復は必要かな。無理なものは無理ときちんと言うべきです。
中村：
プロダクトオーナーがスプリントゴールを伝えたら、メンバーはそれに対してどういう狙いなのか、できなかったらどういうことが起きるのか、理解するところから始めるといいですね。
一方的な宣言で終わりになっちゃうとうまくいかないと思います。
新井：
言われたからそれを必ず守らなくちゃいけないという主従関係みたいになっちゃうと、健全ではないですよね。
ただ、明確な理由があれば話は別です。
例えば、背景としてクリスマス商戦などビジネス的に絶対守らなくちゃいけない、逃せない機会があるような場合は、残業が必要かどうかということも含めてきちんと話した上で「がんばってくれ」と伝えればいいと思います。
それがその後もずっと継続しちゃうと疲弊してしまうので、有給休暇を使うなどしてリカバリーは必要です。
セルフマネジメントしながらできるといいですね。
中村：
最初にプロダクトオーナーが意思を宣言して、他のメンバーたちはその意図を確認した上でそれを実現するためのバックログを考えていく。必要ならタスク分解を進めたりしながら、実現できそうかどうかを会話していって、できそうであればそれをスプリントゴールにすればいいし、難しそうなら言葉を変える。そういう会話ができるといいですね。
新井：
「理解が難しい」「実現が難しい」と表明することも、開発者側の責任であり役割なんですよね。
Message from coaches
- プロダクトオーナーの意思が濃く反映されるのは仕方のないこと。一方的に伝えたり受け入れたりするのではなく、「コミュニケーションの往復」をすることが大事。
- プロダクトオーナーがビジネス的な背景からスプリントゴールを設定しなくてはならない場合は、メンバーにその理由を伝えた上で会話をしよう。いつもよりペースアップした後は、メンバーが疲弊しないよう有給休暇を使うなどしてリカバリーが必要。
- 開発者側は、無理なことは無理と伝える責任がある。スプリントゴールの狙いを理解した上で必要なスプリントバックログを考え、実現できそうかどうかを判断しよう。
チームでうまくスプリントバックログを作るには？
中村：
メンバーそれぞれが持っている多様な経験や情報が必要ですし、結局大事なのは「対話」じゃないでしょうか。
みんなが誠実であることも必要ですね。
新井：
プロダクトゴールやスプリントゴール、お客様に提供する価値に対して誠実であるか、真摯であることは大事ですね。
できないものはできないと言うこと、時間的に間に合わないということを早めに表明するのも誠実さです。
隠し続けても最終的には露呈して各方面に迷惑がかかってしまいますから、早めに出していくということですね。
参加者コメント：
「勇気」が必要ですね。
中村：
そうですね。できないことを約束してその場を切り抜けたとしても、できないものはできないですから、ちゃんと言うことが大事です。
スプリントレビューでインクリメントを見せてフィードバックを得ることができなければ、次の作戦を立てられないまま、情報がない、分からない状態でまた1週間走らなくてはなりません。
自分たちがどんなにがんばったとしても、インクリメントを見せられなければ次の1週間が無駄になってしまうので、自信を持ってできる量、内容にして、コミットメントすることが大事ですね。
新井：
それが結果として価値につながっていくんですよね。
Message from coaches
- メンバーそれぞれの経験や情報を持ち寄り対話をしよう。
- プロダクトゴールやスプリントゴール、お客様に提供する価値に対して誠実・真摯であることが大事。できないことはできないと早めに伝える勇気を持とう。
- 次のスプリントをどれくらい意味あるものにできるかは、スプリントレビューでインクリメントを見せてフィードバックを得られるかどうかにかかっている。自信を持ってできる量、内容を設定して価値につなげよう。
絶対達成できるスプリントゴールを設定した方がいい？
参加者コメント：
絶対達成できるスプリントゴールを設定した方がいいんでしょうか？ それとも、できるかどうかわからない、50%程度の目標にするべきでしょうか…
中村：
もちろん状況によりますけど、まずはチームが当たり前にスプリントゴールを達成できることを目指しましょう。
なぜかと言うと、スプリントレビューでステークホルダーからフィードバックを得るためには、まず当たり前にインクリメントができる、つまりスプリントゴールが達成できることが前提だからです。そうじゃないと、フィードバックも信頼も得られません。
そのうちどんどんチームのやり方や成果が安定していきます。そうなってきたら、今度は意図的に自分たちの幅を広げたり新しいことに挑戦したりと「実験」をしてみるといいですね。
その結果、スプリントゴール達成の頻度が下がったとしても、チームもステークホルダーも、チームが実験していることが分かっているので問題にならないと思います。
逆に10スプリント連続達成と言われると、実験できているのかな？ と思ってしまいます。
新井：
私も、まずはきちんとスプリントゴールを達成できる状況を作り出すために、最初のうちは100％達成できるようなスプリントゴールを置いた方がいいと思います。
その後、エンジニアたちから「もっと高めを目指そう」という声が出てきたり、プロダクトオーナーが実現したいことが出てきたりしたら、スクラムマスターから「もっとチャレンジしようよ」と働きかけていく。
「もっとチャレンジしよう」「もっとユーザー価値を高めていこう」とチームが考えられるように、スクラムマスターがコーチングするべきですし、そうすることで少しずつストレッチ系の目標が入ってくるんじゃないかな。その繰り返しじゃないでしょうか。
参加者コメント：
信頼貯金をためてから徐々にストレッチめの目標を掲げていくんですね。信頼貯金という考えは勉強になりました。
新井：
よかったです！
Message from coaches
- まずはチームが当たり前にスプリントゴールを達成できるようになることを目指そう。ステークホルダーからの信頼とフィードバックが得られるようになるまでは、100%達成できるようなスプリントゴールを置くようにしよう。
- チームが安定して成果を出せるようになったら、よりユーザー価値を高めたり自分たちの幅を広げたりするための「実験」をしていこう。
- チームが安定から挑戦へと徐々に舵を切り成長していくために、スクラムマスターからチームに働きかけよう。
redjourney.jp