こんにちは！
最近の気温変化について行けずすでに夏が恋しい佐土原です。
4月から以前より所属していたチームでスクラムマスターを勤めさせていただいています。
ここ数ヶ月のスプリント毎に出力されるバーンダウンチャートの変遷をログに取ってみました。
そのログを自分なりに考察していたものを整理してアウトプットしよう、というのが今回の記事内容になります。
まだまだスクラムマスター歴も浅く拙い考察内容も多いと思いますがよろしくお願いします！
※ 以降の内容のほとんどがスプリント毎に僕が考察していた文面をコピペして表現を整えた程度のものなので、概要だけ読みたい方は記事の終盤「まとめ」まで読み飛ばしてください！
スクラムチーム構成
- スクラムマスター 1名（自分）
- PO 2名（PO業務の移行期間につき2名体制）
- 開発チーム 4名
スプリントの期間は1週間で固定して行なっています。
バーンダウンチャート考察ログ
スプリント１
おきていた事象/やっていたこと
- スプリント開始時点で開発に着手できる状態ではなかった
- ストーリーが不明確（洗い出しができていなかった）
- スプリント期間中にストーリーの洗い出し/ストーリーポイント付与を行った
- 個々人が着手しやすいタスクから着手している
- そもそものストーリーの優先度づけがあいまい
- 優先度順に着手する意識がまだすこし薄い様子
- 優先度づけが話し合いのもとでなく個人の暗黙の判断で行われている
- スプリント期間中にストーリーの内容確認やポイント付与を行ったため作業時間が取れなかった
スプリント２
（JIRAの期間設定間違ってます…）
おきていた事象/やっていたこと
- スプリント終盤までストーリー消化できていない
- ストーリー間（タスク間）の関係性を考慮せずにタスクに着手していた
- Aが終わらないとBが完了できないのにBから着手していた
- 事前にAとBの関係性について話し合えていなかった
- ストーリー間（タスク間）の関係性を考慮せずにタスクに着手していた
- スプリント中にストーリーポイントが増加している
- データの関連性など事前に把握していないとその他のタスクも進まないものを考慮していなかった
- データ設計の部分のタスクを独立して切り出した
- スプリントプランニング時にそのようなタスクが発生しそうということを話し合えなかった
- 話し合えればそもそもデータ設計を後に回す判断もできたかもしれない
スプリント３
おきていた事象/やっていたこと
- スプリント終盤までストーリー消化が進まない
- ストーリーの細分化ができていない（ひとつのストーリーが重い）
- スプリントプランニング時に大きいタスクは細分化を促す
- ストーリーの細分化ができていない（ひとつのストーリーが重い）
- ポイントが増加している
- 担当者を変える必要があるタスクが追加に
- スプリントプランニング時に話し合っていればスプリント中の増加にはならなかったはず
- プランニング時に「このストーリーを完了させるには」の話をする
- 担当者を変える必要があるタスクが追加に
スプリント４
おきていた事象/やっていたこと
- スプリント期間中のポイント増加
- 一部メンバーのチケットで切られておらず暗黙のうちに取り掛かっていた作業を可視化
- プランニング前に直近なににとりかかるのかの確認ができていなかった
- デイリー時にも「ここにはないですがxxやります」系の話は拾っておくべきだった
- 差し込みでの開発タスク（プロジェクトのメインでない開発タスク）の優先度を上げた
- 優先度の意思決定するための関係者がプランニングで不在だった
- そもそもプランニングも長すぎた
- 大きいストーリーの分割に時間を割いていた
- 一部メンバーのチケットで切られておらず暗黙のうちに取り掛かっていた作業を可視化
- スプリント前半でのタスク消化が見られない
- ストーリーポイントのサイズが大きい？
スプリント５
おきていた事象/やっていたこと
- 一部担当領域の近いメンバー間でペアプロ
- スプリント終盤でベロシティが落ちきらなかった
- 作業を進める中で発覚する問題がいくつかあったことが原因
- プランニング時にタスクの詳細について話し合うことができれば回避できたかも
- スプリントプランニング時にサブタスクの洗い出しができていなかった
- 見積もりと実際の作業量が見合っていなかった
- →計画時のポイント積みすぎに影響
- 見積もりと実際の作業量が見合っていなかった
スプリント６
（またもやJIRAの期間設定間違ってます…）
おきていた事象/やっていたこと
- 9/6 開発外の作業で開発業務に取り組めず
- 事前に把握可能だった開発外タスクの見積もりを考慮できていなかった
- 開発の手を著しく止めることが想定される開発外タスクは事前に洗い出す
- 突発なタスクも大きく手を止めることが判明した段階でタスクとしてJIRAに加える
- 9/9 一部機能のリリースで障害が発生。その後1.5営業日ほど開発業務が停止 (~9/10いっぱい)
スプリント７
おきていた事象/やっていたこと
- 一部メンバーでモブプロスタート
- モブプロだと進捗効率が著しく落ちる
- 要因：
- そもそもモブはリソース効率は悪い
- もっとも今回はフロー効率すら上がっていないが
- モブメンバーの知識差について
- ジュニアなメンバーが混ざると講義形式になりやすい（進捗より教育・理解が優先される）
- ジュニアなメンバーがドライバーになる際に頭を使わずただ言われたことを書くだけになりやすい
- 作業効率は下がった上で、かつジュニアなメンバーの教育も効率的に進まない
- 教育重視であれば指導者:受講者が1:1もしくは1:多でなければ受講者側にとって心理的に安全な状態が生まれにくい
- ex) Aさんは教えてくれているがその間Bさんのリソースが余っている, 自分のせいで作業進捗が悪くなっている, 等
- 作業効率は下がった上で、かつジュニアなメンバーの教育も効率的に進まない
- 結論：
- モブ（3人）をペア（2人）+ソロ（1人）に変更
- 教育目的重視のペアと進捗目的重視のソロの組み合わせ
- 教育目的であればモブよりペアが適している
- 教育目的重視のペアと進捗目的重視のソロの組み合わせ
- モブプロだと進捗効率が著しく落ちる
- 迅速にモブプロの課題について話し合えた点はgood
スプリント８
おきていた事象/やっていたこと
- 全体的にこれまでに比べ安定してタスク消化が進む
- モブをペア+ソロに軌道修正
- プロジェクト終盤につきタスクの詳細度が高いものが多かった
- ユーザー対応もあまりなかった
- 一方で終盤あと少し落ちきらず
- タスクの中に一部実際の作業詳細を考慮できていない部分があった
- 完了の定義をストーリー、サブタスクともに設定
- ほとんどプラニング時点で設計をやるような状況に
- 一部メンバーのタスクが可視化されていなかった
- 翌スプリントから該当メンバーのタスクを可視化、完了の定義を明確に
- スプリントプランニングで納期までの機能の優先度の話できず
- プランニング前後の都合で時間が押していたこともある
- が基本的には自分のファシリテートミス
スプリント９
おきていた事象/やっていたこと
- 10/14(月)は祝日
- バーンダウンしていなくて問題なし
- 10/11 12:00ごろのタスクの上下はプロジェクト完了までの優先度を加味したタスクの分割＆入れ替え
- スプリント開始前のプランニングでのファシリミスによる影響
- うまくバーンダウンした要因と思われること
- ペア(2人)+ソロ(1人)をさらに解体
- フロント3人全員独立したタスクを担ってもらうことに
- プロジェクト終盤につき育成よりタスク消化の進捗を優先
- タスクが可視化されていなかったメンバーのタスクをチケット化
- 内容
- 技術的調査
- 不具合修正
- ユーザー対応
- 内容
- スプリントプランニング時点で詳細にタスクの設計を行った
- タスクの完了の定義
- サブタスクの発行
- サブタスクの概要や完了の定義を記入
- そもそもリリース終盤の時期的なものもあり、詳細度の高いタスクが多い
- ペア(2人)+ソロ(1人)をさらに解体
まとめ
スプリント中にストーリーポイントが増加する要因
- ストーリーの内容が不明瞭
- ストーリーの完了の定義が曖昧
- ストーリーに対するサブタスクの洗い出しができていない
バーンダウンしにくい要因
- ストーリーの粒度が大きい
- 機能要件レベルでPOとエンジニアの認識が合っていない可能性が高い
- スプリントプランニング時に完了の定義や仕様の詳細について話し合いができていない
- 完了の定義が曖昧なままスプリントを開始してしまう
- サブタスクの洗い出しができていないままスプリントを開始してしまう
- ストーリーやタスク同士の関連性が考慮できていないままスプリントを開始してしまう
学び
- スプリントプランニングがとにかく大事
- ほとんど設計が完了するくらいの詳細度で完了の定義やサブタスク出しを行うとスプリント中のイレギュラー遭遇率が減る（その分プランニングはとても疲れる）
- ストーリーやタスクが明確だと開発チームの心理的負担が減る
- 結果的にPOとの期待値の認識合わせも行えるためPOの不安も減る
- きちんとストーリーの優先度や詳細、完了の定義などを管理しておけば不明瞭な項目が減り、バーンダウンしやすくなる（プロジェクト終盤は特に）
- モブをうまく回す条件（仮説）
- 技術的知見が近しい人の集まりで実践する
- 細かな暗黙知（アーキテクチャの知見、命名規則、など）の共有を目的とすると良いかも？
- 技術的知見に開きがある場合はペアの方がうまく回せそう
終わりに
スプリント中のポイント増加については多くの場合ストーリーの要件が不明瞭であったり、PO-開発チーム間でのコミュニケーション量が足りていないことが原因であったように思います。
一方バーンダウンさせるために必要なことの多くはスプリントプランニングでの話し合いの中身をどれだけ密度高いものにできるかが鍵となっている印象です。
ですが結局のところ多くのスクラム関連書籍に書いてある内容をきちんと実践することが重要なんだな、ということを実感できた２ヶ月半でした。
今回はバーンダウンチャートをできるだけ綺麗な階段状にすることにコミットした内容となっていますが、今回のプロジェクトではあまりベロシティを安定させるには至れていないので、今後はこのあたりを改善することが課題かなと思っています。
もちろんその他にも改善できる箇所はまだまだあるので、これからも継続して改善を行えるよう善処していきたいと思います！
