プランニング会議は実験室 ！チームと顧客に支えられるスクラムマスターの日々の試み

CI&Tに入社して4年目、スクラムマスターになって１年半、今までは教えられた通りにプロセスを回していました。
しかし、プロセスは私たちを目的地までたどり着かせるツールであり、全てを解決してくれるわけではありません。

プランニングではいつもスプリントバックログを細かいタスクに分けて、それらを時間で見積もっていました。
その見積もりを時間ではなく、日にち単位で見積もったらどうなるのか？
それについて考えて、お客様とより良い関係を築けるように、チームと新しい方法に挑戦してみました。

新しいことに挑戦させてくれる会社、一緒についてきてくれるチーム、その経験について話したいと思っています。

It has been 4 years since I joined CI&T, and 1 year and half since I became a Scrum Master.
When I joined, I learned CI&T process and all these years I've been running it exactly the way I was taught.
Along the time, I also learned that the processes exist to lead us to a certain Goal, they are not a magical solution to all our problems.

On our planning, we used to split the Sprint Backlog into smaller tasks and estimate every one of them in hours. However, what would happen if we changed the estimation from hours to days?
This question was made to me when I was looking for a way to improve the team relationship with the customer. Not accurate estimations was one of our struggles at the time.
Finally, I decided to talk with my team and make an experiment: try a new methodology with my team that could also help us to get more trust from the client.

In this short talk, I'd like to share my experience of new trials, learnings with my team members and how CI&T supported us on this trial.

Transcript

1. プランニング会議は実験室 ！ 2021.1.7 CI&T株式会社 Arissa Nakamura チームと顧客に支えられる スクラムマスターの日々の試み
2. 01 プランニング実験 私とCI&T まとめ
3. 自己紹介 2019年3月 スクラムマスター昇進 2016年9月 テスターとして 入社 自己紹介 2019年2月 Scrum Fest Osaka （スピーカー） 中村 ありさ 2020年1月 RSGT 2020 （スピーカー）
4. https://speakerdeck.com/arissa/xin-zu-ri-xi-buraziruren-ga-rinaziyairuna metorikusuguan-li-nichu-hui-tutahua
5. https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/1 2616/qa
6. • ブラジル創業のリーン・アジャイル・エージェンシー • 従業員：3000人（日本オフィス30人＠錦糸町・東京） • 取引先：J&J、コカコーラ、Google、アステラス製薬等
7. 02 私と プランニング実験 まとめ
8. プランニング会議 プランニング会議はスプリント内のタスクを見積もる場である ビジネスグルーミング・テックグルーミングで挙がってきたソリューションの議論をする タスクを細かくブレイクする
9. 通常のプランニング会議 • 1 Sprintあたりのチームキャパシティ
10. 通常のプランニング会議 プランニングの参加者 スクラムマスター、アーキテクト、開発者、テスターと、可能であれば PO タスク分け チケット管理ツール（JIRA）に連携する為のカスタマイズされた Google Spreadsheetを使う
11. 通常のプランニング会議 • Jira Importer例（タスク分けと時間見積もりを入力する）
12. 通常の日々のメトリックス 開発チームは毎日デイリーで進捗を確認する 時間のバーンダウンチャートと BCPのバーンダウンチャートを監視する BCPは「Business Complexity Points」の略 CI&Tで使うソフトウェアの複雑性を計る単位
13. 通常の日々のメトリックス • 時間のバーンダウンチャート • BCPのバーンダウンチャート
14. 突然な提案 上司から違うやり方でプランニングを行ってるチームが ブラジルの本社にいるとお話しを聞かされた 新しいプランニングのやり方のレクチャーをしてる 人の話を聞いて興味が沸いてきた
15. 変更の承認 レクチャーをしていた人に直接連絡して、 一度ビデオ会議でプランニングの実行法について詳しく聞いた 自分が新しいやり方がわかるようになってから、 参加していたプロジェクトのPMとチームにお話をした チームも実行できると自信がついた後に、 お客様の承諾を得た
16. 新たなプランニング会議 新しいプランニング会議の参加者は変わらず、 スクラムマスター、アーキテクト、開発者とテスター ソリューションの議論は行いますが、詳細までは議論しない 見積もりは「スプリントロードマップ」という、 別のGoogle Spreadsheetを使って行う
17. 新たなメトリックス • スプリントロードマップ（想定版）
18. 新たなメトリックス • スプリントロードマップ（スプリント実行後）
19. 新たなメトリックス • タスクのバーンダウンチャート
20. 新たなメトリックス • タスクのバーンダウンチャートの元になるデータ
21. 変更後 「タスクが遅延してるのが誰となぜおくれてるのか」から 「チームはなぜこのストーリーのデリバリーに遅れたか」に変化 「正確な見積もりを出す、そして納期を守る」から 「品質の良いシステムを作る」のマインドセット 日々のコミュニケーションが改善された
22. 変更後 時間単位だと詳細にチームの進捗を監視することができるが、 日にち単位はSMと連携しないと遅れてるように見える場合がある チームとPMとPOとの信頼関係がないとできない手法 決めた時間にタスクを完了できない場合、 すぐにアーキテクトとSMに相談する
23. 変更後 • チームに送ったサーベイ結果
24. 03 私と プランニング実験 まとめ
25. 時間単位 日単位の見積もり 時間単位の見積もりと日にち単位の見積もりはそれらいい点と欠点がある チームとお客様に合うやり方を探すのが大切
26. 時間単位 日単位の見積もり 「プロセスはツールであり、 全て解決してくれる魔法ではありません。」 どんなプロジェクトでも、状況に適したルートを選び、 チームをガイドすることが スクラム・マスターとしてのチャレンジ
27. ciandt.com THANK YOU