nishida スプリントバックログの粒度はどれくらいがいい？
中村：
「デイリースクラムで動きが分かる程度の詳細さ」とスクラムガイドにありますから、多くても4時間くらいで終わる見込みの大きさというのが目安でしょうか。
2日もかかるようなタスクは進捗が分からなくなってしまうのでおすすめしません。
新井：
たしかに、デイリースクラムで「昨日と同じ状況」というのは避けたいですね。
中村：
昨日より何かが進めばタスクボードのカードが動きますから、カードが動いていないということは何かが詰まっている、と分かるくらいの大きさにするといいですね。
新井：
それを検査するためにも、デイリースクラムを毎日同じ時間、同じ場所でやるといいですよね。週2回とかじゃなくて、毎日やることが大事です。
参加者コメント：
タスク分解の手間が嫌がられがちです。粒度が大きくても、口頭で進捗を共有するというやり方で大きな問題はないでしょうか？
中村：
分解しなくてもチームがスプリントを終えられていて、ステークホルダーからも良いフィードバックが得られているのなら、問題ないと思いますが、大体はそううまくいかないですよね。
そうなるとやはり分解した方が良いのではないでしょうか。検査しやすいように小さくした方が良いとスクラムガイドにも書かれていますから、それを根拠にお話してみてはどうでしょうか。
新井：
問題があることに気がつくためにも、見える化はしていけるといいかな。
チームが熟練すれば、それが当たり前にできるようになっていきます。
抜け漏れもなく進捗も悪くない、スプリントゴールも毎回達成できる、という状況になっているのであれば、チームに任せていいんじゃないでしょうか。
Message from coaches
- タスクは4時間以内くらいで終わる大きさに分解するといい。大きすぎるとデイリースクラムで進捗が把握しづらくなってしまう。
- 検査の精度を高めるため、デイリースクラムは毎日同じ時間、同じ時間でやるのがおすすめ。
- タスク分解の必要性をチームに伝えるには、スクラムガイドを根拠に話したり、見える化をして問題に気づくきっかけを作ったりしてみよう。
スプリント開始後にバックログを変更してもいい？
新井：
スプリントバックログの受け入れ条件について解像度が高まった結果、見積りや内容の変更が必要になることはありますよね。
「スプリントの期間を通して更新される」とスクラムガイドに書かれている通り、「どんどん更新していきましょう」というのが答えです。
放置ではなく適応していくことが大事です。24時間ごとのデイリースクラムの中で、どんどん検査・適応してアップデートしていきましょう。
中村：
スプリントバックログの3つの要素、Why・What・Howのそれぞれでも少し違うと思います。
どのようにやるか（How）については、新たなタスクを1つ追加すればいいですよね。
一方、プロダクトバックログアイテム（What）については、新しく入れられるならばそれでいいかもしれませんが、入らない場合もあるでしょう。その場合は、何かをはずすなり小さくするなりの交渉が必要になると思います。
スプリントゴール（Why）を変えなくてはならないことはあまりないと思いますが、もしそうならスプリントを一旦中止して再検討してもいいかもしれません。
例えば、届けたいと思っていた機能を競合他社が先に出してしまったような場合だと、価値が想定より下がってしまうわけですから。
新井：
影響がWhyの部分まで及ぶのか、Howだけで良さそうなのか。プロダクトオーナーやステークホルダーにまで影響が及ぶようなことであれば、ワンチームとして巻き込んで一緒に検討していきたいですよね。
Message from coaches
- スプリントバックログは、デイリースクラムで検査・適応してどんどん更新していこう。スクラムガイドにも「スプリントの期間を通して更新される」と書いてある。
- ユーザーに届ける価値が想定と違ってきた場合は、一旦スプリントを中止してスプリントゴールを再検討する必要も。
- 変更の影響が及ぶ範囲によっては、プロダクトオーナーやステークホルダーも巻き込んで一緒に検討しよう。
新しいタスクを、いつ、誰が追加する？
参加者コメント：
新たなタスクが見つかった場合、いつ、誰が追加するかというルールはチームによると思いますが、どんなパターンが多いですか？
中村：
誰でも追加していいですし、言い方を変えれば、みんなが関心を払う責任があります。
最低でも、デイリースクラムでそういう話ができるといいですね。
新井：
新たなタスクが発生したことは別に悪いことじゃないんです。
むしろ自分たちで気がつけた、お客様に迷惑をかけずに済んだというのはいいことなんですよね。
分かった時点で適応していくっていう俊敏性がすごく大事です。
スプリントゴールを達成できそうかどうかを話し合うのがデイリースクラムです。
1ヶ月に1回のミーティングではなく、毎日のデイリースクラムをするということは、検査・適応することに価値を置いているということなんですよね。
Message from coaches
- チームみんなでスプリントバックログに関心を持ち、新たなタスクが見つかったら適宜追加していこう。
- 新しいことが分かった時点で適応する俊敏性が大事。毎日のデイリースクラムで、スプリントゴールを達成できそうかどうか話し合おう。
- 毎日デイリースクラムをするということは、検査・適応することに価値を置いているということ。新しいタスクが発生することをポジティブにとらえよう。
時間見積りの精度を高めるには？
新井：
プランニングの段階で時間見積りをするものの、ベロシティや実績を出してみると大幅に違っていることってありますよね。
見積りが合っていないとなると、見積り自体をやめる流れになってしまうこともあると思います。
それはそれで間違えてはいないのですが、エンジニア的には見積りの精度を上げたいと感じる方もいるのではないでしょうか。
中村：
合わないことが「多々」あるのは問題かな。
一つ一つのタスクは1日以内に終わる大きさまで分解していますから、結構見通しが立つはずです。
それが1日で終わらないケースが「多々」あるというのは、タスクのばらし方がそもそも粗いのかもしれません。
数十個あるうちの1〜2個が思ったより複雑で半日以上かかったというようなことなら、次に考慮すればいいですね。
新井：
タスクを分解するときの論理展開がちょっと弱いと、ズレが多発しちゃうのかもしれません。
精度を高めるためには、スプリントレトロスペクティブの中でズレの原因について自分たちでふりかえれるといいですね。
どんな抜け漏れがあったから時間が伸びてしまったのか、気づきや学びを言語化してみると、暗黙知が形式知に変わっていくんじゃないでしょうか。
Message from coaches
- たくさんあるうちの1〜2個のズレは気にしなくてOK。次の見積りで考慮しよう。
- ズレがたくさんある場合はタスクを分解する粒度が粗い可能性も。スプリントレトロスペクティブの中でズレの原因についてふりかえろう。
- 学びや気づき、見積りのズレを引き起こした抜け漏れなどを言語化し、暗黙知を形式知に変えよう。
