見出し画像

スプリント中にタスクが全部終わらない原因ランキングと解決策

ラテ（仮）＠アジャイルコーチ・スクラムマスター

スプリント中にタスクが全部終わらないといったお悩みを抱えている人は多かったり、問題視していないが成果を出すための大きな障害になっているチームもよく見ます。

スプリント中にタスクが完了していないと、マネージャーから評価が悪くなってしまったり、問題を抱えているチームとして判定されがちです。スクラムで開発して、ユーザに価値を提供できるチームを目指して、上長から評価される人を目指して、一緒に頑張っていきましょう。

今回は、私がこれまで関わってきたチームであった、スプリント中にタスクが終わらない原因を重要度順でランキング形式で、その要因と解決策をセットでご紹介します。問題がない場合も、問題がある場合も、どちらも紹介しています。なので、自分たちのチームが該当するものはどれなのか。また、問題がないものの場合は、いい兆候だということをマネージャーに共有することで、評価を高めるのに使ってください。

重要なものは、最後の方に書かれていますので、ぜひ最後までご覧ください。


第8位 PBIの消化よりもスプリントゴールを重視している

第8位は、「PBIの消化よりもスプリントゴールを重視している」です。本記事の中で最も重要度の低い状態、チームが適切な対処をしている場合です。この状況であるなら、そのまま継続できるように進めてください。

スクラム開発において重要なのは、顧客に価値を提供することであって、タスクをたくさんこなすことではありません。そのため、スプリントゴール（スプリントで達成したいユーザへ届ける価値）を達成できることの方がタスクをこなすことよりも重要なわけです。したがって、すべてのタスクの完了が間に合いそうになくなった場合、スプリントゴールを重視して、全タスクの完了を見送るのは適切な判断です。継続していただけるのが良いかと思います。

第7位 チームが成長を目的に少し難しい量に挑戦している

第7位は、「チームが成長を目的に少し難しい量に挑戦している」です。こちらも前項目同様にチームが適切な対処をしているケースです。継続できるように進めてください。

私のスクラムの師であるJim Coplien氏はスプリント中の全タスクの完了の成功率は1/2が最も良いと説明しています。なぜなら、毎回のスプリントで全タスクが完了しているとすれば、それはチームが確実にこなすことのできる安全圏の量のタスクを確約していることになるからです。成功できるかどうか分からない量に対して、全力で頑張るからこそチームが成長できるのです。

したがって、チームの成長を目標に、全タスクが終わる状態でない場合があることは問題ありません。できれば、成功率が1/2になるように挑戦を続けてもらえたらと思います。

第6位 見積もり能力が低い

第6位は、「見積もり能力が低い」です。こちらは、適切な対処をしているわけではありませんが、時間が解決することもあるので重要度が低めになっています。

判断方法

見積もり能力の低さが原因の場合は、見破るのは簡単です。ベロシティ（過去のスプリントでこなしたPBIのストーリーポイントの合計）の計測と、毎回のスプリントで完了していないタスクがいくつかあるかを確認したらよいのです。ベロシティをグラフにしたときに、安定せずに上下に揺れていて、仕掛り中のタスクがある場合です。

解決策

これは、見積もり能力が高まることで自然に解決していく場合もありますが、3ヶ月以上継続している場合は解決が必要です。PBIの見積もりをする時間を長めにとって、設計までイメージして対話することや、プランニングポーカー（一斉に見積もりを出して理由を説明する見積もり方法）を導入することをおすすめします。

もっと詳しく知りたい方へ

第5位 大きすぎる目標設定をしている

第5位は、「大きすぎる目標設定をしている」です。この事象を放って置くと「確約してもどうせ達成できない」と確約が軽視される傾向になります。該当する方は、改善できるように取り組みましょう。

要因

大きすぎる目標を設定している状態とは、スプリントプランニング（計画会）の時間に、自分たちのキャパシティを超えた目標を設定していることになります。これらの要因として考えられるのは、自分たちのできることを過大評価している場合や、ステークホルダーやPOから「ここまで終わらせてほしい」と要求されている場合です。

判断方法

大きすぎる目標設定を見破る方法は、スプリントでPBIを消化できていることが、毎回であったり、実績と確約したPBIのポイントを比較して実績よりも確約したポイントが多いかどうかが判断基準になります。

解決策

このような状態は健全ではないので、解決する必要があります。最も簡単な方法は、過去のスプリントの実績を元に、次のスプリントの計画をすることです。過去3スプリントの平均を使って次のスプリントの計画をすることです。また、初期でまだ3スプリントの実績がない場合はあるだけを参考に決め、最初のスプリントの場合は予想で大丈夫です。過去の実績以上に、確約を要求されそうなときはスクラムマスターに止めて頂きたいところです。

もっと詳しく知りたい方へ

第4位 スプリント中に進捗を把握できていない

第4位は、「スプリント中に進捗を把握できていない」です。こちらは放っておくとデイリースクラムでせっかく作業を共有しても、意味をなさなくなってしまいます。さらに、現実を直視せずに時間を不必要にタスクに時間を使ってしまうことにも繋がります。改善しましょう。

要因

スプリント中に進捗を把握できていない要因としては、タスクの数が多くて全体像が把握できていないケースや、タスクの粒度が大きく進めても進捗に反映されないケースがあります。加えて、かかった時間をそのまま進捗として反映させていたため、進捗していたと思っていたにもかかわらず、進捗していなかったというケースもあります。

判断方法

スプリント中に進捗を把握できていないことを見破る最も簡単な方法は、デイリースクラムでタスクが完了しそうかどうかの議論がなされていない場合です。それに加えて、完了していないタスクの進捗具合を自己判断して進捗率に反映させている場合も問題です。

解決法

解決方法は、2つあります。1つはスプリントバーンダウンチャートを作り進捗を可視化する方法、もう1つは、タスクの粒度を小さくする方法です。

バーンダウンチャートは、毎日のデイリースクラムで、残タスク数を数えプロットすることで作成することができます。このとき気をつけていただきたいのは、タスクの進捗具合が80％だとしても完了するまではチャートに反映させないことです。なぜなら、進捗具合は、途中で詰まってしまうことで想定と全然違った終了時間になるからです。まだ、着手中も含め、完了になっていないタスクをすべて数えてグラフにします。

タスクの粒度を小さくするのは、異変に早く気づくためです。タスクが大きすぎるとデイリースクラムで確認したときに、数日タスクが着手中になります。すると、タスクが移動しないことに課題感を持ちません。そのため、タスクの大きさは、1営業日で終わる大きさ以下にしておくとよいです。こうしておくと、2日間同じものに継続的に取り組んでいたら何かトラブルがあったのではないかと気づくことができるようになります。

もっと詳しく知りたい方へ

第3位 PBI（やること）の粒度が大きすぎる

第3位は、「PBI（やること）の粒度が大きすぎる」です。こちらは、放っておくと進捗が分かりづらいどころか、スプリント中に価値を提供できる可能性が低くなったり、リリースの頻度を下げてしまう可能性もある重要な問題です。早急に改善しましょう。

判断方法

PBI（やること）の粒度が大きすぎることが原因の場合は、見破るのは簡単です。見積もりをするときに、大きさに幅がある場合です。プランニングポーカーをしている場合、1や2の見積もりもあれば、13や20の見積もりもある場合です。

解決策

こちらは、PBIの粒度が大きすぎることが原因なので、大きなPBIを複数のPBIに分割することで解決します。顧客に価値がある粒度でPBIを分割します。分割の方法は、INVESTと呼ばれる分割手法が良いとされています。以下の項目の頭文字を取ってINVESTです。すべての内容を満たせるようにPBIの分割をしていきましょう。

  • Independent 独立している

  • Negotiable 交渉可能

  • Valuable 価値がある

  • Estimable 見積もり可能

  • Small 小さい

  • Testable テスト可能

もっと詳しく知りたい方へ

第2位 過剰に分業している

第2位は、「過剰に分業している」です。これは、フロントエンド、バックエンドなどで分業している場合や、1人1PBIを担当しているチームで発生しやすいです。

過剰に分業することの問題は、すぐに価値を産まない仕掛りの製品ができてしまい、不要にメンテナンスコストがかかってしまうことや、スプリントが変わればPOが優先順位を変えたい場合も多いわけですが、着手中のものが多ければ途中破棄する決断に至りづらくPOの意思決定にマイナスの影響を与えます。

判断方法

過剰に分業している問題を見破るのは簡単です。スクラムボード・タスクボードの着手中のPBIの数や、タスクの数を確認すればよいのです。着手中のPBIの数がチームメンバーの数と同じかそれ以上なら過剰な分業と判断できるでしょう。

解決策

解決策は簡単で、複数人で1つのPBIや1つのタスクに取り組めばよいのです。複数人で1つのタスクに取り組むためにはどうしたらいいか？と気になる方もいるかもしれません。そういった場合は、ペアプログラミング・モブプログラミングを利用するとよいでしょう。コードレビューのコストが下がったり、設計の手戻りが減ったりと案外コストが大きくなりづらいものです。

また、チームでルールを作り、同時に着手できるPBIの数（WIP制限）を決めるとよいでしょう。

もっと詳しく知りたい方へ

第1位 手戻りが多い

第1位は、「手戻りが多い」です。これに該当する方は、この記事を読む前から大きな課題感を持っている方がほとんどかと思います。これは、進んだつもりが進んでいなかったとなるのでとても影響の大きい課題です。さらに、開発者のモチベーションを大幅に下げたり、POのガッカリ感をもたらしたりとマイナスな影響が大きいです。

さらに、コミュニケーションの少ないチームであれば、スプリントレビューでPOにチェックしてもらい受け入れ拒否されてしまうと、そのスプリントでやった成果が大幅に失われてしまうことも珍しくありません。早急に改善すべき状態です。

これは、POが忙しすぎたり、POと開発者の関係が良くなかったり、することでコミュニケーションが十分に取れていない場合や、PBIの受け入れ条件を明確にできていなかったり、POが求めていることが伝わっていなかったりする場合に起こります。

判断方法

手戻りが多い場合の判断方法は簡単で、開発者が作ったものがPOに受け入れをされていないでやり直しになっているものがいくつもあったら要注意です。

解決策

解決策は、要因によって色々あります。POが忙しすぎる場合は、手戻りのデメリットを伝えて開発者とのコミュニケーション、PBIをチェックしてもらう時間の優先順位を上げてもらう、それでも厳しければ、SMや開発者がPOの業務を一部巻き取って、POの時間を確保する必要があるでしょう。

POと開発者の関係が良くない場合は、ドラッカー風エクササイズや偏愛マップなどのチームビルディングや、チームランチや、飲み会など、関係性を向上させる施策に取り組むことで改善します。

作るものの理解についての齟齬がある場合は、スクラムイベントであるプロダクトバックログリファインメントの時間を少し長くして、対話の時間を十分に確保したり、話したことをチケットに記入して認識をあわせることが効果的です。

実は、POの中で作るもののイメージが十分でない場合もあると思います。そういった場合は、SMがPOの壁打ち相手になって、一緒にイメージを固めていくことができれば、かなり解消しやすくなります。

もっと詳しく知りたい方へ

まとめ

以上、スプリント中にタスクが終わらないケースを重要度順にランキング形式でお伝えしてきました。時間が取れる方は、すべての「判断方法」の項目を読んでいただいて、自分たちのチームのタスクが終わらない事象が、重要な課題をはらんでいる可能性がないか確認いただけたらと思います。

この記事が気に入ったらサポートをしてみませんか？