チームでスクラム導入中ですが、「どこまで決めるべきか」の塩梅がわかりません。
スケジュールやスコープの確約度合い
スクラムの思想では、「不確実性を前提に、スプリントごとに調整する」のが大切だと理解しています。
ただ実際には、ステークホルダーからはいつまでに何ができるのかを求められます。
曖昧にすると不安がられるし、かといってリリース日やスコープ、仕様をガチガチに固めると結局ウォーターフォールと変わらない気がして、スクラムでやる意味があるのか疑問に感じています。
イベントの運用ルール
リファインメントやレトロスペクティブを正しく回そうとすると、pbiのフォーマット整備、詳細仕様の調整、アジェンダの準備、ファシリの進行手順、振り返り用のデータの収集、振り返りフォーマットの整備…とやることが増えていきます。
ルールを決めないと見積もりや振り返りの精度が出なそうで怖いのですが、決めすぎると運用が重くなって本末転倒な気もします。
「開発に集中したいのに会議やその準備に時間取られてる」という状態になりかけています。
どちらも「決めすぎても決めなさすぎてもダメ」で、ちょうどいい落としどころが見えていません。
皆さんのチームではどうされていますか？
回答7件
#2
総合スコア22
投稿2026/01/27 02:19
編集2026/01/27 13:46スクラム導入中ですが、「どこまで決めるべきか」の塩梅がわかりません。
曖昧にすると不安がられる
スプリント期間は任意の期間が選択できます。
PBIを小さくして、スプリント期間が短ければ決めやすくなるのではないでしょうか。
また、スプリント期間が長いことが原因で成果物を見せるまでに時間がかかっているのであれば、スプリント期間を短くしてステークホルダーやプロダクトオーナーに細かく見せてあげる環境ができれば「進んでいるんだな」という実感を与えることができるのではないでしょうか？
実際に期間を短くした影響で開発に影響が出てしまう場合はステークホルダーやプロダクトオーナーと交渉するべきでしょう。
お互いがやりやすい環境を話し合って折り合いをつけるべきです。
また、スクラム開発を進めていくと「前回はAというPBIに3日かかり、BがAに似ているので前回の慣れも考慮してBは2日程度だろう」という具合にコツがつかめてくるはずです。
スクラムに長期間取り組むことで慣れてきてやりやすくなる事もあります。
リリース日やスコープ、仕様をガチガチに固めると結局ウォーターフォールと変わらない気がして
スクラムの前提で個々が自発的に動くという事が必須条件です。
プランニングやリファインメントの時間に仕様をガチガチに固めるのではなくゴールの認識は必ず一致させ、仕様は簡易的に設定して、実際の細かい仕様は必要に応じて担当者と開発者が会話して決めるべきです。
リファインメントやレトロスペクティブを正しく回そうとすると、pbiのフォーマット整備、…
そもそもスプリントが動き出している状況でPBIのフォーマットを気にしている状態は非常にまずいです。
フォーマットが決まっている前提で動き出し、スプリントを進めていく中で現在のフォーマットを少しずつ空いた時間で改良していく程度にするべきでしょう。
また、「正しく回す」という定義が曖昧ですがあくまで開発効率を良くしたり、よりよいプロダクトを作ることを目的として設ける時間のはずです。
リファインメントやレトロスペクティブの時間を一定時間必ず設けることが目的ではないです。
「開発に集中したいのに会議やその準備に時間取られてる」という状態になりかけています。
複数開発チームが存在する前提であればスクラムマスターを採用する事で解決すると思います。
数チーム程度であれば「やり方が良くない」という気がします。
ルールを決めないと見積もりや振り返りの精度が出なそうで怖い
ルールを決める事を怖がっているような文章にみえますが、ルールが決まることで時間短縮につながることもあります。ルールが曖昧なことで開発チーム内ですら認識の齟齬が発生して無駄に時間が消費されることもあります。
細かい話だと表記揺れなどが該当します。
同じ意味であるにもかかわらず言い方を変える事は避けるべきです。
言い方を変えるからには何らかの理由が必要です。
他にも、以下のような事例が身近にありました。
Xさんは「機能Aの事をA」と呼び、Yさんは「機能Bの事をA'」と呼ぶ場合、Zさんからみると「AとA'何が違うの？」「Xさんが言っているAと、Yさんが言っているA'は呼び方が似ているが機能は全く別であることを前提に考える」などと無駄に考える必要があります。また、Zさんが確認せずに勝手に解釈した場合は「似た呼び方をしているが、実は同一機能ではなく機能Aと機能Bが存在していた。機能BについてのPBIだったが、機能Aについて実装してしまった」と後から気づくことになり、時間を無駄に消費することもあるでしょう。
そして、認識の差が「ステークホルダーと開発チーム」だった場合が一番良くないですね。
#4
総合スコア22
投稿2026/02/02 03:21
そうですね。
ユビキタス言語というものもありますので是非上手く活用してみて下さい。
#6
総合スコア241
投稿2026/02/09 03:04
スクラムも一つの手段なので、目的をちゃんと持てていればそれなりの運用になると思います！
バーンダウンなどは、スクラムにおける期日管理として優秀だと思うので、導入してみてはいかがでしょうか！
あなたの回答
tips
プレビュー