プロダクトバックログ項目の明確化の必要性
みなさんこんにちは。@ryuzeeです。
プロダクトバックログ項目からタスクにうまく分割できないので、あればそのコツが知りたいと@riskriskさんからリクエストを頂いたので解説したいと思います。
まずは以下の図を見てください。 これはスクラムにおいて、プロダクトバックログからスプリントバックログへの流れを会議体とともに示したものです（パワーポイント版はこちら）。
実はほぼこの中に全て答えがあります。 まずプロダクトバックログ項目（ストーリーなど）からタスクにうまく落とせない場合は、以下のようなことが原因として考えられます。
- そもそもなんのためにそのプロダクトバックログ項目があるのか分からない
- プロダクトバックログ項目の内容が曖昧または抽象的すぎて、作るべきものが分からない。または人によって著しく成果物のイメージが異なる
- プロダクトバックログ項目に受け入れ条件がないため、何ができたらそのバックログ項目が完了になるのか分からない
- プロダクトバックログ項目の受け入れ条件が抽象的もしくは測定困難（クールな画面とか応答が速いとか）
- 同様にプロダクトバックログ項目のデモの仕方がわからない
- プロダクトバックログ項目が大きすぎて、１つの項目に含まれる作業が膨大になってしまう。それ故抜け漏れが大量に発生する
- プロダクトバックログ項目の他への依存度が高すぎて、具体的な作業内容や作業順序のイメージがつかない
このような状態のままスプリントプランニングを行うと、当然のことながらプロダクトオーナーへの質問が増え、時間が長引くことになります。 したがってそうなる前に事前にプロダクトバックログ項目を定期的に見直し、Readyなプロダクトバックログ項目を用意するようにする必要があります。 それをバックログリファインメントもしくはバックロググルーミングと呼びます。
プロダクトバックログのメンテナンスや優先順位付けはプロダクトオーナーの仕事ですが、開発チームが仕事をしやすいように、リファインメントに際しては開発チームがプロダクトオーナーと協力しながら行う必要があります。 Jim Coplien氏曰く、「Readyなバックログ項目がなければ、開発チームはビーチに行って良い」とのことですが、さすがにそれは難しいので、プロダクトオーナー、開発チーム、スクラムマスターが協力関係でいることが良いと思います。 なお、前述の通り、この作業は定期的に行う必要があります。 なぜならビジネスの環境の変化、スプリントレビュー等からのフィードバックなどによって、作るべき内容や順番は変化し続けるからです。 プロジェクトの初期に一回だけやっても変化に対応できません。
プロダクトバックログはあくまで現時点でのリストであるべきで、一度決めたら固定で進めるという類のものではありません。
なお、タスクがうまくこなせない、タスクが完成しない、という課題においては、一般的に、タスクの粒度が大きすぎる、タスクの完了条件が明確でない、ということが多いです。 まずはタスクのサイズを小さく（4時間以内程度）にしてみるのが良いと思います。 その上で、デイリースクラムやスクラムボードを使って、そのタスクの滞留時間を観測してみます。 例えば、数日間同じタスクに取り組み続けている、ということであれば何らかの問題があることは明らかなので、レトロスペクティブ（ふりかえり）をつかって改善策を検討していくことになります。
![サーバ/インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載! ]](/images/common/book_devops.png)
