Scrum の基本的な進め方を完全に理解しようぜ

はじめに

現在、コミットしているプロジェクトは去年の 11月頭から Scrum を導入し Sprint などの Scrum イベントを回しつつプロジェクトを進めています。その中で社内の Scrum Master さんに Scrum の概要や Scrum イベントについて教えてもらったり、社外の Scrum 研修でワークショップを体験したり、直接手を動かしながら気づいたことが色々あるのでざっくり整理してみたいと思います。去年の僕みたいに Scrum の定義が曖昧な方や Scrum について全く分からない方に読んでいただけると幸いです。

Scrum のメリット

• プロジェクトの状態が可視化されるので把握しやすくなる
• 役割がはっきり分離されているから働きやすい
• チームワーク向上によって目標達成が早くなる

Scrum の概要

• 複雑な問題に対して対応できるもの
• 価値を生み出す軽いフレームワーク

Scrum の要素

役割

• Product Owner
  • Product の What を担当
  • Product Backlog の管理
    • Product Backlog Item の作成
    • Product Backlog Item の優先順位付け
    • Product Backlog Item の完了を判定
• Scrum Master
  • Scrum プロセスの管理
  • チームの働き方を最適化
    • Scrum について教育
    • サポート
    • ファシリテーター
    • コーチング
• Developer
  • Product の How を担当

作成物

• Product Backlog
  • 大体な計画
    • Product Backlog Item を作成
      • ユーザーが得られる価値を基準
    • Product Backlog Item の優先順位を決め
• Sprint Backlog
  • 詳細な計画
    • Product Backlog Item を細かい作業に分離
    • Sprint 途中で追加される作業も存在
    • 作業は 1日で終える単位が好ましい
• Increment
  • Sprint で完了した作業
  • ユーザーが利用可能な状態
  • 完了の定義を満たす必要がある

イベント

• Sprint
  • 間隔は 1、2週間が一般的
  • 他のイベントの上位レイヤー
• Sprint Planning
  • Sprint の設計
    • 目標を設定
    • 優先順位に基づいて Product Backlog Item をピックアップ
    • ピックアップした　Product Backlog Item を細かい作業に分離
    • 作業ごとに Story Point を付与
      • Story Point の単位は時間ではなくチームごとに異なる
        • つまり、Sprint に参加するメンバーのパフォーマンスによって違う
• Daily Scrum
  • Sprint の状態を毎日確認
    • Sprint が目標通り進められているのか？
    • 追加作業は要らないのか？
• Sprint Review
  • プロダクトの振り返り
  • Product Owner が開始
  • Stakeholder と話し合いながら今後の動きを決定
    • (必要であれば） Sprint で完成したものを見せる
    • Feedback をもらう
    • Product Backlog Item に対する進捗ついて議論する
    • 今後の予定などを共有
  • Stakeholder に対して承認をもらう時間ではなく
• Sprint Retrospective
  • 働き方の振り返り
    • Fun/Done/Learn
      • 明るい雰囲気
        • ネガティブな箇所がないため
    • KPTA
      • 真面目な雰囲気
        • プロブレムが言えるため
  • 根本的なプロセス改善のツールとして利用

その他

• Sprint Cancel
  • 障害対応が重かったり 2日以上かかる緊急対応などが割り込み作業としてできた場合、Product Owner の判断で該当する Sprint をキャンセルすることができる

Scrum の流れ（個人的に考える）

1. Role を決定する
   • PO: Product Owner
   • SM: Scrum Master
   • DEV: Developer
2. PO が製品の目標に基づいて Product Backlog Item の洗い出しを行い、優先順位を決める

3. Sprint Planning で Product Backlog Item の細かい作業を洗い出して、それぞれの作業に Story Point を付与する。Sprint の作業日数をもとに消化できそうな作業をピックアップする

4. SM と DEV は毎日 Daily Scrum を行い、作業を消化していく

5. PO と DEV は定期的に Backlog Refinement を行い、Product Backlog Item の見直しなどを実施。加えて Product Backlog Item の完了を判定する作業をやっても構わない

6. PO は Sprint Review を開始し、Stakeholder にデモを見せたり、Product Backlog Item の進捗などを共有する

7. PO と SM, DEV は働き方の改善を重点的に Sprint Retrospective を行う

8. また 3 に戻って Sprint Planning を行う

終わりに

これまで Scrum Master の役割を勘違いしていたり、そもそも Scrum Master が必要なロールなのかっていう疑問があったんですが、結構はっきりなった気がします。Scrum Master は PO と DEV, Scrum イベントが入っている Sprint っていうコンテナをうまく回していくロールを持っている感じなので、Scrum Master の能力次第でプロジェクトの雰囲気やスピードなどが変化されていく気がします。固定観念を持っていた自分を反省します。

この記事が誰かのお役に立てれば幸いです。

以上、CX事業本部 MADチーム、キム (@sano3071) でした。