[アジャイル開発] スプリントゴールについて👀
Hideyuki Fujihara『スクラムブートキャンプ』を読んで気になった部分であったり、つらつらと考えたことについてまとめてみようと思います。
以下、そのまとめです。
Hideyuki Fujiharaスプリントゴールの定義を示す前に、最初に以下の項目についてどれがスプリントゴールとして機能するかについて考えてみます。
- バックログの〜をやる
- 〜を実装する
- 〜のために〜を作る
- 〜のために〜を作る、その為には最低限〜が必要だ
Hideyuki Fujiharaこの中でスプリントゴールとして機能するのは一番下だけになります。
最初のものは手段が目的化してしまっていて、
2番目はwhyがなく、
3番目はmustがないからです。
最初のバックログチケットは視点が低く、手段と目的が逆転してしまっている状態です。
バックログチケットはスプリントゴールに従属する存在であって、その内容に縛られる必要はなく、
より良い代替案があればそれに取り組むべきです。
古くなっている可能性もありますし、あくまでスプリントゴールを達成するためのコンポーネントとして捉えるべきかと思われます。
Hideyuki Fujihara2番目のwhyがない状態に関しては、
- ゴールが明確でなくボンヤリとしている
- ターゲットが絞り込めていない
このような状態にあるかと思われます。
副次的には、
- 濃淡がない(優先順位が正しく付けられていない)
こんな状態にもあるかと思われますし、
- mustなものとwantなものも明確になっていない
と言った状態にもなっていると思われます。
これはゴールが不明瞭であることが原因なので、
- これって何で必要だったんだっけ？
- それがあるとユーザーにとってどう良いんだっけ？
- それってどれくらい必要だったんだっけ？ etc...
こんな感じでそもそも論に立ち返ったり、
ユーザーストーリーのことを想起してMECEになっているかどうかを考えたりなど、
何を実現しないといけないのかを明瞭にする必要があるかと思われます。
早い話、
『なんで？』『どうして？』
と問い続ける必要があるんですね。
その過程で代替案が見つかったり、優先順位が低いことが分かったり、抜け漏れが見つかったりするので、
上記のような状態になっている場合はこのように考えてみても良いかも知れません🤔
Hideyuki Fujihara3番目のmustがない状態に関しては、
- このスプリントで絶対にやらなければいけないこととそうでないことを峻別出来てない
- 作りたいもの、提供したいものが絶対に満たしていないといけないものが何かが明確になっていない
- mustとwantを同一視してしまっている
- wantの濃淡を意識できていない
こんな状態にあります。
別の言い方をすると、
合格基準(合格最低点)が分からない状態
という感じでしょうかね。
ゴールは明確ではあるのですが、必達要件とそうでないものを区別できていない状態だとスプリントを効率良く回す際に支障が出るので、
これもまた明確にせねばなりません。
ただしこの時、アレもこれもと必達要件にしてはいけません。
スクラムチームが安全に、合理的に達成できる目標を超えている可能性があるからです。
その合理性を定めるにはベロシティとワイドバンドデルファイ（いわゆるプランニングポーカー）などのSP見積もりを用います。
上記により安全圏を定めることで、スプリント内の必達要件をより良く定めることができます。
厳しい場合は次のスプリントで取り組む、という感じにしたりします。
それでも期限内で必達であるとすればその期限を見直したり、
または期限内で開発するスコープを狭めたりします。
この時はmustを中心に考えますが、
mustの中での濃淡、たとえばリスク(発生可能性と影響度の乗算)の低いものをスコープから外すなど、
スプリント内での合格最低点を見直したりします。
勿論、場合によってはその追加もなされますが、
この場合はプロジェクトリスク、プロダクトリスクに起因していることもあるため、
リスクのモニタリングを強化する必要にあると思われます。
このように開発時のボトルネックの分析に繋げたり、
そもそものPJのゴールは何だったのか、
ユーザーストーリーで考えた場合のプロダクトの受け入れ基準は何だったのかなどの明確化や再定義などに繋げることも出来るので、
3番目の状態にある際はそれをより洗練させるようにします。
その洗練のためにも朝会が重要になってきますが、それはまた別の機会に。