アジャイルとリーンソフトウェアに関する独立系プロフェッショナルであるNeil Killick氏が，工数予測に見積を使用しない(NoEstimates)チームのために，実作業に先立って実行可能なスライシング・ヒューリスティック(Slicing Heuristic)を説明する。
氏のスライシング・ヒューリスティックの定義は次のようなものだ。
よりよい作業と予測可能性のための共通語である"一貫性"を創造する上で，作業をジャスト・イン・タイムに"スライス"する方法を説明するための明確な原則。
このスライシング・ヒューリスティックのプロセスについて，氏は自身のブログで次のように書いている。
- プロダクトオーナや顧客の参加の下で，バックログを，１，２日で"Done-Done"になるシンプルなストーリに詳細化し，その価値によって順序付けする。
- ストーリをチームで実行する。
- ストーリ完了に要した時間を測定し，Littleの法則を適用して現在進行中の作業とスループットからサイクルタイムを算出する。
- 振り返り：ストーリを製品に反映させるために，実際に要した時間はどれだけか？それに従って調査と適用を行い，必要ならば次のユーザストーリのサイズ決定にその情報を利用する。
別のブログでは，ヒューリスティックについて，必要とされる予測可能性のレベルへの到達を評価するための成功基準である，という言い方もしている。
スライシング・ヒューリスティックは，ストーリを実践に移すための単なるメカニズム以上のものである，というだけでは留まりません。気まぐれな時間やTシャツのサイズよりも，何を開発するべきかを選択するための"Ready-Ready"のポリシでもあるのです。
氏はスライシングヒューリスティックの目的を，ソフトウェア提供ライフサイクルのさまざまな作業において，実際のサイクルタイムを測定した経験則に基づいて，決定論的予測という儀式を置き換えることにある，と述べている。
#NoEstimatesに手を染めたチームにとって，ユーザストーリのヒューリスティックは，個々のストーリに必要な時間を見積もる必要なく，経験的予測を提供するための，極めて有効な方法です。
さらにプログラムやプロジェクト，フィーチャ，ユーザストーリなどといった，作業タイプの "Definition of Ready" の一部を形成する各作業タイプごとに，それぞれのスライシング・ヒューリスティックを使用するように提案した上で，その概念の説明として，次のような例を挙げる。
"着手可能なフィーチャには，グルーミングされたユーザストーリを４つより多く含んでいてはならない"
作業の粒度は，成功基準を用いて説明されている。
例えば，ユーザストーリには３日，フィーチャには２週を越える期間を費やすべきではない。
スライスヒューリスティックを使用して明示的な作業見積を行ってはいけない，と氏は言う。ヒューリスティックは，実際のサイクルタイムを測定するために使用されるのだ。 よりよいポリシのためであれば，ヒューリスティックの採用を検討してみてはどうだろう。