バックロググルーミング(Backlog Grooming)の目的は，プロダクトバックログを最新かつクリーンに保つことにある。ただしスクラムではその実施方法を規定していないため，プロダクトオーナやチームによってアプローチの方法はまちまちだ。
Jeff Patton 氏は，あるチームでバックロググルーミングを行った時の経験を，ブログ記事 backlog grooming bugs me に書いている。そこでは毎週，チーム全員が顔を合わせてバックログの全ストーリを再確認して，詳細な議論を行っていた。プロダクトオーナは質問に答えて，スクラムマスタがチームメンバの受入基準を記録する，という具合だ。長時間に及ぶミーティングにチームのメンバは不満で，時間の浪費だと感じていたという。結果的にこのミーティングは，氏によれば，バックログをクリーンアップした状態に保つ上で効果的な方法ではなかった。
(...) 私の知っている "バックロググルーミング" というミーティングは，まったくもって意味のないものです。実際のところ，ルーチン的にミーティングに参加しているプロダクトオーナ自身，こんなミーティングではバックログを整理できる訳がないと思っているのです。
では優秀なプロダクトオーナはどうやってこの役目を果たしているのだろうか，氏は彼らにインタビューを始めた。
よい結果を得ているプロダクトオーナたちに，何ができれば次のスプリントの準備が整ったと思えるのか聞いてみました。するとほぼ全員が，チームメンバとの多くの会話とコラボレーションを通じて次のスプリントの作業を確認し終えた時だ，と答えたのです。その理由として彼らの多くは，ストーリをサポートするために必要な情報を自分自身で想定するのは非常に難しいと分かったからだ，と説明しています。チームメンバの作業を詳細に確認し，選択可能なオプションを理解して，彼らの作業進行を支援するためには，チームメンバとの議論が必要なのです。
バックロググルーミングに代わるソリューションとして氏が勧めるのは，プロダクトオーナシップのためにチームを用意する方法だ。氏はそれをディスカバリチーム(discovery ream)と呼んでいる。
バランスを保つため，ディスカバリチームには２種類のメンバが参加します。ソフトウェア開発の動機となるビジネス問題，ユーザとユーザの抱える問題，ユーザがソフトウェアを使用する方法を理解した人と，技術的な障害を理解して，実現可能なものの識別を支援してくれる人です。価値と有用性，実現性のこのようなせめぎ合いからこそ，真に優れたプロダクトが生み出されるのです。プロダクトオーナひとりだけがチームを率いることになるかも知れませんが，チームであることに変わりはありません。
ストーリに関する定期的な議論を，それにふさわしいメンバで運用するにはどうすればよいのだろうか。氏は例を挙げて説明してくれた。
私が関わった優秀なプロダクトのオーナシップグループのひとつでは，ストーリワークショップを少なくとも週１回，時には２回，実施していました。(...) 次のミーティングで議論される予定のストーリには，レストランの "日替わりランチ" に似ている部分があります。チームメンバは "オプト・イン"，つまり参加するかしないかを自分で決めます。(...) 活発で楽しい議論が行われています。チームのメンバも，共同作業の機会として楽しみにしています。
プロダクトのバックログを整理する方法について，氏は次のようにまとめている。
そう，バックログはグルーミングしておきましょう。でもチーム全員で行う必要はありません。自分でやるのはごく一部にしておいてください。あとはあなたのもっとも近い協力者 – バランスの取れたプロダクト・ディスカバリ・チームが行うのです。
Joel Spolsky氏はブログ記事 software inventory の中で，フィーチャバックログをインベントリと比較した上で，よく見られるバックログの用い方についての問題点を指摘している。
フィーチャバックログに関するトラブルの90%は，結局は実装されないという点にあります。機能を定義して，設計して，考えて，議論を重ねた機能が実現されないのですから，ただ時間の無駄でしかありません。”バックロググルーミング" セッションを定期的に行っているプロダクトチームがあると知って，しかもそれがひとつひとつの機能について毎日あるいは毎週検討するという，まったくもって時間と精神的エネルギの浪費を行うためのチームであると分かったときには，本当にびっくりしました。
氏は別のアプローチを取るようにアドバイスする。
フィーチャバックログのリストに入れるのは１ヶ月，あるいは２つの作業までに制限してください。バックログが一杯になったら，ひとつの項目を削除するまで新たな項目を追加しないようにします。バックログ内の項目に関する仕様作業，設計，議論などに時間を割かないでください。実際のところバックログは，議題や作業の対象にしてはならないものをリストアップすることが目的なのですから。
soul-sucking death marches from hell というブログ記事では Dan Mezick 氏が，”バックログ・グルーミングのミーティングをゲームする" 方法を説明している。氏が勧めるのは，"バックログタイムアウト" ミーティングというミーティングを毎日，25分のタイムボックスで実施する方法だ。出席者はプロダクトオーナとスクラムマスタが必須，その他のチームメンバは任意参加とする。バックロググルーミングのアプローチに関しても，氏はいくつかアドバイスをしている。
ミーティングの目標は， "バックログについて，昨日は知らなかったが今日は知っているものは何か" という問いに答えることです。
PO(プロダクトオーナ)は，新たに生まれた「明確な情報」を [プロダクトバックログに] 毎日追加します。そして最新の [プロダクトバックログの] 変更が，以降のミーティングでレビューされるのです。
[バックログ・グルーミングの新手法の] 最後には，約束した内容の正式なレトロスペクティブの実施まで完遂することを忘れないでください。
氏はこのバックログ・タイムアウトミーティングの経験を，次のように書いている。
参加した人たちは，会議の明快さと簡潔さ，オプトアウトが可能なことを高く評価しています。一般的な (徹底されない) アジャイルの実践では，スプリントの終盤はデスマーチになるため，それが終わるまでミーティングの出席者も少なくなるようです。
Anders Abel氏は，スクラムのバックログ・グルーミングにかんばんを利用する 方法について説明している。
項目を最初にバックログに登録するときは，新しい列に置くようにします。プロダクトオーナは，その要求がそもそも調査の労力に値するものかどうかを決定します。値するのであれば，それを調査の列に移動します。この列がプロダクトオーナとビジネスアナリストにとっての "作業中 (work in progress)" 列です。完了したと判断されるものは "要求完了" に移動します。列の項目数が10～20 (物理的な制約は無視します) まで達したら，バックロググルーミングのミーティングを実施して， プロダクトバックログの項目を確認します。バックログの各項目が十分に明確で，実行可能であると判断されれば，最終的にそれを "バックログ" 状態に移動します。開発チームはこの時点で，作業時間の見積も行います (私たちはストーリポイントではなく時間を使用しています)。
氏はプロダクトバックログをクリーンに保つ上で，かんばんアプローチがどのように有効かを説明している。
スクラム実践によって効率の向上した開発チームにとって，開発者が効率的な作業を実施するのに十分な情報を提供するバックログを作り上げることが，これまで以上に重要になっています。(...) 開発プロセスの改善に多くの時間を費やしているのならば，開発フェーズに至るまでのプロセスにも注目するのは，ごく自然なことだと思います。しかしながら，項目をバックログに登録するワークフローが十分に定義されているのは，残念ながら極めて稀なようです。(…) 数ヶ月も過ぎれば，優れたツールサポートを備えた，適切な製品バックログ管理プロセスの恩恵を感じるようになるのは明らかです。
読者の参加するチームでは，プロダクトバックログをどのように手入れ(groom)しているだろう？