こんにちは。asatoです。
スプリントレビューって何気に難しくないですか？
スクラムガイド（2020）スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。
スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、⾃分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者は次にやるべきことに協⼒して取り組む。新たな機会に⾒合うようにプロダクトバックログを調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。
スクラムガイドを読んでも、いまいちどうスプリントレビューを実施すればよいか…とりあえずデモするか…
ということで、僕はこんなスプリントレビュー好きだなーという、とても個人的なお気持ちを表明します！
明るい
まず、明るいこと。
いや、パーティみたいにはっちゃろ！ってわけではないですよ。でもたまに、すごく参加者が緊張してる会ありますよね。レビューって言葉が悪いのかもですが、いかにも誰かにジャッジされる会みたいに感じられる会。
これから行われる会は、スプリントの成果をまずはみんなで喜び、先々のスプリントでよりゴールに近づけるようにみんなで意見を出し合うような会なわけです。そういう準備はできているでしょうか？
スプリントレビューの主催者はチームです。チームの準備と立ち振る舞いがこの会の雰囲気を左右し、この会の成果にも響きます。
まぁそんなことは置いといて、しんどいスプリントを走り抜けてきたのですからゴールテープは笑顔で切りたいじゃないですか。明るい会にしましょう。
プロダクトゴールやスプリントゴールから始まる
スプリントレビューでは、スプリントの成果を検査します。そして、そもそものゴールを知らなければ成果は適切に検査できません。
プロダクトゴールやスプリントゴールから始まることで、フィードバックの方向性を定めます。チームが目指しているゴールに意識を集中させます。
これは、ステークホルダーに向けてもそうですし、チームメンバーに向けても機能します。最初に参加者全員でゴールの方向に意識を向けておくことで、成果をゴールに近づける議論ができるようになります。
機能紹介より課題紹介
デモをやる前に、軽く機能の紹介をすると思います。「〇〇機能を作りました」とか「〇〇できるようになりました」とかです。
僕はそれよりも課題紹介が好きです。「〇〇な人の〇〇という課題にアプローチしてみました」みたいなやつです。どんな人のどんな課題を解決しようとしているのか、です。
機能の話になると、デモをみている人も視野が狭くなる傾向があるなと感じています。「〇〇機能」と言って不足はないかに意識が集中し、細かい配置や配色などにも目が行きます。
課題の話になると、体験寄りの視点になります。脳内の「〇〇で困っている人」がそのデモの流れを通してその課題を解決できるかな、ということを考え始めます。課題を解決するための過不足や配置・配色の話に寄ります。
先ほどのゴールと同じように、フィードバックを有効な方向に揃えることができます。
ユーザーになりきってデモ
課題紹介からの流れで、そのユーザーになりきってデモをするのも好きです。
開発に深く関わった人であれば、どういうユーザー行動を想像して作ったのかが参加者にとって明確になります。説明的ではなく、その人になりきってです。自分で作ったはずなのに、「あれ？ここ変じゃない？」みたいのが見つかったりします。
開発に関わっていない人がやれば、よりユーザーに近い操作になり、どんなところはスムーズでどんなところは躓くかが明らかになります。本当のユーザーならなおさらです。それはもうユーザビリティテスト。
どっちのパターンも好きです。
これはデモで「多くを語らない」という意味です。開発をしていると色々な意図や折衷案、しがらみなどがあります。それが先に明らかになるとフィードバックが鈍ります。仮に絶対技術的に無理なことでも、フィードバックがあったという事実は貴重です。逆にフィードバックがなかったという事実も貴重です。フラットに見てもらいたいものです。
Doneしたものだけに絞られている
DoD（Definition of Done）を満たしていないものが紹介されることもよくあると思います。ある程度まで進んでいるので、それを早く見せてフィードバックがほしい気持ちはわかります。でも、Doneしたものだけに絞っていた方が好きです。
これは結構好みなのかもなーと思うのですが、Undoneはどれだけ進んでいてもUndoneなんだと思います。
スクラムガイドは「ゲームのルール」と書かれています。スプリント中にDoneできたかどうかというのは、ひとつこのゲームを面白くしているポイントなんだと思います。ここを厳格にすることで課題発見をしやすくできると僕は考えています。
ローカル環境で見せて、あとはここちょっとやるだけ、テストするだけ、デモ環境にデプロイするだけ、みたいなことありますよね。でもお披露目するとUndoneだった悔しさが薄れてしまうと思うんです。
あと、その残された5%の作業でめちゃくちゃつまずく可能性もありますしね。
なので、Undoneは全員がUndoneだと心底理解できるようにレビューにはあげないほうが好きです。どうしてもその日付近でその人たちに見せないといけない事情があるなら、Doneしてから次のスプリントレビューを待たず、それだけデモする時間を設けるのがいいと思います。
フィードバックに対する結論を出さない
これは割と意見分かれるかも。スクラムガイドの「今後の適応を決定すること」に違反しているようにも読み取れますね…
僕はスプリントレビューをあまり議論の場だとは思っていません。成果のお披露目とフィードバックを集める会だと思っています。ので、フィードバックに対して「やる or やらない」を決めるための議論は後に回して、フィードバックの背景を深堀ったり、他のフィードバックを聞き出す時間にしたいなと考えています。
対応するかどうか、ソリューションは何がいいかに責任を持っているのはチームだと思っています。そしてそれは、スプリントプランニングやリファインメントのアクティビティで実施すればよいのではないかなーという考えです。
チーム内だけでスプリントレビューをやっている場合でも一緒です。スプリントレビューのフィードバックも他のプロダクトバックログアイテムと同じフローに乗ったほうが落ち着いて公平に判断できると思ってます。
今後の話がある
今回のスプリントの成果発表だけでなく、今後の目標や見通しの話があると、いいなと思います。
今段階ではこういう方向にプロダクトを進化させようと思っているとか、こういうユーザーのこういう課題にチャレンジしようと思ってるとか。少し中長期的なプロジェクトを進めているなら現段階でのリリースの見通しとかが共有されていると、次も期待できるなーって感じがします。
おわり
はい。完全に個人の好みです。でもこういうスプリントレビューをしているとき、スクラムの価値を感じられました。
いろんなチームがいろんな工夫やいろんな当たり前で自分たちのスプリントレビューの価値を高めていることと存じます。そういうのいっぱい知りたいなー。
サポートもお待ちしております！
