PBIの分類
復習: スクラムガイドにおけるプロダクトバックログとPBIの説明
プロダクトバックログに含まれているアイテムだから、プロダクトバックログアイテム
プロダクトバックログは「プロダクトの改善に必要なもの」の一覧であり、
創発的(emergent)かつ順番に並べられている(ordered)
プロダクトバックログには、コミットメントとしてプロダクトゴールが含まれる
プロダクトバックログは、スクラムチームが行う作業の唯一の情報源である
前提
スクラムガイドに示すようなシンプルな世界観を実現できているスクラムチームであれば、スクラムの価値基準を満たすプロダクトゴールとPBIを用意できるので、それでよい。現実が「そうではない」場合、その度合いに応じてPBIは複雑になる
「プロダクトの提供する価値」には、ユーザーに対する価値、ステークホルダーに対する価値、開発者に対する価値があるという整理をすれば、何を入れてもよいか(何を入れるべきでないか)はわかりやすくなると思う
スクラムチームのメンバーが専任でないケースはパラメーターが多すぎるので、ここでは考えない
なによりも優先されるべきもの
Defect (欠陥): 本番環境に出ていってしまった不具合を直すのが最優先
なんならスプリントを止めてしまってもいいはず
プロダクトの改善に必要なもの
Idea(アイデア): いわゆるプロダクトディスカバリー的なやつと捉えればよさそう(検証必要な仮説とか)
Behaviour(振る舞い): いわゆる「機能(feature)」はここ
Structure(構造): いわゆるアーキテクチャや設計はここ。ランタイムの構成なんかも含まれそう
技術的負債(って言わないほうがいいと思う)もまあ、ここですかね
Ops的なもの
トイルだろうが何だろうが必要なら入れるしかない
"スクラムチームの効果を改善するために役立つ変更"
スクラムガイドではスプリントレトロスペクティブのセクションに「スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。」とある
しかし、チームの練度がスプリントバックログの計画としてすべて対応できる状態でもなければ、すべてをこの対応でおこなうのは難しいので、PBIにしてもいいんじゃないかな
スクラムチームの改善を「プロダクトの改善に必要なもの」と解釈すればいいだけかもしれない
けっきょくは
プロダクトゴールの定義の仕方次第な気もする。総合的に考えて「いい塩梅」のプロダクトゴールを定められるかどうかが鍵になるのでは
各スプリントでそれぞれの割合をどうするかは「要はバランス」