ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

スプリントでのプロダクトバックログアイテム着手の方法

みなさんこんにちは。@ryuzeeです。

スプリント中に対象のプロダクトバックログアイテムにどのように取り組んでいくか、というのは意外とよく質問を受けるので、ここで整理しておきたいと思います。 話を分かりやすくするために、スクラムボードを見ながら考えていきます。

アンチパターン1:プロダクトバックログアイテムごとに担当を決める

プロダクトバックログ単位で人をアサイン

まず最初に避けるべきなのは、プロダクトバックログアイテム単位で担当を決めてしまうやり方です。スクラムでは誰かが開発チームのメンバーに対して作業を割り当てることはしませんが、割り当てているかどうかに関係なく、開発チームのメンバーが「特定のプロダクトバックログアイテムにサインアップして、そこを全部担当する」というのも避けるべきです。 このやり方をした場合には、次のような問題が発生します。

  • 開発チームのメンバーは自分がサインアップしたプロダクトバックログアイテムの完成ばかりを気にしてしまう
  • 難易度の高いものや未経験のものをやりたがらない、という力が働いてしまうこともある
  • すなわちチームの成果より個人の成果を重視する方向になりがち
  • 全体で見たときに、スプリント終了時点で、「すべての項目があとすこしで終わる」という状態が頻繁に発生する可能性が高い
  • スクラムでは未完成のものは、あと少しだろうがなんだろうが成果としては扱わない。すなわちその場合開発チームとしての成果が0になってしまう
  • 個人の状況に左右されやすいため、スプリント単位での成果の量(ベロシティ)が安定しなくなる
  • したがってプロダクトオーナーからみた場合、将来の予測性が低く、計画がたてにくくなる

アンチパターン2:散発的に色々なプロダクトバックログアイテムに手をつける

散発式な作業

次に避けるべきなのは、色々なプロダクトバックログアイテムに散発的に取り組んでしまうやり方です。 開発チーム内にスキルセットの偏りがあって、特定の人しか特定の作業ができない、といった場合に発生しがちです。このやり方をしてしまった場合の問題点は上記のアンチパターン1と同じで、「プロダクトバックログアイテムが完成しない」リスクが高いことです。

また、このようなやり方をしている場合、潜在的に以下のような問題がある可能性もあります。

  • 開発チーム内にスキルセットの偏りがあって、特定の人しか特定の作業ができない(が特定の人がいつも忙しい)
  • 似たような作業は、同じタイミングで実施した方が効率がよい、という思い込みがあって、複数のプロダクトバックログアイテムの作業をまとめてやってしまっている
  • アーキテクチャ上の問題があって、複数の開発メンバーが同時に特定のコードを触りにくくなっている。コンフリクトが頻繁に発生して大変なので、それが起こりにくいところを着手してしまっている

アンチパターン3:プロダクトバックログの優先順位を無視して取り組んでしまう

優先順位を無視した取り組み

絵は少々極端ですが、選択したプロダクトバックログの先頭から順番に着手するのではなく、順番を無視して着手しているのを見かけることもあります。 しかしこれはプロダクトオーナーに対する冒涜行為です。プロダクトオーナーが順番をつけるのは、その順番につくることで成果が最大になると考えたからです。もしこのやり方をして、スプリント終了時に上位の項目が完了しなかった場合、そのスプリントで本当に手に入れたかったものが手に入らないことになってしまいます。

このようなやり方をしている場合には、以下のような問題がある可能性があります。

  • プロダクトバックログアイテム間で依存関係があり、下位の項目が終わらないと上位の項目が終わらないようになっている
  • プロダクトバックログのリファインメントが機能していない。事前に開発チームがその順番では作れない(作りにくい)ことをプロダクトオーナーに伝えられておらず、適切な並び順になっていない

じゃあどうするのか?

ここまで見てきて、もうどうすれば良いのか分かっていると思いますが、プロダクトバックログアイテムにどう取り組んでいくか整理しておきましょう。

  • 原則として、スプリントで着手するプロダクトバックログアイテムは、上位の項目から着手する
  • 幅広くいろいろなプロダクトバックログに着手するのではなく、上位の項目から「1つづつ」「全員でよってたかって」「完成させる」
  • すなわちプロダクトバックログアイテムの単位での同時仕掛りの数をなるべく少なくし、かつ完成までのリードタイムを短くする
  • 完成させるためには、プロダクトオーナーの受け入れ確認が必要なので、項目が1つでも完成したら速やかに受け入れ確認を依頼する。すなわちバッチサイズを大きくしない
  • 完成させることが何より重要なので、効率ばかりを追求しない

よい取り組みの例

最後に

うちではこうやってる!というのがあればぜひ教えてください。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 【資料公開】アジャイル開発プロジェクトの始め方
次の記事 スクラムの導入状況のサマリー (The State of Scrum Report 2017)

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World