プロダクトゴールが導入された理由は何ですか？
スクラムガイド2017までは、プロダクトバックログアイテムが、プロダクトの長期的な目的とどのように結びついているのかが明確ではありませんでした。その結果として、プロダクトオーナーは全体性や達成したい価値に注力するよりも短期的な作業に集中しがちになり、開発者は毎スプリントでインクリメントを作ることに注力するだけの機能工場（フィーチャーファクトリー）になりがちでした。...
View Articleスクラムマスターの仕事はどう管理したらよいですか？
スクラムの3本柱は透明性・検査・適応です。 また、5つの価値基準の1つに公開があり、スクラムガイド2020では、「スクラムチームとステークホルダーは、作業や課題を公開する」とあります。これを踏まえると、スクラムマスターの仕事は、他のスクラムチームのメンバーから見えるように管理しましょう。...
View Articleアジャイルにおいて、チームが機能しているというのはどういう状態ですか？
列挙するとキリがありませんが、以下のような状態を想像するとよいでしょう。チームが安定的かつ継続的に価値を提供してるチームが失敗から学習し、成長を続けている問題が発生しても多くはチーム自らで解決できる管理者がいなくても、自らの判断で行動できるチームが「自分たちが機能しているというのがどういう状態なのか」を考えて実践と改善を積み重ねている
View Articleプロダクトオーナーが会議や休暇で不在のときはスプリントの長さを変えてもよいですか？
いいえ、スプリントの長さを変えてはいけません。 スクラムでは、スプリントという固定の期間を繰り返すことでリズムを作り、検査と適応を繰り返します。 スプリントの長さを変えると、検査が十分でなくなったり、本来適応すべき問題を隠したりしてしまいます。例えばこの質問の例では、プロダクトオーナーがスクラムイベントの時間に会議を設定していること自体が解決すべき問題です。...
View Article年末年始やお盆などの長期休暇がある場合はスプリントを長くしてもよいですか？
スクラムガイドでは、「スプリントの期間は固定である」「スプリントが終了したら速やかに次のスプリントに入る」としており、年末年始やお盆などの長期休暇に関する記述はありません。すべてのイレギュラーケースを想定するのは不可能なので記述がなくて当然なので、スクラムやアジャイルの原理原則を踏まえて対応を考えます。スクラムではプロダクトの検査と適応によってリスクを制御するため、スプリントレビューがとても重要です...
View Articleリモートでアジャイル開発できますか？注意点があれば教えてください
はい。リモートでアジャイル開発をうまく進めている例は多数あります。 たとえばリモートを活用することで、ステークホルダーがスプリントレビューに参加しやすくなるといったオンサイトにない利点もあります。 ただし、全体で見ると、プロセスの観点ではオンサイトと比べて大きな違いはありません。一方で、コミュニケーションや人間同士の関係性に関しては大きな違いがあります。...
View Articleスクラムマスターはデイリースクラムに参加しますか？
スクラムマスターの責任は、スクラムガイドに書かれたスクラムの実践とスクラムチームの有効性に責任を持つことです。 デイリースクラムについては、開発者だけで確実に開催されるようにし、その上でデイリースクラムの目的を開発者が果たせるようにします。...
View Articleプロダクトオーナーは開発しているプロダクトの技術的な知識をどこまで持つべきですか？
スクラムガイドでは、「プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである」とあります。...
View Articleプロダクトバックログにおける優先順位と順番の違いは何ですか？
スクラムガイドでは2010年版までは「優先順位」という単語が使われていましたが、2011年版以降は「順番」「順序付け」という単語を使っています。 これには明確な意味があります。優先順位（Priority）は、各プロダクトバックログアイテムの重要性や緊急性を評価する指標です。 これは、ビジネス価値、ユーザーへの影響、リスク、コスト削減効果など、さまざまな要素を考慮して決定されます。...
View Article初期の段階でいつリリースできるかを予測するのにストーリーポイントは使えますか？
そもそも論として、プロダクトバックログアイテムを見積もってリリース時期を決めるのではなく、先にプロダクトゴールとそれを達成したいおおよその期間を決めることをお勧めします。 スクラム（に限らず）の目的は、すべての機能を作ることではなく、ゴールを達成することです。 ゴール達成に向けた実現方法には柔軟性があったほうが、達成の可能性が上がります。...
View Articleスクラムでは「成果物」ではなく「作成物」と呼ぶのはなぜですか？
スクラムでは、プロダクトバックログ、スプリントバックログ、インクリメントのことを作成物（Artifacts）と呼びます。最大の理由は、スクラムによるプロダクト開発での「成果」は、プロダクトの利用者に価値を届けることに他ならないからです。プロダクトバックログは、スクラムチームの持ち物であり、これ単体で誰かに提供するものではありません。つまりプロダクトを開発する上での中間作成物に過ぎません。スプリントバ...
View Articleスプリントレビューにステークホルダーが参加していますが、あまり反応やフィードバックがありません。どうしたらよいでしょうか？
スプリントレビューでステークホルダーの反応が薄い場合、いくつかの要因が考えられます。たとえば次のような場合です。レビューが進捗報告的になっており、フィードバックをしにくい雰囲気になっているフィードバックを求められているという認識がステークホルダー側にないステークホルダーの関心がないインクリメントを提示している改善するには、以下のような点を考慮するとよいでしょう。スプリントプランニングでスプリントゴー...
View Articleスクラムチームのメンバーを入れ替えるときに気をつけることは何ですか？
まず大前提として、スクラムでは安定したチームを推奨しています。 これは、チームの中での信頼関係や作業のやり方が成熟するにはある程度の時間と経験の蓄積が必要だからです。 そのため、人の入れ替えがあると、チームに影響が出る可能性があります。とはいえ、現実の組織では異動や退職、新規メンバーの追加などで、チームの構成が変わることもあります。 その際は、以下の点を考慮するとよいでしょう。(1)...
View Article開発者からイベントのせいで開発できる時間が減ってしまうと言われますがどうしたらいいですか
このような声が上がる背景には、「より多くの時間をコードを書くことに使いたい」「イベントが多くて集中できない」といった気持ちがあるのかもしれません。しかし、スクラムは「効率（Efficiency）」ではなく「効果（Effectiveness）」を重視するフレームワークです。単に開発時間を最大化することが目的ではありません。まず押さえておくべきは、スクラムで定義しているイベントは必要最低限のものであり、...
View Articleステークホルダーとの調整はすべてプロダクトオーナーがやるのでしょうか
そんなことはありません。スクラムガイド2020の日本語版に以下のような記述があります。スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。このように、ステークホルダーとのさまざまな関わりはスクラムチーム全体の責任であり、プロダクトオーナーだけのものではありません。...
View Article見積もれないプロダクトバックログアイテムがあるときはどうすればいいですか？
「見積もれないプロダクトバックログアイテムがある」という状況自体は問題とは限りません。 見積もれないというのは、「プロダクトバックログアイテムに不確実性や情報の不足がある」ことを示す正当な見積り結果であり、それが把握できているのはむしろ健全です（見積もっていないのとは違います）。見積もれていないアイテムすべてですぐに対応が必要とは限りません。...
View Article