という質問を元同僚にされたので、回答をメモ。
課題感としては、Howが定義されていないと開発に入れない、けどHowが定義されていると開発者が実装のアイデアを考える余地がない、というもの。わかるー。
プロダクトバックログアイテムの構成要素
僕の好きなプロダクトバックログアイテムの構成要素は「ユーザーストーリー」と「受入基準」から成るシンプルなものです。元同僚も同じチームのメンバーだったので、話の前提はこちらになります。
ユーザーストーリーは「誰のどんなペインを解消したいか」または「誰にどんなゲインを得てほしいか」を述べたものです。 受入基準はチケットの完了条件であり、機能実装のチケットの場合は簡単なE2Eのテスト項目のイメージのものが記述されています。
今回の質問は主に受入基準を誰がどのレベルで定義するかということでした。
僕の答え
スプリントプランニング終了時の受入基準の詳細度はチームによる
チームで決めましょう。 どのくらい詳細に書かれていれば開発者全員が迷わず開発でき、同じ品質を提供できるのか、です。 僕は簡単なE2Eのテスト項目くらいが好きと言いましたが、それはチームで合意された期待動作の存在が安心や勇気につながると思っているからです。 もちろん縛られている感覚を持つ人もいるでしょうが、チームでプロダクトを作っているなら、「よしなにいい感じで最高にしとくんで」はリスクが高いです。 前もってチームで合意が大事です。 もちろんペアプロやモブプロの中で合意していく手段もあります。 その場合、詳細度は低くても構わないでしょう。 とはいえ、見通しを立てるために詳細はあったほうがいいですよね。
このルールは一度決めたら変えないというわけではありません。チームの成熟度や取り組むプラクティスとの関連によっても徐々に変わるでしょう。詳細でなくても品質にばらつきがなかったりそのための取り組みがあるなら、記述に関して効率化が図れます。
リファインメント前の受入基準の詳細度もチームによる
チームで決めましょう。 リファインメント前のプロダクトバックログアイテムは叩き台です。 叩き台として機能するレベル感はチームによります。 プロダクトやユーザーの理解が未熟な段階では詳細な記述がなければ議論は活性化されないでしょうし、逆に成熟していれば記述が足枷になったり不自由に感じたりするメンバーもいるでしょう。 チームで対話しながら徐々に詳細度を減らしていくのがおすすめです。 詳細度が減ることでプロダクトやユーザーの理解の必要性が見えてきてそちらにも興味範囲が広がることもあります。 ユーザーストーリーだけあればよい、の状態を目指してみたいですね。
Howの捉え方もチームによる
何をHowと捉えるかもまたチームによります。 例えば、コード・設計や利用するマネージドサービスも、画面構成や操作時の挙動や文言も、機能・ソリューション自体のこともHowと捉えることができます。 人によってはWhatと捉えていることもあります。 また例えば、何らかの申請を毎月出さなければならない人がいて、毎月一から申請を作るのは時間がかかるので、申請テンプレートを管理できる機能を作ろうとしたとき、これはWhatでしょうか？ Howでしょうか？ 新規申請ページでテンプレートを選択できる、はWhatでしょうか？ Howでしょうか？ 新規申請のページの右上のテンプレートを適用ボタンからモーダルが開き、リストからテンプレートを選択すると各項目にテンプレートで設定した値がフィルインされる、はWhatでしょうか？ Howでしょうか？
開発者が求めている自由度は、モーダルではなくアコーディオンかもしれないし、ボタンの文言かもしれません。新規申請ページ以外の導線かもしれないし、テンプレートではなく過去申請のコピーかもしれません。
それはチームによって、もっと言えば「今のチーム」によって異なるはずです。それに合わせましょう。そのために話しましょう。
おわりに
という回答でいかがでしょうか😁？ チームのなりたい方向に向かってベイビーステップしていきましょう！ 質問ありがとう！
