アジャイル
スクラム

【スクラム入門】認定スクラムマスターの俺が正しいスクラムの理論をまとめる

はじめに

人によってスクラムの理解が異なることは珍しくない。なぜならば、スクラムは単なるフレームワークに過ぎないし、抽象的な部分もあるし、一見たくさんルールがあるようで実は決まっていないことも多いから。その場その場で各自がスクラムの理論を基本に最適解を考えだす必要がある。つまり、スクラムの唯一解(これだけがスクラムの正解だと呼べるもの)は存在しない。
しかしながら、世の中には明らかに間違った、絶対に関わりたくない危険なスクラム開発の話を耳にすることは多い。そこで、以下の有名な参考から、正しいスクラム理論の一例をまとめる。
あ、"認定スクラムマスター"というのはスクラムマスターの資格保持者のことです。まぁどんな資格も資格だけでは価値は薄いですが。

参考

アジャイルソフトウェア開発宣言
アジャイル宣言の背後にある原則
スクラムガイド
スクラム入門
Scrum Boot Camp
認定スクラムマスター研修

アジャイル

アジャイルとは

アジャイルとは、より良い解決方法を探している状態である。
"状態"なので、「アジャイル開発をやろう!」というのはおかしくて、振り返ってみて「あれはアジャイルだったなー」ってなるもの。"Don't just do agile, be agile."という名言があるくらい。だから、より良い方法を探してたどり着いた結果がたとえウォーターフォールだったとしても、それはアジャイルである。
"agile"を辞書で調べると"迅速な"とか"俊敏な"とかがでてくるため、「アジャイルとは顧客の要望の変化に迅速にこたえるための考え方だ」などと誤解されることが多いが、それは単なるアジャイルの1つの側面にすぎない。
アジャイル自体の歴史は1950年代までさかのぼるが、いわゆる我々の言う"アジャイル"は、2001年に作成されたアジャイルマニフェスト(アジャイルソフトウェア開発宣言、アジャイル宣言の背後にある原則)を指す。アジャイルとして決まっていることは実はこれだけ。下に概要をまとめる。

アジャイルソフトウェア開発宣言

左よりも右に価値を置く。(決して左が要らないとは言っていない。)

プロセスやツール < 個人と対話
包括的なドキュメント < 動くソフトウェア
契約交渉 < 顧客との対話
計画に従う < 変化への対応

アジャイル宣言の背後にある原則(抜粋)

要求の変更は歓迎します。
数週間から3か月という短い間隔でリリースします。
ビジネス側の人間と開発側の人間は毎日一緒に働かなければなりません。
face-to-faceのコミュニケーションを重視します。
動くソフトウェアこそが進捗の最も重要な尺度です。
一定の開発ペースを維持できるようにしなければなりません。
シンプルさ(無駄なく作る)が本質です。
自己組織的なチームである必要があります。
もっと効率的な方法をみつけるために定期的に振り返りそれに基づいて自分たちのやり方を調整します。

スクラム

スクラムとは

スクラムとは、経験主義にもとづき反復的かつ漸進的にプロセスを進め、現状を見える化するフレームワークである。
ソフトウェア開発以外でもスクラムは活用できる。

3本柱

スクラムの3本柱は透明性検査適応である。
最初は抽象的で理解しにくい部分かもしれないが、この3本柱を意識しながらスクラムを実践することが、スクラムの本質を理解して成功させるために必要なことである。ただ、なんとなく決められたイベントをこなして、なんとなく作成物を作るだけではスクラムの高い効果を得ることは難しい。

透明性

スクラムチームの現状や問題点を見える化すること。

検査

見える化により問題点を見つけること。

適応

スクラムチームに問題があった場合に、改善策を考えて対処すること。

5つの価値基準(確約、勇気、集中、公開、尊敬)

個人はスクラムチームのゴールの達成を確約しなければならない。
スクラムチームのメンバーは正しいことをする勇気を持ち、困難な問題に取り組まなければいけない。
全員がスプリントの作業とスクラムチームのゴールに集中しなければいけない。
スクラムチームとステークホルダーは、仕事や課題と、その遂行の様子を公開することに合意しなければいけない。
スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。

なんだか小学校のクラスルールみたいですが、全てを実現するって意外と難しいものです。
この5つの価値基準のどれかでも満たしていないケースを発見したら、発見した人は妨害リストにそれを追加するべきである。

スクラムチーム

スクラムチームは自己組織化されており、機能横断的である。
スクラムチームはプロダクトオーナー、スクラムマスター、開発チームの3つのロールから構成される。
プロダクトオーナーとスクラムマスターのロールの兼任は禁止されているが、それ以外は禁止されていない。

自己組織化

スクラムチームが誰かに管理されておらず、自分たちで自分たちを管理している状態。
例えば開発チームの場合、進捗管理、課題管理、改善、スプリントバックログの選択などを自分たちで適切に行っていればそれは自己組織化されていると言える。

機能横断的

スクラムチーム外に頼らずにゴールを達成できる状態。
例えば開発チームの場合、プロダクトを開発するための全て(設計、コーディング、試験、環境構築、ドキュメント作成など)が開発チーム内でのスキルセットのみで解決されていれば、それは機能横断的なチームであると言える。

ロール

プロダクトオーナー(PO)

ミッション

プロダクトのROIを最大化すること
POは開発チームへの作業依頼権限とスプリントの中止権限を持つ唯一の存在である。

やること
  • プロダクトバックログアイテム(PBI)の管理
  • リリース計画策定
  • 市場調査
  • ステークホルダとの対話
  • 開発チームとの対話
  • 予算管理
  • スプリントレビューで"DONEの定義"にしたがって受け入れ判断をするなど
注意点

POを複数人で実施することも可能だが、その場合は代表者を1人決めておく必要がある。

スクラムマスター(SM)

ミッション

スクラムチームにスクラムの理論を理解してもらい、それを正しく実践するように促すこと。
"促す"とは具体的には、スクラムチームの誰かがスクラムのプロセスとして正しくないことをした際に「それで大丈夫だろうか、問題ないだろうか」と問題提議するなどである。(なんか、学校の先生みたい)
SMはサーバントリーダー(メンバーが成果をあげるために支援や奉仕を行うリーダー)である。また、外部からの不要な干渉を避けるためにスクラムチームを守る義務がある。そのため、社内の管理職や顧客に楯突く場合もある。

やること
  • 妨害の除去
  • 妨害リストの作成
  • POのサポート
  • 開発チームのサポートなど
注意点

チームが自己組織化するために、SMはメンバーに直接的な指示(タスク割り当てなど)や管理(進捗管理など)をしてはいけない。従来のプロジェクトマネージャ(PM)にSMを重ねてしまう人が多いが、それは絶対にやってはいけないことだ。スクラムにはPMは存在しない。ただし、PMがやっていた仕事がなくなったわけでなく、それらは3つのロールに分担されている。
開発チームができるだけ開発業務に専念できるように、妨害の除去として、開発以外の雑用をやることも多い。
スクラムチームが成熟してくるとやることがなくなってくる。その場合は、ロールの兼任をするのも一つの方法だ。(本当にそんな日がやってくればの話だが。。。)

開発チーム

ミッション

インクリメントを完成させること

やること
  • 開発
  • プロダクトバックログの追加
  • 妨害リストの追加など
注意点

開発チームは自己組織化されており、外部から仕事の進め方やタスクを指示されるようなことがあってはならない。
1つの開発チームは3~9人で構成されなければならない。それより少ないと機能横断的でなくなる可能性が高くなるためNG。多すぎると調整が大変になってしまうためNG。多すぎる場合は別のスクラムチームをもう1つ作るべき。
開発チーム内で年齢や役職、会社の違いがあったとしても全員フラットな関係でなければならない。
開発チームに専門能力(JenkinsとかUIの芸術部分でありがちだよね?)の高いメンバーがいて、その人に頼りがちだけどそこで問題が起きたとして、それはそのメンバーだけの責任でなく開発メンバー全員の責任である。

スプリント

スプリント

スクラムではスプリントと呼ばれる1ヶ月以内の固定した開発期間を何度も繰り返す。1週間、2週間、1ヶ月のいずれかが一般的。
スプリント期間は固定である。つまり、第一スプリントは2週間、第二スプリントは1週間などと異なってはいけない。また、たとえスプリント期間内に完了しなかったプロダクトバックログアイテムがあったとしても、スプリントを延長してはいけない。残ったものは次のスプリント以降に繰り越す。
スプリントはスプリントプランニング、デイリースクラム、開発作業、プロダクトバックログリファイメント、スプリントレビュー、スプリントレトロスペクティブで構成される。
特に決まりはないけど、スプリント期間が週単位の場合は、月曜始まり金曜終わりが一般的。

スプリントの中止

緊急事態によりスプリントを続けることができなくなった、続ける必要がなくなった場合にスプリントは中止される。
スプリントの中止実行権限を持つのはPOだけである。
スプリントの中止はよっぽどのことが無い限り、行われるべきでない。中止された場合は開発チームは会社のフロントで嘆きの儀式を行おう。

スプリント0

自己紹介、スクラム理論の勉強会(認識合わせ必須)、プロダクトバックログの作成と共有、必要技術スキルの勉強会、開発環境構築などを行うスプリント開始前の準備期間のこと。必要期間はチームにより異なる。

リリーススプリント

インクリメントの統合テストや通常スプリントで残ったタスクを実施してリリースを行うための特別なスプリント。
スプリント毎にリリース可能なものを作成するので、リリーススプリントが無いことが理想だが、そうでない場合に用意される。
リリーススプリントはPOがリリース準備が整ったと判断するまで続く。

イベント

イベントは規則性を生み、イベント以外のミーティングができるだけ行われないようにする。
全てのイベントはタイムボックス化されている(何分とか、何時間までとかが決まっている)。もし、タイムボックスを超えてしまう場合は、打ち切らずに議論が完了するまで続けるが、タイムボックスを越してしまったという事実は妨害リストに追加する。
イベントにより透明性の獲得と検査適応が実施される。

スプリントプランニング

  • いつ?⇒スプリントの最初
  • 誰が?⇒全てのロールが参加する。ただし、第二部はPOは連絡がつく状態であれば参加しなくてもよい。
  • 目的は?⇒"何"を"どのように"作るかを決定すること。
  • どれくらい?⇒最大4時間(1スプリント2週間の場合)。

スプリントプランニングは第一部と第二部で構成される。第一部ではベロシティからだいたいできそうなプロダクトバックログを選択して、第二部でその見積もりや選択の詳細、やり方を詰めていく感じ。

第一部

第一部では、スプリントで消化できるプロダクトバックログアイテムをベロシティを基に開発チームが選択する。
プロダクトバックログはリファイメントによってすでに見積もりがされている状態のはずだが、リファイメント後に作成されたプロダクトバックログアイテム(つまり見積もりがまだされていないもの)で、今スプリントの範囲になりそうなものはこの場で見積もりをする。

第二部

第二部では、開発チームは選択したプロダクトバックログアイテムをスプリントバックログに分割し、タスクレベルに落とす。これにより、POとSMにどのようにプロダクトバックログアイテムを消化できるかを伝えられる状態になる。
分割したスプリントバックログに時間数を見積もり、その総計が1スプリントでのチームが開発できる時間をオーバーした場合は優先度の低いプロダクトバックログから外していく。逆に余裕がある場合なプロダクトバックログをその分選択する。
POの予想より多すぎたり少なすぎたりする場合は、開発チームとPOは話し合う。
開発チームは選択したプロダクトバックログアイテムを完了することに全力を注がなければならないが、完了することを約束するわけでない。なぜならば、見積もり時にはわからなかった技術的に困難な事象が発生することはよくあるからである。無謀な長期の残業は行わない。

1スプリントあたりのチームの開発時間数

これはスクラムで定義されているものではない。あくまで一例の計算方法。
下の"オーバーヘッドを引いた割合"とは、開発チームはイベント時間以外でも実際には開発しない時間があるため、それを差し引いた割合である。例えば、開発に関する議論の時間やリフレッシュ休憩時間、雑談などである。

開発チームの人数×(1日の勤務時間数×スプリントの日数-イベントの時間数)×オーバーヘッドを引いた割合

例えば、開発チームが5人、1スプリント2週間、1日の勤務時間が8時間の場合は以下。

5人×(8時間×10日-15.5時間)×0.7=225.75時間

デイリースクラム

  • いつ?⇒毎日同じ時間(一般的には朝)
  • どこで?⇒どこでもいいがいつも同じ場所
  • 誰が?⇒開発メンバー。SMは必要に応じて参加する。POは見学(発言は基本的にNG)してもよい。
  • 目的は?⇒開発チームの検査
  • どれくらい?⇒最大15分

開発チームは各々が、"昨日やったこと"、"今日やること"、あれば"課題(妨害)"の共有を行う。また、スプリントバックログのバーンダウンチャートなどを活用して、進捗確認を行う。SMが進捗管理をするのではなく開発メンバーが自分たちで進捗管理を行う(自己組織化)。
課題は共有にとどめること。ありがちなのは、課題の解決方法まで議論してしまって、15分のタイムボックスを破ってしまうことだ。課題の解決に関する議論はデイリースクラム後に関係者だけが話し合って、必要であればその結果を他のメンバーに共有するようにする。
毎日同じ時間と同じ場所で開催するのは、「いつだっけ?」、「どこだっけ?」という無駄をなくすため。
座りながらやると時間オーバーしがちだから、全員立ちながら行う。
SMはチームが未熟な場合、デイリースクラムを先導しても良いが、チームが成熟してきたら、一歩後ろから見守ったり、あえて参加せずに座りながら自分の作業をしているフリをして聞き耳を立てる程度でよいだろう。(進捗状況や妨害の確認のためにリスニングしておくのは必要。)
管理職の見学は避けたい。なぜならば、共有でなく管理職への報告になりがちで自己組織化が損なわれやすいのと、課題共有がしにくい雰囲気になりやすいから。もし管理職にエスカレーションするべき課題があるならば、デイリースクラム後にあげる。

プロダクトバックログリファイメント

  • いつ?⇒いつでも良い。毎週中頃にやることが多い。
  • 誰が?⇒全てのロール
  • 目的は?⇒プロダクトバックログの透明性の獲得
  • どれくらい?⇒最大0.5日

POはプロダクトバックログの説明(変更、追加、削除、詳細化、順序変更など)を行う。
開発チームはプロダクトバックログへの意見(追加や順序変更や質問など)や新しいプロダクトバックログアイテムの見積もり、必要であれば再見積もりを行う。

プランニングポーカー

プロダクトバックログの見積もりには"プランニングポーカー"と呼ばれる手法が一般的に使われる。開発チーム全員がフィボナッチ数列など(0, 0.5, 1, 2, 3, 5, 8, 13,...∞)の値が書かれたカードを持っており、プロダクトバックログアイテムに「いっせーのせ!」でカード(見積もり)を提示する。この見積もりは単位のない"相対見積もり"である。例えば基準にしやすい機能(しばしばログイン機能が用いられるが)を"2"として、それと比較した難しさを相対見積もりとして決定する。当然ながら、人によってポーカーの出す値は異なるので、一番大きい値をだした人と小さい値をだした人を中心になぜその値をだしたのかを議論する。議論したあと、再度カードを使って見積もりし直す。この議論により、ある特定の人しか気づかなかった情報がチームに共有され、共通理解を得ることができる。見積もりってなんか殺伐としがちだけど、カードを使うとなぜかみんなにこにこしながら話し合える(笑)
一つ一つの見積もりにはそこまで大きな時間をかけてはいけない。

スプリントレビュー

  • いつ?⇒スプリントの終わり
  • 誰が?⇒全てのロールとPOが招待した重要な関係者(ステークホルダーなど)
  • 目的は?⇒インクリメントの検査とプロダクトバックログの適応
  • どれくらい?⇒最大2時間(スプリント2週間の場合)

開発チームはインクリメントのデモを実施して、質問に答える。また、完了できなかったプロダクトバックログがあれば説明する。デモをやることと受け入れに通ることばかり考えがちだが、大切なのはスクラムチーム内でよく議論して、よりよいプロダクトを得るための手がかりを見つけることである。デモはそのための手段であって目的ではないことに注意しよう。また、デモの説明スライドは作るべきでない。そこに労力が割かれがちだからだ。
POはDONEの定義に従い、インクリメントが受け入れ可能かを判断する。
スプリントレビューを通して参加者は議論し、有益な意見があれば、必要に応じてプロダクトバックログの変更を行う。

スプリントレトロスペクティブ

  • いつ?⇒スプリントレビュー後で次のスプリントが開始される前
  • 誰が?⇒SMと開発チーム。POは参加してもよいが必須でない。
  • 目的は?⇒スクラムチームの検査適応
  • どれくらい?⇒最大1.5時間(1スプリント2週間の場合)

スプリントで人・プロセス・ツールの観点から問題がなかったか、もっと成果を出すためにできることがないかを議論し、次回のスプリント以降の改善策を考える。
手法として、KPT(Keep, Problem, Tryを出し合うこと)がよく使われる。
このイベントが省かれる話を時々聞くが、本当にスクラムを理解していればそんなことは起こりえないはずだ。

作成物

作成物は透明性検査適応の機会を提供する。
全ての作成物は全員に見える化されている必要がある。

プロダクトバックログ

プロダクトに必要なもの(新規機能追加、既存機能修正など)が優先度順に並べられた一覧。
POがプロダクトバックログの内容と並び順に責任を持つが、スクラムチーム全員が追加できる。
優先順位は顧客要求、市場調査結果、リスク対応、機能要件、非機能要件、依存関係などを考慮して決定する。
優先度が高いもの(1、2スプリント先くらいまで)ほどタスクレベルに分割可能なくらい詳細で、低いものほどアバウトなものにする。優先度が低いものまで詳細にすべきでない。なぜならば、作るかどうかも分からないものまでコストかけて詳細化しても無駄になる可能性があるから。逆にこれはジャストアイディアを気軽に提案できるメリットでもある。
ビジネス要求、市場、技術などの変化、新しいアイディアなどによりプロダクトバックログは常に変化する。したがって、プロダクトバックログは決して完成するものではない。
プロダクトバックログの書き方は自由だが、ユーザーストーリー形式(「〜として、〜したい。それは、〜だからだ。」というストーリーとデモ手順とストーリーポイントを書くフォーマット)が一般的。

DONEの定義

プロダクトバックログの完了定義。
POのスプリントレビューでの受け入れ判断基準に使われたり、開発チームがインクリメントを作成する際のゴールの一部になる。
機能要件だけでなく非機能要件、カバレッジ、必要であればドキュメントなどの完成も定義しておく。

スプリントバックログ

プロダクトバックログアイテムをタスクレベルに分割したもの。スプリントプランニング第二部で開発チームにより作成される。また、スプリント期間中での修正、追加、削除も可能である。
スプリントバックログの管理を行えるのは開発チームだけである。
規模や工数はバラバラで問題ないが、1つのスプリントバックログアイテムの見積もりは1日以下の大きさに分割すること。それより大きい見積もりのものは一日以内になるようにさらに分割する。
スプリントバックログアイテムは"未着手"、"着手中"、"完了"のいずれかのステータスがラベル付けされており、そのステータスが可視化されている。JIRAでも付箋とホワイトボードによるアナログ方式でも問題ない。
スプリントバックログの担当は開発チームが自分たちで決める。誰かに割り当てられるものでない。
設計、コーディング、テストコードの作成だけでなく、結合テストなどの実施、CI環境改良、ノウハウを残すなどもスプリントバックログとして分割するべきである。

妨害リスト

スクラムチームがスクラムを正しく実践する上で妨害になっていることを優先度順にリスト化したもの。
"妨害"とあるが、これはスクラムチーム外によるものだけでなく、スクラムチーム内によるものも対象である。
どのロールでも追加できるが、妨害リストの管理の責任者はSMである。
特にSMは積極的にこの妨害を取り除く。
いつでも追加可能だが、特にデイリースクラムやスプリントレトロスペクティブで課題(妨害)の共有が行われやすい。

その他重要項目

ベロシティ

ベロシティとは、そのスプリントで開発したプロダクトバックログのストーリーポイントの合計である。
スクラムチームはベロシティを高めて安定させることを目指す。(高めることよりも安定させることの方がより重要)
ただし、ベロシティを過信し過ぎてはいけない。なぜならば、そもそもストーリーポイントがいい加減な値だからだ。ストーリーポイントは綿密に議論してだした値でないし、フィボナッチ数列の値しかだせないし、技術的な不安点があるからとりあえず大きな値を出すとかする。また、スプリントの日数は祝日、メンバの休暇などで厳密にはスプリント毎に異なる。したがって、ベロシティはそこまで信頼できる値ではない。ではなぜベロシティやストーリーポイントが必要なのだろうか?ベロシティが必要な理由は、POがおおまかなリリース計画を立てるためである。POの独断による推測よりも実際に開発を行う開発チームのなんとなくの推測の方がはるかに信頼できる。(まだましだ。)特に開発チームが成熟してきてベロシティが安定してくればそこそこ信頼できるようになる。ストーリーポイントが必要な理由は、ベロシティを計算するため以外に、その過程に大きな意味があるからである。それはプランニングポーカーで得られるチーム内での情報共有と共通理解を得ることだ。
しかしながら、数値としてあらわされるため、未熟なチームはベロシティの値の大きさを必要以上に気にしてしまうし、スクラムを理解していない管理職はこのような数字が大好きなので、ベロシティでボーナス評価をするなんていうバカげたことをやりかねない。そうなってしまうと、チームはベロシティに細工をしてしまい、チームは崩壊するだろう。そうならないようにSMはチームや管理職を教育する必要がある。

バーンダウンチャート

リリースバーンダウンチャート

横軸が時間で、縦軸が現在残ってるプロダクトバックログのストーリーポイントの合計。
認定スクラムマスター研修でも言われていたが、はっきり言ってこれは使うべきでない。ナンセンスなうえに危険だからだ。プロダクトバックログは期間関係なしに追加されるし、このチャートの縦軸が0になるようことは期待されていない。しかし、しばしばウォーターフォールの感覚に慣れてしまった人はプロジェクト期間中に全部終わらせることに誤解しがちだし、スクラムを理解してない管理職がこれを見て余計な妨害を加えてくる可能性がある。

スプリントバーンダウンチャート

横軸が時間で、縦軸がスプリントバックログのタスクの総見積もり時間。
スプリントバーンダウンチャートにより、検査を行い、スプリントの進捗の透明性をあげられる。
スプリント期間中にスプリントバックログが追加されることもあるため、縦軸の値が上がることもあるが、最終的には0になるようにする。開発チームはこのスプリントバーンダウンチャートを利用して、スプリントでの進捗を管理する。

鶏と豚

外野が野次を言うべきでないという比喩。
鶏と豚が経営する店で、ある日鶏が、”ハムエッグ”を新規メニューとして出そうと提案する。しかし、豚は「俺は自分の身を削るのに、お前は卵を提供するだけで身を削らないじゃないか、公平じゃない!」と反対する話。
POはプロダクトバックログの豚、開発チームはスプリント作業の豚、SMはスクラムプロセスの豚、それ以外は鶏である。各豚の責任分野ではその豚が一番偉い。
イベント毎に参加できるロールが限定されているのはこれが1つの理由である。

メンバの追加

メンバ追加するから次のスプリントからは開発ペースあげてよと言われても、簡単に「分かりました。」と言ってはいけない。なぜならば、新規メンバは往々にして最初の期間は育成(プロダクトの理解、スクラムの理解、技術の理解など)が必要で、逆に最初の方はベロシティは落ちる傾向にあるからである。メンバの追加で短期的に生産性をあげることは難しい。一般的に、新規メンバ追加による生産性向上には3ヶ月〜6ヶ月かかると言われている。

テスト専門チームを許さない

スクラムではテスト専門チームの存在を許していない。なぜならば、例えば、スプリント終了後にテスト専門チームがバグを見つけたとしても、開発チームは既に次以降のスプリントの開発作業をやっているため、すぐには対応できないからだ。そもそも、スプリントの中で徹底的にバグを発見して潰すべきなのである。また、テスト専門チームがいることによって、深層心理的に彼らに頼ってしまい、自己組織化のマインドが薄れてしまう危険性もある。

開発チームって何人用意すれば充分?

プロジェクト開始前に、開発チームは何人集めればよいのだろうかと悩むだろう。なぜならば、スクラムではどんな機能を作るかは決まっていないのでウォーターフォールのように期間と人月から人数を算出することはできないからである。
したがって、現実的には、社内のリソース事情や予算事情などにより決定されるだろう。開発チームは3~9人までなら何人でもよいが、5人くらいが一番やりやすいので、初めてのスクラムだから5人集めようという考え方もある。

やりかけで終わったプロダクトバックログアイテムのベロシティ計上

スプリント期間中に途中までしかできなかったプロダクトバックログアイテムが存在する場合、そのプロダクトバックログアイテムのストーリーポイントをベロシティとしてどのように計上するかと悩むかもしれない。例えば、そのプロダクトバックログアイテムのストーリーポイントが8だとして、それの半分くらいしかできなかった場合に、4ポイントを今回のスプリントのベロシティに計上するか、それとも全く計上しないかである。答えとしては、計上するべきではない。なぜならば、ベロシティは完了したものしかカウントしないからだ。ちなみに、そのやりかけのプロダクトバックログの再見積もりはやってもやらなくてもいいだろう。どうせやりかけなんて信用できないから。

最後に

スクラムの理論を浅く理解するのは簡単ですが、深い理解とその実践は難しいです。個人的には、自己組織化と三本柱を意識できるチームかどうかが本当にスクラムを活かしているかどうかに繋がるかなと思ってます。
この記事を読んで、やっぱりスクラムはうちの会社に向いてないなーって思った皆さんの考えは多分正しいです。なぜならば、スクラムチームのみならず社内の偉い人、SIであれば顧客もと多くの人にスクラムを教育してスクラムをよく理解してもらう必要があるから(悪い部分も)。そういった教育ができる人材もまだまだ少ないと思います。しかも偉い人ってなかなかこっちのいうことは聞いてくれませんorz
そういった話とか、SI×スクラムの話とか顧客や社内の偉い人がスクラムを理解してないとあるある問題もいつか書こうと思います。
あ、これ見ながら認定SM試験のウェブテストやれば多分受かります。