スプリントの回転の中で実現しているのは、「価値」か、それとも「進捗」か
アジャイルで各種定義されていること、例えばスクラムイベントやバックログといった概念で、何を実現しているのか、そこにどんな意味があるのかを考えてみよう。
さっそくイメージにしてみる。
リファインメントで行っていること
プロダクトバックログとは一体何か。そこでリスティングされるものは、「これが実現できたら価値につながる」という価値の候補である。あるいは、「これは価値がありうるかもしれない」という価値の仮説である。存在してしかるべきという機能は前者にあたり、本当に効果があるかどうかは分からず、仮説を含んでいるという機能は後者にあたる（前者は一元的品質、後者は魅力的品質のイメージ）。
価値候補だけでバックログが構成されている場合は、「とにかく機能を片っ端から実現していけば良い」という開発になる。主眼は、着実に機能が作成されているか、機能の品質は期待通りか、という点になる。
もちろん、「これが実現できたら価値につながる」としているのは作り手の想定であって、現実はそうとは限らないという可能性がある。バックログが価値候補なのか、価値仮説なのか、その判断の当たり外れは今回の論点からはずれるため置いておく。
スプリントで行っていること
リファインメントでバックログを整え、スプリントプランニングで作成対象を決定する。その後、スプリントにおいてインクリメントの作成がチームによって進められる。チームおよび、プロダクトオーナーは、徐々に出力されていくインクリメントをもとに状況の把握を行う。「この調子で行けば、予定していたインクリメントは作りきれそうだ」「いや、一部が積み残しとなりそうだ」そうした状況判断を行う。
同時に、スプリント中に完成されていくインクリメントは順次、その確認を行う。バックログで想定していた内容が作成されているかを、まずは確認しなければならない。
スプリントレビューで行っていること
完成が確認されたインクリメントについてレビューを行う。チーム、プロダクトオーナー、ステークホルダーが場に集まり、インクリメントに対するフィードバックをあげる。内容としては、作成された機能やインターフェースに対する改善点が主となる。レビューで収集した改善点は次のスプリントに向けて、バックログの候補となっていく。
スプリントレビューはもう一つの活動がありうる。バックログ時には仮説だったことが、実際に機能・インターフェースとして認識、操作できるようになるため、仮説の評価を行うことができる。レビューの時点で、一定の検証が行われ、必要に応じて仮説がアップデートされる。仮説自体は、「仮説キャンバス」で捕捉し管理していくと良い。
プロダクトレビューで行っていること
プロダクトレビューとはスクラムイベントではない。私が作った概念である。
スプリントレビューでは統合されたインクリメントを検査するものの、現実的には前回スプリントからの差分を確認するに留まることが多い。作成しているものの「全体」を捉え直す機会が別になければ、差分最適は担保されても、「全体」は置き去りになっているという状況がありえる。
プロダクトレビューでは、バックログ上で価値の候補として認識していた機能を実際に試行して確かめる（より現実の利用に近い状況で試す、ウォークスルーする）。同時に、価値の仮説に関しては検証を行う。単に機能の動きや使い勝手を試すというよりは、立てていた仮説が立証できるかのテストを行う。プロダクトを実際に利用する人たちを招いて、疑似利用してもらう。その結果から仮説の確からしさを判断する。
もちろん、プロダクトレビューの結果からも改善点の立案や仮説の再定義を行う。これらは、リファインメントでバックログに仕立てたり、保留の判断を行う。
この流れから言えることは何だろう？ 二つ触れておく。一つは、ここで言う「仮説の検証」はもちろん、「価値候補の改善」も行っていないようであれば、「進捗」を追いかける開発でしかないということだ。それが悪いわけではない。ただ、意図しているかは確認したほうがよい。
もう一つは、「価値候補の改善」に終始した開発になっているとしたら、価値仮説も織り込んでみてはどうか、ということだ。あってしかるべきの機能の開発と改善に全振りする、つまり当たり前品質にあたる機能の開発に集中しなければならないという時期も確かにある。一方で、そこで終始しているだけではプロダクト的には勝てない。
さて、手元のバックログには何があがっているだろうか。作ったものに対する改善策だろうか、あるいは検証結果に基づく期待の価値候補だろうか。それとも、いわゆる、"must (何が何でも作らないといけない)"と呼ばれる機能群だろうか。