PBI（プロダクトバックログアイテム）とユーザーストーリーについて調べてみた。
ほんと、今更なのですが、PBI（プロダクトバックログアイテム）とユーザーストーリーの関係性について調べてみました。
PBIではユーザーストーリーが主にあるべきなのか？いやいや、PBIってフィーチャー（機能）じゃないの？とか、ようわからんくなったものでですね。
今、うちのプロジェクトのPBIでは、（ちゃんと決めたわけではないのですが、流れから、、^^;）「①基本あるフィーチャー（機能）を作成するもの」と、「②結合的なテストとしてあるユーザーストーリーが実施できることを確認するもの」「③その他（休暇や引越しなど）」となっています。
そして、最近、特に②が良くない気がしていたのです。。。なんかここだけウォーターフォールっぽぃですよね(;´Д｀)
公式「スクラムガイド（2017年 日本語版）」を確認
プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正
をすべて一覧にしている。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性が
ある。プロダクトバックログアイテムには、「完成」時にそれを確認するためのテスト記述も含まれて
いることが多い。
んー。特に「ユーザーストーリー」っぽぃ事は書いてないですよね。他、資料中探しても「ユーザーストーリー」に対する記述もなしでした。
この程度の書き方しかしてないので、我々のプロジェクトで①で機能を作って、②で流れを確認するといった、別途ユーザーストーリーを確認するという事はあながち間違いというわけではないのかなぁ。。と思うわけです。
元ソース：
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
どうやらユーザーストーリーはXPからの派生のようです
オージス総研では、このように書いてます。
スクラムはコンパクトなアジャイル開発フレームワークとして誕生したため、プロダクトバックログ項目の表現形式や定義プロセスについての具体的な方法は当初既定されていませんでした。スクラムが発展する過程で、XP（eXtreme Programming）というアジャイル手法の考え方を取り入れ、ユーザーストーリーを用いてプロダクトバックログ項目を定義することが今では一般的です。
ぬお！！
ってことは、XPから取り込んだ手法で、プロダクトバックログ項目（PBIと同義ですよね？）はユーザーストーリーを使って定義するという事か！
流石は、オージス総研！！
（いずれ、研修など受け行ってみたいなぁとかいう思いもあり、たまにウォッチしてますｗ）
元ソース：
www.ogis-ri.co.jp
まとめ
今までやっていたやり方が決して悪いという事ではないと思います。
ただ、モヤっとしてたのが、「ある１つのPBIである機能が出来上がった時点で、その機能を含めたなんらかのユーザーストーリーができるはずでは？そういうのまとめてやるものではないのでは？」と疑問に思っていたのです。
今回、調べたことでこのモヤモヤ感は解決です。
今後は、各PBIでユーザーストーリーを記載して、「このPBIで開発する機能ができることによって、ユーザーがやれるようになる事」を明確にしたいです。そして、それができるようになったという事を完了条件にしたいと思いました。
おまけ
ユーザストーリーについて、↓のスライドも役に立ちます。
ユーザーストーリー駆動という考え方もあるようです。
