スプリントゴールとプロダクトバックログアイテム(PBI)、PBIの実現について（WHY, WHAT, HOW）

ふたつのゴール

スクラムガイド2020によれば、スクラムには２つのゴールがあります。
プロダクトゴールとスプリントゴールです。

ボルダリングで遠くにゴールがある場合、ゴールに向かうためにどうするでしょうか？
次に四肢のうちどれか１本を届く範囲の石に伸ばすと思います。

その四肢を次に伸ばす石がスプリントゴールであり、あそこまで行こうと思い定めているゴールがプロダクトゴールです。

スプリントにおけるスプリントゴール

スプリントではスプリントゴールはなくてはならない存在です。
なぜならばスプリントで最も重要なイベントであるスプリントレビューは、スプリントゴールがないと成り立たないからです。

スプリントレビューでスプリントゴールを達成できるか、達成のためにどんなプロダクトバックログアイテム(PBI)を積み上げるのか。それぞれのPBIで何をするのか。PBIをどのように実現するのか。
それを決めるのがスプリントプランニングです。

スプリントにおけるスプリントプランニング

スプリントプランニングではスプリントの目的であるスプリントゴール（WHY）のために、ゴールを達成するためのプロダクトバックログアイテム（WHAT）をどう積むか。
積んだプロダクトバックログアイテムをどう実現するか(HOW)を決める場でもあります。
※スクラムガイドに準拠していますが、私のチームの場合なので他社では違うかも知れません。

スプリントゴールの設定

スプリントゴールはプロダクトオーナー(PO)が原案を出します。
最初にスクラムチームはキャパシティに応じてPBIを積み、積んだPBIでスプリントゴールを実現できるかを考えます。
キャパシティに応じて積んだPBIでスプリントゴールが達成できない可能性が高い場合はPOにスプリントゴールの代替案を提案します。
※スクラムガイドに準拠していますが、私のチームの場合なので他社では違うかも知れません。

スプリント中にスプリントゴールの変更は私のチームでは許容されないため、スプリントプランニングでのスプリントゴールの設定とスコープとなるPBIの設定は重要です。
※スプリント中のスプリントゴールの変更は可能派と不可能派がいます。スクラムガイドには特に定義はありません。

プロダクトバックログアイテムの立ち位置

プロダクトバックログアイテムの記述とプロダクトバックログの中での優先順位、プロダクトゴールとスプリントゴールこそがPOの意思表示です。
スクラムチームはそこからPOの意図を読み取ります。

ただしプロダクトバックログアイテムはスプリントゴール達成のためにPOが考えた解の一つです。

しかしPOは技術に明るいわけではありません。技術に明るくまたその限界を知るのは開発者です。
同じ目的を達成できて、よりよい別解があるならスクラムチームはやるべきことを変えてよいでしょう。
達成すべきはスプリントゴール（WHY)であり、WHYが達成されるならWHATは比較的柔軟に変更できます。

PBIのタスクへの分解について

タスクの分解については「１日で終わるサイズであればよい」とされます。
タスクの見積は理想時間でなされ、フィボナッチ数が1,2,3,5,8,13...であることを考えれば、タスクの見積はおおよそ5理想時間までが適正と言えるでしょう。
それ以外は「スクラムチームはブラックボックス」であるので、どういう切り口でタスクをカットして、どう実行計画を作って、どういう粒度でタスクチケットを起票するかはスクラムチームに一任されます。

PBIのタスク分解のアンチパターン

従来型の開発に慣れた人間からするとスクラムにおいてはPBIは極めて曖昧なまま丸投げされると感じるでしょう。

ユーザーストーリーのような曖昧な書き方のまま渡されます。
従来型の開発に慣れた人間からするとこの曖昧さは耐え難いように感じるようです。

するとどうするかと言うと、HOWをまず先に確定させて、そこからWHAT(PBI)を決めるのです。
はっきり言ってアンチパターンです。
WHYを達成できるならWHATもHOWもスクラムチームに一任されているのに、HOWから始めようとするのです。
HOWを十全に達成したのに、WHATがWHYにつながっておらず、ゴールを達成できなかったらどうするのでしょうか？

スクラムにおいては、開発者は順番にWHYからWHAT, HOWを見ることを求められます。
ところが経験の浅いスクラムチームではまずHOWありきで物事を決めようとします。
ひどい時はHOWからWHATを決めようとするでしょう。

HOWへの固執への処方箋

何をしていいか分からないから開発チームはHOWから決めようとするのです。
ですから何をすればいいのかをガイドしてやればいいのです。

私のチームでは受け入れの基準をテストケースの形で書くよう促しました。
またテストケースを書く際に画面遷移をラフなイラストや図で説明します。
リモートならパワポで雑な図を作るだけでも十分です。

すると「何をするか？」がはっきりします。
すると、そのテストケースを満たすために実装をどう切っていくか、を開発チームが考えることができます。

スプリント中のスコープの変更

バーンダウンチャートが理想線より実績線が上にとどまり、このままでは終わらない、となったときにどうするかです。
スクラムのセオリーに従えばスコープを落とします。
従来型開発に慣れた開発者はスコープを落とすことを嫌がりますが、スクラムではリソースとタイムボックスを固定している以上スコープで調整することになります。

この際気をつけることは「落としていいPBIは未着手のものだけ、仕掛中のPBIは落とせない」「スプリントゴール達成に必要なPBIは落とせない」という点です。
ではもし、現在スプリントに含めたスコープの達成がこのままだと難しく、未完了のPBIはすべてスプリントゴール達成に不可欠なものである場合どうすればいいでしょう？
答えは残業してでも頑張るしかありません。
なぜならスプリントゴールの達成はスクラムにおいて最も優先度の高いものの１つだからです。
それでもスプリントゴールの達成が不可能となればどうすればいいでしょう？
スプリントを中止することも選択肢に上がってきます。
スプリントゴールはスクラムの根幹の１つです。終わらなければどれだけスコープを落としても大丈夫、というのは典型的なスクラムに関する誤解の１つです。

HOWに固執するスクラムマスター

（話がそれますが）
開発者からスクラムマスターに転じたスクラムマスターもまた、問題に対してHOWありきで物事を考えがちです。
HOWありき、は従来の計画駆動開発に慣れたエンジニアにありがちな性質です。

しかしロジックがなければ他の人間を説得できず、周りを巻き込めず何もできないか、あるいは独善的に陥りがちな傾向があるように感じます。

その際もスクラムマスターにまずProblemをどう分解するか？を教えることから始めるとHOWに固執する症状は和らぐと感じています。