#note https://scrumexpansion.org/ 2025/06/11 に実施された Scrum Guide Expansion Pack Launch Event のアーカイブ動画 この動画の中では、なぜ Expansion Pack が必要なのかについて説明している https://www.youtube.com/live/_z3Gvg7VK6g 日本語訳も https://github.com/ScrumGuides/ScrumGuide-ExpansionPack/issues/12 で動いている様子 また背景など含めて https://scruminc.jp/blog/6817/ にも紹介されている ## メモ ※ 2025/06/23 時点でのバージョンを参照している ### 背景 > [2020年版スクラムガイド](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)は短くてシンプルで、今日においても的確です。ただ今日抱えているすべての変化、特にAIによってもたらされる変化について、人々を導くための情報が不足しているだけなのです。拡張パックはスクラムガイドにあるルールを書き換えたわけではなく、それを補完する目的があります。 > ジェフ博士は、スクラムガイドが「固まっていて、決して変わらず、誰もそれについて話そうとしない」状態を終わらせたい、という強い意図がありました。この拡張パックは、GitHubで公開され、**誰もがコメントでき、四半期ごとに更新される**というコミットメントがなされています。つまり、誰もが、拡張パックを変更するために意見を主張する機会があるということであり、拡張パックは変更され続ける、「生きたドキュメント」になります。 > この拡張パックは、新しいスクラムガイドとしてではなく、**2020年版スクラムガイドと矛盾しない範囲で、追加のコンテキスト、プラクティスを提供**しています。 https://scruminc.jp/blog/6817 より したがって、拡張パックはその名の通りスクラムガイドを具体的なプラクティスで補完するような内容になっている。 > This Scrum Guide Expansion Pack explains the _what_ and _why_ of each element of Scrum through a future-looking lens. また拡張パックの中でも上記のように各スクラムの構成要素の "what" と "why" をちょっと未来 (2025年時点での観点でという意味かな？) から整理している ### まとめ 拡張パックの最後に `Scrum Expanded on One Page` というのがあるのでそれをまずそのまま貼る [](https://gyazo.com/1228b07b6e81ed29737b9117a5783e34) 続いて、role (責任), artifact (作成物), イベント (event) それぞれについて拡張パックで気になったことを書いていく ### roleなど に関する補足 - Developers -> Product Developers - おそらくは「開発者」だけではなくプロダクトデリバリーに関わる全員を指す意図を込めた - Stakeholder -> Stakeholder/Supporters - ざっくりチーム外関係者のように書いてたが Stakeholder を「顧客・ユーザー・意思決定者など、プロダクトから価値を得るあらゆる関係者」として具体化している - またプロダクトに対して支援 (e.g. 経営者やリーダーなどプロダクトへの投資者など) する Stakeholder のタイプを追加している - スクラムを推し進めてくれる外部の協力者も含まれる ### event などに関する補足 - Sprint Review は双方向のワーキングセッションであり、デモだけをする場ではない - > It is an interactive, collaborative working session. - > The Sprint Review inspects many things related to the Product, such as the Product Goal, Product Backlog, the Sprint Goal, the learnings, the Increment, Stakeholder expectations and limits, result feedback, side effects, progress with the Product, the market, as well as forward-looking, e.g., what new ideas and opportunities have emerged, potential next steps. ### artifact などに関する補足 - Definition of Done -> Definition of Outcome Done, Definition of Output Done - Output に関する DoD もですが、ある特定の機能を実現、デリバリーするにあたってどういう Outcome を期待するかという話も追加 ### その他の観点でメモ > For complex work, like building Products, there are more unknowns than knowns, expertise alone is valuable but insufficient, and cause and effect are only coherent in retrospect. [[Cynefin フレームワーク]] でも同様の整理がされている (拡張パックでも出てくる) が、専門性は重要という前提は変わらず、結果からしか正解がわからないという点を強調していてよかった。 > A self-managing (49) Scrum Team checks whether they are on track, takes action when not on track, decides how to work, resolves Scrum Team conflict, and fixes problems in the Scrum Team. 自己組織化について、検査と適応を通した自己修復のような表現が結構しっくり来ててよかった > Cadence > Working in Sprints provides a consistent rhythm that helps the Scrum Team focus on clear, short-term goals. This cadence supports regular inspection and adaptation, enabling the Scrum Team to learn and adjust informed by feedback. Over time, it builds a sustainable pace of delivery, improving predictability and fostering continuous improvement. 一定のリズムが定期的な検査と適応を促進させるというのも説明として触れていてよかった。 [[Scaling People]] でも読んだけど、ケイデンス という言葉を最近よく見る (もしかすると ジョシュアツリー というだけかもしれないが) 気がする > The Scrum Team crowdsources possible solutions without judging them too quickly. If the potential value is high but there is a lack of evidence that the value can be realized, the Scrum Team should do research, assumption testing, or build simple prototypes they can test with real customers, decision-makers, or users. 価値が高いと考えているものの、証拠が不十分なのであれば探索せよというのはよかった。 つまりコードを書くことが Product Developer の仕事ではないということ。 > Increments may be delivered to Stakeholders or released prior to the Sprint Review. _The best value validation is attained through result feedback. > ... > The Increment is released as soon as practically possible, considering the need for early result feedback. スプリントレビューを待つ必要はないよという話 (割とスプリントレビューをリリースの頻度と勘違いしている人がいる気がする) > Multi-Scrum-Team Products > ... > the ideal is still only one Product Owner, who should be a leader for the Product. To allow the Product Owner to handle multiple Scrum Teams on the same Product, the Product Owner often becomes more strategic and delegates problems to solve and opportunities to the Product Developers, including, for example, aspects of Product design or Product management. 複数にスケールする場合の話も言及されていた スケールするのは慎重にやれというのは主張は変わらずで Product Owner は1人が理想とのこと (Scrum@Scale で複数人で Meta Scrum を構成するという主張なので意外) またその際には Product Developer がプロダクト周りのタスクをより多く請け負う必要があるという話も納得感ある > In the liminal between complex and ordered, this is Scrum’s default sweetspot: 昔 [# AgileByExample 2017: prof. Dave Snowden - Cynefin in practice](https://www.youtube.com/watch?v=HVx_jIBqumc) で Dave Snowden さんが話してた内容にも触れていて興味深い ### 紹介されている参考資料など 紹介されている参考資料のうち個人的に面白かったものもメモしておく > 7 Marquet, L. D. (2013) Turn the Ship Around! A True Story of Turning Followers into Leaders. Portfolio. > 8 Marquet, L.D. (2021) Leadership is language: The hidden power of what you say and what you don’t. Nakskov, Denmark: Nota. [[TURN THE SHIP AROUND]] にも触れている！ > 80 _LeSS (n.d.) ‘Why LeSS? Achieving adaptiveness’. Available at: [https://less.works/less/framework/why-less](https://less.works/less/framework/why-less)  (Accessed: 17 May 2025)._ > 136 _Leffingwell, D. and Knaster, R. (2023) Safe 6.0 framework, Scaled Agile Framework. At: [https://www.scaledagileframework.com/](https://www.scaledagileframework.com/)  (Accessed: April 5, 2023)._ > 137 _Sutherland, J. (2021) Scrum@Scale - the scaling framework created by dr. Jeff Sutherland, Scrum@Scale Framework. At: [https://www.scrumatscale.com/](https://www.scrumatscale.com/)  (Accessed: April 5, 2023)._ > 141 _Schwaber, K. et al. (2021) Online nexus guide, Scrum.org. At: [https://www.scrum.org/resources/online-nexus-guide](https://www.scrum.org/resources/online-nexus-guide)  (Accessed: April 5, 2023)._ 当然 LeSS や [[Scrum@Scale]] や SAFe や Nexus などにも触れている > 113 _Cagan, M. (2024) Transformed: Moving to the Product Operating Model. Hoboken, NJ: Wiley._ > 114 _Cagan, M. (2025) ‘The Product Operating Model’, Silicon Valley Product Group, 17 March. Available at: [https://www.svpg.com/the-product-operating-model/](https://www.svpg.com/the-product-operating-model/)  (Accessed: 8 June 2025)._ > 115 _Cagan, M. (n.d.) ‘The Product Operating Model: An Introduction’, Silicon Valley Product Group. Available at: [https://www.svpg.com/the-product-operating-model-an-introduction/](https://www.svpg.com/the-product-operating-model-an-introduction/)  (Accessed: 8 June 2025)_ [[The nature of product - Marty Cagan, Silicon Valley Product Group - Lenny's Podcast]] などで登場する Marty Cagan さんの記事にも触れている！ > 129 _Appelo, J. (2023) Sometimes, you *don’t* want focus, unFIX. At: [https://unfix.com/blog/sometimes-you-dont-want-focus](https://unfix.com/blog/sometimes-you-dont-want-focus)  (Accessed: 14 January 2024)._ > 130 _Appelo, J. (2023) Bets and objectives, unFIX. At: [https://unfix.com/bets-and-objectives](https://unfix.com/bets-and-objectives)  (Accessed: 14 January 2024)._ [[unFIX]] にも触れていて意外 > 138 _Skelton, M. and Pais, M. (2023) Team topologies, Team Topologies. At: [https://teamtopologies.com/](https://teamtopologies.com/)  (Accessed: April 5, 2023)._ [[Team Topologies]] にも触れている！ > 142 _Quartel, R. et al. (2024) FaST guide, Fluid Scaling Technology. At: [https://www.fastagile.io/](https://www.fastagile.io/)  (Accessed: December 6, 2023)._ FaST にも触れている！