新米スクラムマスターの思考メモ(その3 Sprint Planning編)

| 3 min read
Author: hiroaki-taka hiroaki-takaの画像

これは、豆蔵デベロッパーサイトアドベントカレンダー2022第17日目の記事です。

はじめに

#

「新米スクラムマスターの思考メモ」の3回目の記事です。これまでは、スクラムマスターになる前と、Retrospectiveでの思考メモについて執筆してきました。まだご覧になっていない方は、ぜひ過去の思考メモもご覧ください。

今回の記事では、Sprint Planningではどのようなことを感じ、行動したかについてまとめてみたいと思います。

Sprint Planningについて取り組んでいること・感じたこと

#

プランニングポーカーは2回実施する

#

これは実際にアドバイスを頂いて実施していることですが、SBI(Sprint Backlog Item)見積りのためのプランニングポーカーは2回実施するようにしています。

1回目は、ディスカッションで前提条件、やらないこと、完了条件などについて、スクラムチームで認識を合わせたタイミングで実施します。

2回目は、1回目のプランニングポーカーの結果を踏まえたディスカッションの後に実施します。ディスカッションでは各々の見積りの理由と、スクラムチーム間の認識にずれがないかを確認するためです。なお、仮に1回目で全員が同じ見積り結果となったとしても、ディスカッションは省略しないようにします。

こうして見ると、SBIの見積りに関しても、スクラムの3本柱である「透明性」、「検査」、「適応」が含まれていると感じます。見積りの理由を開示することで「透明性」を担保し、ディスカッションを踏まえて見積りが妥当かどうかを「検査」し、再度プランニングポーカーを行い「適応」するという流れです。

時間見積り vs 相対見積り

#

よくある話として、時間見積りなのか、それとも相対見積りなのかという点が挙げられます。社内の方々の意見を伺ったり、さまざまな資料を調べてみたところ、一般論としてPBI(Product Backlog Item)は相対見積り、SBI(Sprint Backlog Item)は時間見積りを行うことが多いように思います。しかし、今回我々のチームでは、Sprint PlanningでSBIを見積もる際には「相対見積り」を採用しています。

その理由として、今回のスクラムが新人育成の場でもあるためです。このような状況でプランニングポーカーで時間見積りを採用したとしても、能力差から新人とベテランの間では見積り結果に数倍の差が出ることが自然です。にもかかわらず、当チームにおいて2回プランニングポーカーを実施すると同程度のポイントに収束するという歪な状況になっていました。また、新人と既存開発メンバーのギャップを埋めるため、詳細にタスク分解をし過ぎてSprint Planningが長時間に及んでしまっていました。さらには、見積もりの予実が不確実性コーン上でも許容できなかったり[1][2]、結果としてSprint Planningで時間をかけている割にベロシティはそれほど出ていないという…。書いていてもテンションが下がってきますね(笑)。

このような状況を改善するため、実際にRetrospectiveの場でディスカッションが行われ、Sprint Planningの改善に関するTryが挙げられました。そのあとのSprint Planningでは早速、見積り方法を相対見積りに変更しました。

まだ相対見積りに変更して日が浅いので、今後どうなるかは期待半分、不安半分といったところです。

行間は読めているか?

#

個人的な反省点になりますが、現時点でSprint Planningがスクラムマスターとして一番ファシリテーションに失敗したイベントだと思います。

理由としては前述の通り、詳細にタスク分解しすぎていたためSprint Planningが長時間化していたためです。また、Retrospectiveで指摘が入るまで、時間見積りの問題点についてほとんど認識できていませんでした。

前述の通り、SBIは時間見積りをすることが多いですが、これはあくまで一般論です。この一般論の前提にあるものは何か。それはスクラムチームに専門家が集結しており機能横断型なチームが構成できている状況です。このようなチームであれば、時間見積りをしたとしても認識に齟齬が出ることはなく、問題は少ないと思います。一方、現在の開発チームは新人教育の面もあるため全員が専門家という状況ではありません。そのギャップが見積の問題として表面化してきたのだと思います。

これはスクラムに限った話ではありませんが、前提や背景は暗黙の了解となっているときが多いです。資料にしても他の方のアドバイスにしても、必ず、前提や背景があります。そのまま鵜呑みにするのではなく、その記述・発言の裏にある前提や背景をしっかりと認識した上で、適用できるかどうかを判断する必要があります。

よく「行間を読む」という言葉がありますが、まさに記述や発言の裏にあって見えない部分に対する意識が足りなかったかなと自戒しています。

おわりに

#

新米スクラムマスターの思考メモの第3回、Retrospective編は以上となります。

次回は、私が最も難しいと感じているDailyScrumの思考メモについて執筆したいと思います。


  1. 不確実性コーンの出典:Jonathan Rasmusson,「アジャイルサムライー達人開発者への道」, 第1版, オーム社, 2012, p127 ↩︎

  2. Sprint Planningで見積もるSBIは、不確実性コーンの右側(作成の前後)に相当し、不確実性はかなり排除されていると考えられます。しかし、我々のチームの見積り予実はかなりのブレがあり、この不確実性コーンの範囲を超えている状況でした。 ↩︎

豆蔵デベロッパーサイト - 先週のアクセスランキング
  1. 基本から理解するJWTとJWT認証の仕組み (2022-12-08)
  2. Docker+Wasm で WASM をコンテナとして実行する (2023-01-25)
  3. 自然言語処理初心者が「GPT2-japanese」で遊んでみた (2022-07-08)
  4. 直感が理性に大反抗!「モンティ・ホール問題」 (2022-07-04)
  5. Nuxt3入門(第4回) - Nuxtのルーティングを理解する (2022-10-09)
  6. AWS認定資格を12個すべて取得したので勉強したことなどをまとめます (2022-12-12)
  7. Jest再入門 - 関数・モジュールモック編 (2022-07-03)
  8. ORマッパーのTypeORMをTypeScriptで使う (2022-07-27)
  9. Nuxt3入門(第8回) - Nuxt3のuseStateでコンポーネント間で状態を共有する (2022-10-28)
  10. Nuxt3入門(第1回) - Nuxtがサポートするレンダリングモードを理解する (2022-09-25)