Honestly, at first we didn’t track the reason, and that was the mistake.

When work got stuck in UAT, we pushed it to the next sprint and carried a point. After a while our sprints were full of 1-pointers that were mostly “waiting in the release window.” Then we moved UAT to done. It helped morale, but it was a story we told ourselves: the tickets closed, the work wasn’t live, and getting it to production took more effort the longer it sat.

I think of it like a bakery. Finished bread sits in the window going stale, and by the time it ships, nobody wants it anymore.

So we built a separate board to see that work again, and I started looking at three clocks: how long work waited to get into a sprint, how long it actually took to build (not what we pointed it), and how long it took to get out. I had hunches about which kinds of work got stuck most, and I wanted data to prove or kill them, so we could fix the bottleneck instead of hiding it.

To answer your question: time in stage was enough to start the conversation. The reason is what lets you fix it.

It also changed the deal with the business. When we take your work into a sprint, we’ll need you to smoke test it when it’s ready. If it was worth fighting for to get in, it’s worth helping get out the door.