初めてのスクラムマスター-製品のバックログを作成し、作業を設定する必要があります
私は認定スクラムマスターですが、ソフトウェアやプロジェクトではなく日常業務のチームでSCRUMを実装するために、会社のパイロットイニシアチブのSCRUMマスターとして任命された明日まで練習したことはありません。この決定をめぐるすべての政治を想像させてください。
作業は8月1日に開始され、製品の所有者は明日会議を設定して、私とチームに参加しない別の人との製品バックログを作成します。
私の質問：
- 明日、製品バックログの構造を提案する必要があるのは誰か（私またはPO）
- プロダクトオーナーと直接ユーザーストーリーを作成する必要がありますか？
- 私は1時間の会議を持っていますが、私の理解ではそれ以上のものが必要ですか？進め方についてのあなたの提案は何ですか？
私はすべての理論を知っていますが、始めるための非常に実用的なステップが恋しいです。
ご協力いただきありがとうございます ：）
ここにいくつかの詳細情報があります：
- 部門：製品開発（IT以外の製品）
- チーム：7人
- プロダクトオーナー：部門のマネージャーです（チームの7人が彼のチームです）
- スクラムマスター：私はチームにも部門にも属していません。スタッフ機能として働いています。
- 作業の開始：8月1日（ただし、質問でわかるように、POは明日（45日前）に私と一緒に製品バックログを作成したいと考えています）
- 会社：100歳、25,000人の従業員、常にウォーターフォール手法のみを使用小規模ITプロジェクトで進行中の3〜4つのスクラムイニシアチブ（予算は50万ユーロ未満）
明日製品バックログの構造を提案するのは誰ですか（私またはPO）？
通常、製品のバックログを作成するのは製品の所有者です。製品バックログの要点は、ビジネスが必要とする機能を優先順にリストすることです。
プロダクトオーナーと直接ユーザーストーリーを作成する必要がありますか？
バックログの内容は、ユーザーストーリーの内容と注文の両方について、製品所有者の責任です。とはいえ、ユーザーストーリーの作成は、ほとんどの場合、技術チームが関与するものです。
私は1時間の会議を持っていますが、私の理解ではそれ以上のものが必要ですか？続行する方法についてのあなたの提案は何ですか？
古典的なスクラムでは、3つの会議があります。
- スプリントの開始時に、スプリントに含めるストーリーを決定し、開発者がストーリーに対してコーディングできるようにストーリーが十分に定義されていることを確認する計画会議があります。これらの長さは、チームとスプリントの長さによって異なります。私のチームの場合、通常は1時間強で実行されます。
- 各スプリントの間、あなたは毎日立ち上がっています。これは短く、理想的には約10分にする必要があります。製品の所有者が不在の場合があります。
- 各スプリントの最後に、チームがソフトウェアを製品所有者にデモンストレーションするレビューがあります。
私見、これをしないでください。アジャイルクリスタルクリアまたはかんばんに行きたい場合は、あなたの会社に適しています。
スクラムは最悪です、そしてあなたはスクラムマスターであるがチームの一員ではないことによってすでにそれを間違えています！通常、スクラムでは、POがバックログを割り当てる人です。つまり、製品に何を求めているかを決定するのが彼の仕事であるため、彼の仕事は彼が望む機能に優先順位を付けることです。彼はこれを行うためにチームと連絡を取り合う必要があります（チームは何を達成できるか、または彼が実装したい機能に必要な基盤について彼に有益なフィードバックを提供するため）。
これが重要です。アジャイルになりたい場合は、このプロセスにチームを参加させる必要があります。初期設計を決定し、チームに「この作業を行う」ように指示するのは、まあ、非常に滝です。 （そして私はスクラムが一連の2週間の滝に退化する傾向があることを知っています、それはそれを良いことにはしません）。
ですから、計画会議ではチームと一緒に参加してください。 POに、彼が望んでいることをすべての人に伝えるように伝えます。そうすれば、スプリントに割り当てられた時間内に何を達成できるかを彼に伝えることができます。それから彼は姿を消し、あなたが何とか成し遂げたことを彼に示すスプリントの終わりまで戻ってこないはずです。次に、彼がやりたいと思っている余分なこと（または時間がなかった元のこと）を繰り返します。
あなたの仕事は、会議を進行させ、チームを巻き込み、彼が何をする必要があるかを説明したときにPOをそこから追い出すことです。 「チームマネージャー」にならないでください。スクラムマスターは、チームリーダー、チームマネージャー、またはいかなる形態のチームボスでもありません。あなたの仕事は、チームが自分のことを実行できるように明確に保つことです。