概要
2020年9月13日の「スクラムガイドを読み解いてみよう」にイベント参加しました。2回目の参加となります。
前回の参加レポートはこちら。
スクラムガイド変わるってさ:「スクラムガイドを読み解いてみよう」に参加しました
どのような会か
スクラムガイドを読み、パーソナリティの皆さんが読んだ部分について議論されています。
Zoomで行なわれ、参加者もチャットから質問が可能です。
記事内容
本記事では、パーソナリティが話されていた内容と僕の感想や意見を織り交ぜて書いております。
今回のイベントで話されていたのはスクラムガイド「スクラムイベント」の章でした。
この記事では主に以下について主に書きます。
- スクラムのスプリントのタイムボックスについて
- スクラムのスプリントゴールについて
- スクラムのスプリントの中止について
イベントのタイムボックス
スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1 か月以下のタイムボックスである。開発中はスプリントの長さは常に一定である。
スプリントのバックログが終わったら次のタスクをとるというおかわりシステムというのがあるが、早く終わったときに休めないのでよくないのではという話になりました。
しかし早く終わったときタスクをしないというのはやりにくい、、、
スプリントが終わったらGo to beachしてもいいのか！？
おかわりシステムのもう１つの問題として、スプリントにチケットを入れすぎると、チケットが終わらないため失敗(フィードバック)がわかりやすいのに対し、チケットを入れなさすぎて終わらなかったというフィードバックをおかわりシステムが隠してしまうということが意見としてあった。
余った時間は技術的研鑽に使ってという方法もあるが、技術的研鑽は余ったからやるんじゃなくて計画的にやるべきではないかという話が出た。
参加者へのスプリントの長さのアンケートでは、1週間と2週間で半々くらいでした。
3週間スプリントを経験した方もいるみたいです。
感想
僕が経験したのは1週間と2週間スプリントです。
スプリントの長さといえば「フラクタルスプリント」というのもよく聞きますね。
KDDI DIGITAL GATEでは1日のスプリントをやったりしているらしいです。
わずか1日でサービスを試作、KDDIのデジタル変革
スプリント中に祝日があったらどうする？
よく疑問に思うので調べてみます。
2連休が1週間スプリントにあると3日のスプリントになるので、我々だと次のスプリントと一緒に1スプリントにしたり、しなかったりします。
日にちが少なくてベロシティも下がるように見える問題もあります。
ドンピシャの回答がアジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (2)にありました。
@ryuzeeさんのブログですね。
スプリントプランニングやスプリントレビューは定期的に実施することにメリットがあるので、基本的に曜日を固定することをお勧めします。
これはよくわかります。イベントのリズムを作るという観点ですね。
つまり祝祭日があった場合は、その分スプリントの稼働日数は減ります。 開発チームが使える時間も減るので、計画ではそれを考慮して取り組むプロダクトバックログの項目を減らすのが一般的です。
スプリントの日数を減らしても曜日を固定するやり方で良さそうですね。
ベロシティのブレの心配はありますが、3スプリントの平均で次のスプリントの予定を立てることでカバーされるのと、ベロシティはあくまで目安と考えれば問題ないです。
1週間スプリントはなぜ良いか
たまたま発見したのですが、同じく@ryuzeeさんのブログで、アジャイルコーチはなぜ1週間スプリントを勧めるのかというものがありました。
ここでは以下が列挙されています。いっぱいいいことがありますね。
項目と僕の感想をテーブルにしてみた。
| 項目 | 僕の感想 |
|---|---|
| レトロスペクティブ（ふりかえり）が頻繁にあるので改善が進む | フィードバックは早い方がいいですね |
| 計画の精度が高くなる | これはその通り！チケットも小さくなるので見積もりやすいです |
| 例え失敗しても一週間で済むので実験しやすい | 1週間だけやってみようというのは僕もよく使います |
| ベロシティの数字がすぐ出るのでやる気になる | 数字が出ると嬉しいですね。悪い数字が出てもすぐ取り返せるのも良いです |
| 中だるみする余裕がない・リズムがよい | 確かに2週間スプリントの頃は中だるみがありました |
| 一週間で収まるサイズのプロダクトバックログ項目にするので明確な完成を定義しやすい。従ってプロダクトオーナーの受け入れを取りやすい | 小さいのでDoneにしやすいですね |
| スパイクが必要なプロダクトバックログ項目が明確になる | ここはあまり考えたことがありませんでした。我々はスパイクの場合もバックログにしてやっていますね |
| プロダクトオーナーが変更を我慢しやすい | これはありますね。1週間で差込が入ってしまうってよっぽどですよね(結構ある) |
| ごまかしが効かない | ふむふむ |
スクラムイベントの準備は必要？
必要です
management3.0カンファレンスではオンラインのミーティングは短くするべきで。非同期コミュニケーションを使うことが勧められていたとのこと。例えば話す内容を事前に動画にして配信しておき、先に見ておいてもらうなど、、
感想
僕も準備はするに越したことはないと思っています。
僕がよくやっていたのは、
- リファインメントの時にプランニングポーカーやプロダクトバックログ画面の準備
- 振り返りの時の、ホワイトボードと付箋の準備や流れの確認
- リモートでは画面の準備や余計な画面やタブを消したり
こんな感じですね。
準備をすると、すぐ開始できて、みんなの時間を大事にできるため良いです。
タイムボックスやスケジュールの確認もファシリテーションの円滑化に有効です。
どんなけグダらないかで参加者の集中力やミーティングの満足度が変わると思います。
事前の想定外事象のシミュレーションを頭の中でやり、プランBみたいなのを用意しておくとグダる確率を減らせるので成功させたい時は想定外事象への対策も行うと良いことがあります。
スプリントゴールって具体的に何なの？
スプリントゴールとは何かわかっていないので質問しました。
聞いてみるとみなさんもはっきりとは答えられない様子。こうやって作りましょうという方法論なども無いようです。
僕もそうですが、具体的にとなるとなかなか答えられず。考えたくないような部分という話も出たくらいです。
しかし、「バックログを全て終わらせる」という目標は絶対に違うという意見がありました。
スプリントゴールの参考資料としては、以下が紹介されていました。
- 7 Sprint Goal Patterns for Building Great Teams, Part One
- 7 Sprint Goal Patterns for Building Great Teams, Part Two
スプリントゴールは総まとめのテーマでも無い。
目指すことによってチームが加速しやすくなる装置を目指すと良いのではないか。
また、それはストレッチゴールでは無い方が良いのではという話がありました。
再計画に必要なもの、結局何を達成すべきだったのかというところを明確にできるといいのではという意見もありました。
感想
みなさんスプリントゴールについて難しく思っているということで、安心しました。
ここではスプリントゴールの理解を目指して以下について調べていきます。
- スプリントゴールとは？
- なぜスプリントゴールが必要か？
- スプリントゴールの例
スプリントゴールとは？
スクラムガイドでスプリントゴールの定義は以下です。
スプリントゴールはスプリントの目的の集合であり、プロダクトバックログの実装によって実現するものである。
これは開発チームがインクリメントを構築する理由を知る指針となる。スプリントゴールはスプリントプランニングで作成する。
スプリントゴールを設定することで、開発チームがスプリント終了までに実装する機能を柔軟にできる。選択したプロダクトバックログアイテムは、一貫性のある機能として届けられる。それがスプリントゴールになることもある。
スプリントゴールがあれば、開発チームは一致団結して作業ができる。開発チームが作業するときには、スプリントゴールを念頭に置く。スプリントゴールを達成するために、機能や技術を実装する。開発チームの予想と異なることが判明した場合は、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。
書籍からも引用してみます。
スクラム現場ガイド p371の引用です
POは次のスプリントで何を実現してほしいか説明する。スプリントプランニング・パート1の終了時にはチームがスプリントゴールを定める。一文でスプリントの成果を言い表したものだ。そのようなスプリントゴールがあれば、あとで幅と深さについて疑問が出てきたときに役立つ。スプリントゴールと直結する作業でなければ、そのスプリントでは実施しないのだ。
プロダクトオーナーがスプリントの間にやり遂げたいと考える目標についての概要レベルのサマリー。プロダクトバックログアイテムの特定のまとまりとして表現されることも多い
またp325にスプリントゴールの洗練というのが書かれています。
スプリントゴールとは、スプリントにおけるビジネスの目的と価値をまとめたものである。
結局スプリントゴールとは
- スプリントにおけるビジネスの目的と価値を１文でまとめたもので、実装、変更の際の方針となる
- POが責任を持ち、スプリントプランニングで決定
なぜスプリントゴールが必要か
Published Patternsでは、以下が述べられています。
The objective of a Sprint is to deliver value to the stakeholders. However, simply following a list of Sprint Backlog Items (SBIs; e.g., tasks) does not necessarily result in the creation of the greatest value possible.
スプリントの目的は、ステークホルダーに価値を提供することです。しかし、単にタスクをバックログアイテムをこなすことは、必ずしも最大の価値を生み出しません。
アイテムのリストは、個人のタスクとしてこなしてしまいます。しかし、それはチームの異なる視点からくるイノベーションの創出を薄めてしまうということが書かれています。
エンジニアはタスクをこなすことに集中してしまいますが、実は本当に達成したいのは顧客に価値を提供することであるというのを思い出させるのが、スプリントゴールの役割なのだと理解しました。
経験上、スプリントゴールを設定しないスクラムチームには共通点があります。
それは、開発チームが「下請け扱いされている」または「ビジネスに関心が薄い」ことです。
と述べられています。確かにわかる気がします。
先ほど紹介したPublished Patternsを読むとスプリントゴールが必要な理由が色々とわかります。
まとめると、スプリントゴールが必要なのは
- チームメンバーに達成すべきなのは、タスクの完了ではなくスプリントゴールで示す価値の提供であると示すため
- １つの目標を共有し、チームが一致団結するため
- 個々のタスクをなぜ作るかを開発チームが知ることでモチベーションを高めるため。(３人のレンガ職人)
- 修正や判断が必要な時に方針とし、意思決定に柔軟性を持たせるため
スプリントゴールの例
例がないとわからないから集めてみます。
7 Sprint Goal Patterns for Building Great Teams, Part Oneで紹介されている例の一部を以下に記載します。
| 設定方法 | スプリントゴールの例 | 解説 | どのようなときに使うか |
|---|---|---|---|
| より高い目標 | 最初のスプリントで追加された価値を顧客に向けてデモする。 | ソフトウェア開発という最優先項目を、顧客価値、タイムボックスなどのより高い目標で包んでいる。 | チームが価値観を共有していないとき。 |
| メタファー | 実をつけるリンゴの木は根が深い、しかし初年度でも１つのりんごが実る | 最初はアーキテクチャや技術への集中が重要だが、その途中でも何らかの価値を届けることは可能だ。 | チームに何らかのインスピレーションを与えて、モチベーションを高めたいとき |
ちょいと意味がわかりにくいですが、色々な例が紹介されており、インスピレーションを受けるのに良いと思います (part twoにも例あり)。
Sprint Goals — What Do They Really Need (With Examples)では、いくつか例が紹介されていてゴールとともにスプリントバックログへの落とし込み方が書かれています。以下に例の一部を記載します。
スプリントゴールの例: ログインページのインターフェースをリファクタして、ログインページのコンバージョンを25%上昇させる
スプリントバックログに落とし込むと、
- 他の5つのプロダクトでどのようにログインをハンドリングしているか調査する
- ログインインターフェースを書き直し、2つ新しいのを作る
- A/Bテストを始める
この例は目標値があってわかりやすいですね。
このスプリントゴールとこのバックログでやれば、開発メンバー内でも会話がいっぱい起きそうな感じがします。
なぜなら目標が１つで全員がそれに向かっているからですね。
スプリントゴールの例: 良いフィードバックの仕組みを提供することで継続率を上昇させる。
スプリントバックログに落とし込むと、
- フィードバックボタンをいくつかのビューに加える
- クライアントのクラッシュ時に自動的にフィードバックできるシステムを導入する
- サポートが終わったらお客様にフィードバックを聞くメールを送る
- ネットにあるレビューを分析して、プロダクトバックログを更新する。
こちらは数値目標がなく残念ですが、相変わらずわかりやすいですね。
こういう風にスプリントゴールを設定して、それに関連するスプリントバックログのみをスプリントで作業すればかなり集中した開発ができそうです。
品質とは何なのか？
スプリントでは、
品質目標を下げない。
この文章の意味について議論がありました。
DoD(完成の定義)を変えないことだという意見がありました。
しかし、結局ここでいう品質(quality goal)とは何かという話に。
感想
僕もDoDを守るという意味だと思っていました。
品質については割と気になったので、少し調べてみました。
品質について
ISO 9000
ISO 9000が品質に関する国際規格のようです。最新は2015年のもので、ここでは**「対象に本来備わっている特性の集まりが、要求事項を満たす程度。」**とあるようです。
でも意味はわかりませんw。
品質の種類
こちらの品質管理の知識では品質の種類について以下があると述べています。
| 種類 | 内容 |
|---|---|
| 企画の品質 | 顧客ニーズを反映している製品か |
| 設計による品質 | 製品規格や品質規格 |
| 購買品・購入品の品質 | 原材料や部品の仕様や条件 |
| 製造工程における品質 | 不良率など |
| 検査における品質 | 検査項目や管理基準 |
| 使用品質 | 機能や仕様 |
| サービスの品質 | アフターサービスなど |
工業製品感が強いですが、参考にはなりそう。
JIS 25010:2013
JIS 25010は日本の工業規格で経済産業大臣が制定とのこと、ソフトウェアにも対応しているようです。内容もわかりやすく使えそうでした。
例えば4.1にある利用時の品質モデルでは、以下が列挙されています(参考)
| 有効性 | 明示された目標を利用者が達成する上での正確さ及び完全さの度合い |
| 効率性 | 利用者が特定の目標を達成するための正確さ及び完全さに関連して，使用した資源の度合い |
| 満足性 | 製品又はシステムが明示された利用状況において使用されるとき，利用者ニーズが満足される度合い。 |
| リスク回避性 | 製品又はシステムが，経済状況，人間の生活又は環境に対する潜在的なリスクを緩和する度合い |
| 利用状況網羅性 | 明示された利用状況及び当初明確に識別されていた状況を超越した状況の両方の状況において，有効性，効率性，リスク回避性及び満足性を伴って製品又はシステムが使用できる度合い。 |
一部を紹介しましたが、詳細になるとわかりやすくなっていて、使いやすそう。4.2の製品品質モデルにも注目です。
品質目標は自分たちで決めるもの
品質について少し書きましたが、元の品質目標というものに関しては、
Quality Goals: Define and Measure Quality of your applicationで、品質目標(Quality Goals)はQAが所有するが、チーム全体で決めるべきと述べています。
自分たちのアプリケーションの品質の目標だと思うので、自分たちで決めるしかないですよね。
やっぱり品質目標というのはDoD(完了の定義)に近いと思いました。
どの品質に関して設定するかについては先ほど述べた規格が参考になりそうですね。
スプリントの中止
スプリントの中止については、ほとんどの人が経験していなかったです。
唯一経験された方のスプリント中止の要因は、スプリントの初期に開発予定だったアプリの乗るはずのスマートウォッチのOSの廃版が決まったからとのことです。
もう一回中止の経験があったようで、その方がスクラムマスター始めたての頃に、「Scrumのルールを厳密に守るなら中止すべき」として、中止してしまったそうです。やらかしたとおっしゃっていました。
感想
僕も常々スプリントの中止とかありえるのか?と思っていたので、経験談が聞けてよかったです。
長くスクラムマスターをしていてもほとんど経験しないことなので、無闇にスプリントの中止はしないが吉ですね。
スプリントの中止はどのような時にやるかというと、
会社の方向性や市場・技術の状況が変化すると、スプリントゴールは古くなってしまう。状況を考慮して意味がなくなったと思えば、スプリントを中止すべきである。
--- スクラムガイドより
中止判断はスプリントゴールによるため、スプリントゴールの設定はしておく必要がありますね。
最後に
今回のイベントで一番良かったのは、パーソナリティの皆さんもスプリントゴールというものに対して完全にクリアになっていないことがわかったことです。
僕だけがスプリントゴールについてわかっていないのではないかと思っていたので、相場感がわかって良かったです。
これがコミュニティの良さだと感じており、みんなで共感して議論して解決に向かえるのがいいですね。
質問に真摯に対応いただいたパーソナリティの皆様に感謝です。