Jeff Sutherland氏は最近、チームがプロダクトオーナーに何度も問い合わせすることなく効率よく動けるため、ユーザストーリーは実現可能な仕様（Enabling Specification）であるべきだと述べた。
ユーザストーリーはアジャイルチームが最高のパフォーマンスで動けるよう実現可能な仕様でなくてはなりません。そうでないと、ストーリーが一体何を意味しているか理解するために、スプリント期間中プロダクトオーナーに何度も問い合わせなくてはなりません。これはユーザストーリーというプロセスの効率を落とし、ベロシティを下げてしまいます。
Enabling Specificationはスクラムパターンとして公開されている。Jim Coplien氏はこうした実現可能な仕様を伝える上でのプロダクトオーナーの役割について、次のように説明する。
プロダクトオーナーは要件を精査した証しとして、チームに実現可能な仕様を伝えるべきです。「実現可能な仕様（Enabling specification）」とは、その分野でそれなりにスキルのある人が何度も後から確認することなく、そのソリューションを実現するのに十分な仕様が書かれているということです。
仕様が事前に書き下されていることは、プロダクトオーナーが精査したことに比べれば、そう重要ではありません。
Timothy D Korson氏はさらに、継続的な要件推敲とプロダクトオーナーの関与の重要性について次のように書いている。
私がプロダクトオーナーのときには、スプリントに投入されたプロダクトバックログアイテムすべてに関して、受け入れ基準/テストシナリオ開発タスクをタスクボード上に置いていきます。プロダクトオーナーとして、私はそのタスクをする人とかかわり続け、自ら結果としてのテストシナリオを承認します。そのプロダクトバックログアイテムに取り組んでいる他のチームメンバーも心して私たちとかかわり続けます。最近、テネシー州チャタヌーガにある会社がこの提案を実行しました。彼らは、スクラムプロセスに大きな改善が見られ、開発プロセスの初期段階からプロダクトオーナーがフィードバックするチャンスが得られたと言っています。テストシナリオをできるだけ早期にレビューすることは、互いの理解の相違をすばやく見つけるのに役立ちます。これは結局、やり直しを減らして生産性を改善することにつながります。
Specification by Exampleにおいて、著者のGojko Adzic氏は技術に関係のないステークホルダーにも理解できるよう、仕様を実行可能なテストとして表現することを提案している。
従来のドキュメントはすぐに古くなってしまいます。プログラミング言語で書かれたコードを機能の真実を語る信頼できる唯一の資料にしてしまうと、情報のボトルネックとブラックホールを生みます。これに対し、実際に役立つ実例を使ってうまくまとめられた仕様があると、長期的な効果がもたらされます。仕様の検証は受け入れテストにより自動化され、テストが頻繁に実行されます。これにより、システムはテストに書かれたことができている、あるいは反対に、これらのドキュメントはシステムがやっていることを説明している、と信じられるようになります。実例を使ってうまくまとめられた仕様は読みやすく、アクセスしやすく、理解しやすくなります。したがって、これは情報のボトルネックの解消にも役立ちます。
Siddhartha Govindraj氏はプロダクトゴールに対して定期的に仕事を検証するよう主張している。
したがって、多くのアジャイルチームにスプリントと受け入れ基準、完了の定義があるのに、ゴールに対してアプリケーションを検証し、方向を変えていくテクニックがないのは、かなり驚くべきことです。要するに、彼らは「要件仕様が神様」というゲームを何度もプレイしているのです。
もしあなたがプロダクトオーナーであるなら、あなたがやるべき仕事は単にストーリーを受け入れたり却下したりすることではありません。あなたがやるべきは、ゴールに向かって製品を作っているか検証しつづけ、舵取りをすることなのです。
あなたは実現可能な仕様やユーザシナリオの受け入れ基準といったものを書いているだろうか？ それは開発チームの効率を上げるのに役立っているだろうか？