ブログ

ryuzeeによるブログ記事。不定期更新

スプリントのキャパシティを明らかにする方法

みなさんこんにちは。@ryuzeeです。

スプリントを始めるには、スプリントプランニングを実施します。

プロダクトオーナーはあらかじめプロダクトバックログの並び順を最新にしておき、プロダクトオーナーはどれを実現したいのかを提示するとともに、開発チームは実際にどれくらい実現できそうなのかを考えた上で、対象となるプロダクトバックログアイテムを選択します。その上で、選択したプロダクトバックログアイテムを実現する方法を開発チームは検討し、作業計画をたてます。

このときに考慮が必要になるのが、スプリントのキャパシティです。

キャパシティとは何か

スプリント期間が1週間の場合で考えてみましょう。 1週間スプリントの場合、休日を抜くと5日間になります。その間毎日8時間働くとするとスプリント期間中の総時間数は40時間になります。 しかし、この40時間に人数をかけ合わせたものがキャパシティになるわけではもちろんありません。 (※残業は考慮に入れないでください。最初から残業を考慮に入れた計画はろくなものではありません)。

キャパシティとは、そのスプリントで、実際にプロダクトバックログアイテムをインクリメントに変えるために使える時間を指します。

キャパシティの計算方法

では、実際にキャパシティをどう計算するのか見ていきましょう。やり方はいくつもありますので代表的なものを紹介します。 以下の例では、個人単位で数字を出したあとに、開発チーム全体のキャパシティを出すという流れで進めます。

イベントの時間を算出する

まずスクラム関係のイベントの時間を算出します。 スクラムでは、イベントのタイムボックスが決まっています。 1か月スプリントの場合の時間と比率は以下のようになります。

スプリント全体(20日換算)160時間100%
スプリントプランニング8時間5%
スプリントレビュー4時間2.5%
スプリントレトロスペクティブ3時間1.875%
バックログリファインメント16時間10%
デイリースクラム15分/日

スプリント期間が短い場合は、デイリースクラムを除いて時間が短くなります。 1週間スプリント(5日換算)にすると以下のようになります。

スプリント全体40時間100%
スプリントプランニング2時間5%
スプリントレビュー1時間2.5%
スプリントレトロスペクティブ1時間2.5%(※1)
バックログリファインメント4時間10%
デイリースクラム1時間(※2)
残時間31時間77.5%
  • ※1 スプリントレトロスペクティブは同一比率にすると45分となり短いので通常1時間で設定しています
  • ※2 1週間スプリントでは初日にはデイリースクラムをやらないことも多いので、計算上4日に設定しています

スクラム以外に組織の中で必要な作業をする時間を算出する

既に20%以上の時間がイベントに使われていることが分かりましたが、他にも考慮しないといけない点があります。 それが組織の中でのスクラム外の仕事に関係する時間です。 例えば、以下のようなものを考慮に入れます。

  • 運用対応
  • メールの処理
  • 日報や週報の作成
  • 経費精算などの事務処理
  • マネージャーとの1 on 1
  • 目標設定の検討
  • 採用面接の手伝い
  • 研修への参加
  • 有給休暇

これらは毎週定常的に発生するものと、不定期に発生するものに分けられますが、いずれにしても所要時間を算出しておき、キャパシティから減らすことになります。 それぞれの時間がどの程度になるかは組織の規模やプロセスによって左右されます。 感覚的には、上位4つの項目で、5〜10%程度の時間はかかることが多いように思います。

つまり、合計すると研修や有給休暇がない週で、開発に使える時間は27時間、比率として67.5%となります。 (研修や休暇の場合は、それらを全て引いた上で、二重計上されてしまった値を戻せばOKです。また、そんなことはしていないとは思いますが、複数のスクラムチームや業務を兼任している場合は、それも考慮が必要です。)

スプリント全体40時間100%
スクラムイベント9時間22.5%
スクラム以外の業務4時間10%
個人キャパシティ27時間67.5%

開発チームのメンバーごとにキャパシティを合計することで、開発チーム全体のキャパシティが明らかになります。

バッファを考慮する

開発チームのメンバーごとに使える時間を合計すれば、開発チームのキャパシティになることが分かりました。 開発チームが5人のとき、実際にどうなるのかを表したのが下の表です。 (※年間休暇日数は少なくとも10日程度と考えると5人チームでは年間50日となります。つまり毎週誰か一人が一日休むというのはそれほどおかしくありません。)

Aさん27時間
Bさん20時間1日休み(※)
Cさん24時間半休
Dさん27時間
Eさん24時間採用面接2回
合計122時間61%

では、スプリントバックログのタスクの見積時間の合計は、その数字(この例だと122時間)まで入れられるか、というとそういうわけでもありません。

スプリントプランニングでは必ずしも全てのタスクが洗い出せるとは限りません。 初期の段階ほど追加タスクが生まれやすいですし、そもそもタスクの時間の見積があっている保証もありません。

つまり、最初からキャパシティ目一杯を使う計画をたててしまうと、スプリントプランニングで選択したプロダクトバックログアイテムが終わらない可能性が高くなります。 別の観点では、目一杯詰め込んだ計画は、ミスや遅延が即「完成しない」結果に結びつくため、精神的な負荷が高くなります。

このような問題を防ぐためにバッファを持たせます。 バッファは個々のタスクごとに持たせてしまうと、パーキンソンの法則(時間を目一杯使うような力が働く)に当てはまり、ムダが多くなるので、キャパシティの全体に対して確保します。

キャパシティの比率には絶対的な値はないですが、最初は20〜30%程度から開始し、レトロスペクティブなどを使って適正化していけばよいでしょう。今回の例だと、休暇や採用面接など全てを考慮すると、計画済作業に使える時間は全体の半分以下となりました。休みがない場合でもおおよそ50%程度になります。

スプリント全体200時間100%
スプリントキャパシティ122時間61%
バッファ37時間(キャパシティの30%)
キャパシティ(補正後)85時間42.5%

まとめ

最初のうちはこのような計算をしておき、自分たちがどのくらいのペースで開発できるのかを把握しておくと良いでしょう。 スプレッドシートを使って計算できるようにしておくと計算が楽になります。 慣れてくれば、あまり細かく計算しなくても大丈夫にはなっていきます。

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック