JA 
EN 
IT 
ES 
計画石化
スプリント計画の結果は事前に決定されていますか?会議は型にはまった感じですか？それともまったく鈍いですか？もしそうなら、あなたのチームは私が「計画石化」と呼んでいるものに達しています.会議は、会議を通じて提供される柔軟性と創造性が低下するところまで来ました。石化しています。チームに悪影響を与えるレベルにまで達している可能性もありますが、すべてが失われるわけではありません!スプリント バックログの形成が、厳格な一連の要件を「承認」するためのチームの設定になっている場合、彼らが自己組織化チームになる方向に進んでいるとは思えません。彼らがスプリントバックログをまとまりのある作業単位と見なすのをやめるとすぐに、結果として生じる増分自体が「ちっぽけな」もの、つまり価値がないと認識される可能性があります。スプリント計画会議で見られる美しさがあります。それを明らかにする方法を知る必要があります。
基本的に、スプリント計画の目的は 2 つのものを生み出すことです。まず、スプリント目標 – インクリメント全体の統一された目的です。チームが目指すゴールポストです。それは測定可能で、達成可能で、固定されている必要があり、最も重要なことは、それを達成する方法で創造性を発揮できるようにすることです。次に、スプリント バックログ自体 – 目標を達成するために必要と思われる作業です。 「可能性が高い」という言葉を使用したことに注意してください。スクラムでよくある誤解は、チームがスプリント バックログを「完了する」ことを約束しているというものです。実際、彼らはスプリント目標の達成にコミットしています。これは重要な違いです。チームは、進捗状況の調査に基づいてアプローチを適応させることができます (「計画に従うことよりも変化に対応すること」に何か意味はありますか?)。
これは私があなたに試してみることをお勧めするテクニックです。自己組織化、創造性を構築し、集合的な目的に集中するように働きます。重要なのは、信頼が必要なことです。
すべてのスクラム チームが参加しており、チームが時間をかけて洗練された適切に順序付けられた製品バックログがあると仮定しましょう。プロダクトオーナーは、自分が達成したいことを知っています。
ステップ1： プロダクト バックログを (比喩的に) 捨てます。計画会議を推進するために製品バックログを使用しないことをチームに通知します。
ステップ2： プロダクト オーナーに、次のスプリントに求める価値を明確に定義するように依頼します (具体的にはチケットについて言及しないでください)。
ステップ 3: 開発チームは、プロダクト オーナーと協力して、スプリント ゴールに向けた初期作業のチケットと承認基準を定義します。彼らはまだプロダクト バックログを見ていません。
このアプローチは何を達成しますか? あなたはプロダクトバックログの松葉杖を取り除いています.彼らは、計画された作業を個々のチケットの集まりではなく、形成された増分として見ています。彼らは協力しており、サインオフしていません。彼らは創造的になり、関与する力を与えられます。要するに、彼らはスプリント目標の価値に賛同します。ただし、セッションの最後に製品バックログに再度アクセスしてアプローチを確認することを忘れないでください。それが依然としてイベントを推進する主要な成果物であることを忘れないでください。
私にとって、スプリント レビューは全体的な進捗状況を測定する場所ですが、私が気に入っているのはプランニング ミーティングです。なぜ？それは、私のチームが次の挑戦にどれほど熱意を持っているかを知ることができるポイントだからです.結局のところ、彼らがスタートラインで腹に火をつけていなければ、レースに参加したくさえなかったときに、フィニッシュラインでどのように感じると思いますか?