プロダクトバックログを作るときにどんなことを考えているだろう？とふと思ったので書きつらねていきます。
プロダクトのユーザは誰か？
プロダクトバックログを作るにあたって、まずはプロダクトのユーザーが誰か？どういう属性を持っているか？ということを考えるようにしています。 チームメンバーなのか？経理なのか？エンジニアなのか？世間一般の人なのか？シニア世代なのか？ どういう人に使ってもらうものなのかをなるべく具体的に考えます。
メインターゲットとなるユーザは誰か？
プロダクトの具体的なユーザを考えたあとは、考えたユーザーの候補に優先度をつけていきます。 チームの中で一番重要視するユーザーを決めるのは時間がかかったり、決まらないかもしれません。 そういった場合は、インセプションデッキなんかをチームで作ってから取り組むと良いかもしれません。
ユーザがプロダクトを使って到達したいゴールはなにか？
優先度が決まったら、優先度が高いユーザーから順に、そのユーザーがプロダクトを使って達成したいゴールを考えるようにしています。 たとえば、何か社内での申請を扱うシステムであれば、ユーザが申請の承認をもらって、申請の内容が反映されていることがゴールとみなすことができますし、ECサイトであれば、ユーザーが商品を購入して家に届いて満足感を得る、ところまでをゴールとみなすことができます。 こういったゴールを優先度の高い、いくつかのユーザーに対して設けます。
ユーザがゴールに到達するまでにどんな手順をたどるか？
ゴールを設けることができたら、ユーザーがゴールに達成するまでにどういった手順を辿るかを考えていきます。 ここら辺はユーザストーリーマッピングやカスタマージャーニーマップなどの知識を活かしていくことができると思います。
手順を考えるときは、なるべく大きい粒度を先に出していき、そこから徐々に詳細化していくイメージを持っています。 例えば、「見る」「調べる」「知る」「申請する」といった大きい粒度で考えていき、そこから、「ログインする」「xxxxフォームに入力する」「申請ボタンを押す」「FrontEndからBackEndにリクエストを送る」など細かい粒度に分解していきます。 このとき、あまりHowに注目しすぎないようにするとバックログに積みやすいストーリーを作ることができるかもしれません。 たとえば「FrontEndからBackendにリクエストを送る」というストーリーでは、HTTPリクエストなのかGRPCなのかGraphQLなのか、という実装の詳細にはなるべく踏み込まないようにしています。プロダクトをどういった技術で作るかはスプリントプランニングの中でTeam(スクラムの役割の１つ。一般的な組織としてのチームではない)が考えることです。
こうして手順をあげたあとは、その手順をプロダクト外の手順なのか、プロダクト内部の手順なのかを分けるようにしています。 分けた手順のうちプロダクトに関するものを、さらに必要な機能(機能要件, 非機能要件どちらも)を洗い出すようにします。
手順がある程度固まってきたら、各手順に対して、「ユーザーが~できる」 「システムが〜する」といった形で主語と述語を明確に書いていきます。 主語が抜けていると、そもそもその機能を誰が欲しているのか？誰が関係するのか？という認識が暗黙知になってしまいます。 プロダクトバックログを見てユーザをその都度考えるきっかけになればと思っています。
こうして出来上がったものがプロダクトバックログアイテムの候補になるので、オフラインであれば付箋をはることができる場所を探して、付箋に起こしていきます。オンラインツールであれば、JiraやBackLog, GitHubなどで管理するのがよいかと思います。
プロダクトバックログを運用していくと、気づかぬうちに粒度が大きいバックログアイテムが優先度の高い位置にあったり、FrontEndの実装〜、BackEndの実装〜といったよくにコンポーネント単位でバックログアイテムを切られていたり、〜の調査といっあタスク単位になってしまうことがあるので、バックログリファインメントやレトロスペクティブでそういった問題を解決する取り組みをすることも重要だと思っています。
