CTOInYourPocket: the alpha case study

Written June 2024 as a case study on KIRA, the alpha product. Reviewed 6 August 2026: KIRA was the MVP that became CTOInYourPocket. The product name has changed, the findings below are the original alpha results and are left as recorded.

How an alpha called KIRA became CTOInYourPocket

I built KIRA to test a narrow idea: that most delivery slippage in small engineering teams starts upstream, in badly written tickets, rather than in the code. The alpha ran with four client teams, all managing their work in Jira. What I learned from those four deployments is what CTOInYourPocket does today.

The problem I was testing

Vague user stories and thin acceptance criteria push clarification work into the sprint, where it is most expensive. A developer picks up a ticket, cannot tell what done looks like, and either guesses or waits. Both outcomes cost the same thing: a slipped date the board hears about late.

What the alpha did

KIRA sat against the team's backlog and did four things. It validated requirements and acceptance criteria for completeness and asked for the missing detail rather than assuming it. It rewrote stories to a consistent structure. It suggested additional acceptance criteria, including technical ones, so the shape of the work was agreed before a developer opened the ticket. And it broke oversized stories into tasks a team could actually estimate.

What the four alpha teams reported

These numbers are first-party measurements taken across those four deployments in 2024, not an industry benchmark. Read them as what that cohort saw, not as a general claim.

Time spent reviewing and rewriting tickets fell by roughly 80%. Story quality improved on every team in the cohort, measured by how often a ticket came back for clarification after being picked up. Across the cohort the productivity gain worked out at 20% to 25%, which for a five-person team is in the order of £60,000 to £112,500 a year in recovered engineering time.

Who it helped, and how

Project managers used it to get stories to a standard before refinement, so refinement became a decision meeting rather than a writing session. Team leads used it as a second pass on requirements and acceptance criteria. Developers used it to check a ticket was implementable before starting, which is where most of the recovered time came from.

What carried forward

The alpha proved the upstream premise, so the product moved on from it. CTOInYourPocket keeps the parts that earned their place, the validation pass, the consistent story structure and the technical acceptance criteria, and drops the parts that only made sense for a four-team alpha. If you are weighing up where your delivery time actually goes, that upstream question is usually the cheapest place to start looking.