ジャスト・イン・タイム（Just in Time：JIT)のポイントは「必要なものを、必要な時に、必要な量だけ後工程が引き取る」とTPSでは定義されています。
後ろの工程が、その工程に必要モノを必要な量だけ必要な時に取りに行くという意味です。この後ろの工程とは最終的にはモノを必要とするお客様まで対象となります。
お客様が必要な時に、必要なモノを必要な量を提供すると言い直すと分かりやすくなります。
これは、在庫低減から作り過ぎのムダを抑える事ができます。
これを、我々のソフトウェア開発に置き換えてみます。
お客様はユーザー、必要なモノはサービス、サービスは同じものを量としてとらえる概念は無いので単一とします。必要な時は同じでサービスを必要とする時となります。
Agile開発での要求（実現したいサービス）はユーザーストーリーで表現されます。このユーザーストーリーのルールにはIndependent（独立性）、Small（小さい・簡潔）があります。このルールでユーザーストーリーは実現したい単一のサービスを示しています。
一つのプロダクトバックログは一つのユーザーストーリーが当てはまります。
このプロダクトバックを優先順位で並べたリストがプロダクトバック・リストになります。
この優先順位付けはプロダクトオーナーがそのビジネス価値で決めるというのが一般的ですが、ユーザーの要求をベースに開発を進める様なケースではユーザーが必要とする優先順位の方が現実的です。
先のほどのJITの定義に当てはめると、この優先順位のつけ方により、後工程引き取りが実現できることになります。
ここまで説明を続けると、懸命な読者の方はもの作りのJIT思想がプロダクト・バックログ・リストで実現されている事を容易に理解できると思います。
もう一つ、ユーザーストーリーはSmall（小さい・簡潔）であるべきとルールがあります。さらに一つのスプリントに収まるように小さくすべきとも説明されています。
優先順位（ユーザーの必要な度合い）で低いものはユーザーストーリーでは定義せず、エピックで記載して、スプリントに入る直前までにはユーザーストーリーとして記述するというルールがあります。
これもJITの思想に従っていて、必要とされるまではムダになるかもしれない作業（ここではエピックからユーザーストーリーへの組立）を抑止できるのです。
従来手法の開発では使用されないサービスを多く作ってしまうムダを内包していましたが、Agile開発ではこのように、基本的なプラクティスにJITの思想が息づいています。
スプリント毎にサービスを実現し、ユーザーレビューで確認し、ユーザー承認されれば、即サービスをリリースするというScrumの基本的なプロセスもJITの思想が息づいています。