Randi W

Can’t steal what’s freely given. 😄 Take the three clocks with my blessing. And we ended up close to your idea: every piece of work carried the quick test steps for sign-off, checked on the way up, so we could hand over a short script instead of “please test.” We even tried screen-share videos. Showing the age in the weekly leadership update is the part I hadn’t done, and it’s a good nudge: a number on the page does the chasing for you.

Named, and set up front. The person who asked for the work owns the next step. I added an “approver” field that takes more than one person, because a change often touched more than one side of the business. For changes that didn’t touch sales, it was often just our product owner testing and signing off. Then I tried to make saying yes as easy as possible: An automatic comment tags the approvers as soon as the work hits our own testing, so they know it’s coming before it lands on them. Every piece of work carries its release steps, including the quick checks needed for sign-off. Those get tested on the way up, so we can hand them straight to the approver instead of a vague “please test.” We even tried short screen-share videos of the change, so people could approve without logging in at all. A name on it means it isn’t a hand-off scramble. Making it easy for that person is what gets it unstuck. The hard part: not everyone lives in our ticketing system. Sales works in their own tools, so reminders moved to Slack, and then the status got split across two places. I’m still working on that one.

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.

“Which failure does it prevent?” is a great test, and I’d add a second: does it still fit? Honestly, no single check from that deploy mattered most. What matters is not treating the process as finished. We watch for friction all the time and talk about it every sprint, not just at the end of a project. What fits a team one year might not fit it the next. Teams grow, shrink and change; systems change under them. A check that prevented a real failure last year can be pure red tape now, and a gap you could live with at five people can sink you at fifteen. That’s what retros are for, and not only the team’s output: the process around the team too. What went well, what could be better, which step is the bottleneck now, what can be automated so nobody has to remember it. Try something for a sprint or two, then keep it, tweak it, or go back. Change is the only constant, so the process has to change with it.

For two people and hourly releases, I’d keep four: The change says how it ships. Steps and a rollback written on the ticket, not in someone’s head. Ours is a sub-task Jira creates from a label. The other person reads it. A real review of the steps and the rollback, not a click. With two people, that’s the whole review board. Tests that check behaviour, written while you’re in the code. Not coverage padding at the end. One check after every release that someone owns. Automated if you can, named if you can’t. Everything else (CABs, multi-level sign-offs, freeze windows) earns its place as the team, the systems and the blast radius grow. And the list isn’t fixed. Watch for friction and talk about it every sprint: if nobody can say which failure a check prevents, it’s red tape, and if something keeps slipping through, you’re missing a check. The right minimum for two people won’t be the right one at ten.