プロダクトバックログのリファインメントは，プロダクトバックログを分割し，多くの場合は再見積を行うプラクティスである。Scrum Alliance創設者のひとりでMountain Goat SoftwareのオーナであるMike Cohn氏は先日，ユーザストーリの分割と再見積についてブログ記事を書いた。
ストーリを分割する理由のひとつは，より深く理解することだ，と氏は言う。 知識が深まることは見積にも影響を与えるはずだ。分割したストーリの見積合計が最初のストーリと合わなくなっても，それはそれで構わない。
規模の大きなストーリは，複数のチームで対処するため，小さなストーリに分解することがある。TruefitのプロダクトオーナであるJeremy Jarrell氏は，チーム間のストーリ分割についてのブログ記事を書いた。
大きなストーリが最終的にいくつかのチームに分割されても，プロダクトバックログのフェーズでは，ひとつのストーリとして扱われることは少なくありません。こうすることで，個々のストーリの内容に早い段階でとらわれるのを防ぐことができますし，バックログでの位置を上下に移動して，ストーリに新たな優先順位を割り当てることも簡単にできます。
ユーザストーリを分解して個々に再見積を行った結果として，もともとの見積が不正確なものになるかも知れない，と氏は言う。このステージでの見積は信頼性が低く，バックログ上の他のストーリに対して，複雑性を相対的に比較する程度の用途しかない。
しかしスプリント計画では，プロダクトバックログの先頭にあるストーリがそれぞれ，各チーム用のスプリントバックログに移動されます。この時点で，これら同じように大きなストーリは分割されて，各チーム別々のストーリに分割されます。このタイミングで，それぞれの割り当て分に対する再見積が実施されます。これらの見積を加算した合計は，最初の大きなストーリの見積と一致する場合もありますが，そうでなくても驚くには及びません。大きなストーリを小さなストーリに分割する場合，大きなストーリの形だった時は気にならなかったギャップが顕在化することも少なくないからです。結果として，新たなストーリが生まれることもあります。
分割して再見積することによってストーリが大きくなるのを防ぐためにCohn氏は，プランニングポーカをバケツとして使う方法を推奨している。
私は常々，所持している水のバケツとして，プランニングポーカの数字が 最高のアイデアであると書いたり，トレーニングしたりしてきました。8と13は持っているが10はない，といったようにです。もしあなたが10だと思うストーリを持っているのなら，それを13と見積る必要があります。 このちょっとした切り上げ(中程度から大きな数値にのみ起こります)が，ストーリが分割によって大きくなることを緩和してくれるのです。
あるチームにとってのストーリポイントと，別のチームにとってのストーリポイントは大きく違うかも知れない，とJarrell氏は説明している。つまり２つの異なるチームのベロシティは，実施する作業量が同程度であったとしても，さまざまに異なる可能性があるのだ。このために氏は，すべてが単一のベロシティ値に統一されることを期待するため，各チームに異なるベロシティをマップする方法を提案している。その値が，スプリント期間中に完了した作業量を示すことになる。