A year later—what’s compounding the velocity
By Troy McAlpin, CEO
A year ago, Mark wrote the post below about how we doubled engineering velocity. The numbers were real. They held. What’s more interesting is what happened next: same team, same tool, and we kept getting faster.
It wasn’t another workflow tweak. It was giving AI our Product Knowledge.
We saw the gap when we evaluated AI-generated stories against our Glossary. 60% needed changes. Not because the AI was broken—because it didn’t know our product. It used “timebox” the way the rest of the world uses “sprint.” It treated “story” like a generic ticket. It was almost right. Almost right ships. Almost right is worse than wrong.
The Glossary closed that gap. It captures how our product works and makes that understanding available to every AI tool via the Glossary export and to the Story Assistant inside Atono. Cursor reads our Glossary as project context. Claude Code does too. The Story Assistant uses it when we draft stories. Specs and stories that match our product, on the first try. Less rework. Faster delivery.
Watch for Lex’s quote in Mark’s piece below—that stories in Atono don’t become fossils. That turned out to be the leading edge of what we now call Living Stories. The story carries the why from spec through production. AI gets the same context the team does.
The cycle-time wins Mark wrote about gave us flow. Product Knowledge layered on top gave us compounding. We see it in our velocity. A year in, the line still goes up.
The 60% Problem: what we found when we ran our own Glossary against AI-generated stories. Get the one pager.
By Mark Henzi, VP Engineering
Back in October, we made a decision to use Atono to build Atono.
We were confident Atono would address the key pain points we'd experienced with other tools, but the results exceeded our expectations.
Six months later, we've nearly doubled our engineering velocity.
It came from bringing clarity to our development process through purpose-built features designed specifically for cross-functional teams like ours.
Here's what surprised us, and the lessons we learned along the way.
Why velocity matters for early-stage teams
Velocity is more than a vanity metric.
For small teams, it's how you stay nimble. Consider Slack's pivot from a failed game to a communication tool in just months, or how Airbnb rapidly iterated after starting with air mattresses. For early-stage teams, velocity isn't just nice-to-have—it's survival.
We track velocity using story points closed each week. Over six months, our average throughput grew from 10.5 to 18.4. At one point, we hit 32.25.
That's an 80% increase.
What's notable is that our velocity didn't come from rushing through massive stories or simply working harder. The data shows we maintained consistently sized, smaller stories—making our work more predictable and manageable while increasing overall output. Our improvements came from both better tooling and strategic team decisions, with Atono providing the visibility to identify where those decisions were needed most.
What wasn't working
Before Atono, we tried a few different platforms one at a time.
ClickUp gave us flexibility but felt like an endless loop of tab-switching with an overwhelming interface. The constant switching created cognitive overhead that slowed us down.
Linear was fast and clean but imposed rigid workflows—great for developers, less so for everyone else. Lumping everything under generic "issues" made it hard to distinguish what we were actually working on.
Jira... well, we'd all used Jira before. Its steep learning curve and sluggish performance were pain points we all knew too well.
Each tool had strengths. But they also had one thing in common: they pulled us out of flow.
Little things added up:
Switching tabs to find a bug report
Slack threads with no connection to the story
Feature flags managed in a separate tool
We intentionally experienced these tools firsthand to understand user pain points, which confirmed our vision for Atono—a tool that would finally get out of the way and let teams focus on building.
How we centered our workflow around stories
When we built Atono, we focused on a simple truth from our own experience: stories are the backbone of effective development.
Unlike other tools that treat everything as generic "issues," we made stories the foundation of our workflow. Each story clearly captures what we're building, why it matters, and how it creates value—bringing focus to our development process.
Here's how this approach changed how we work:
We use timeboxes to organize stories into focused periods, making it easier to prioritize and plan releases.
Our acceptance criteria have persistent URLs that stay valid even when reordered, eliminating the confusion of "AC #3" references that change over time.
We connect feature flags directly to stories, letting us test and control rollout without switching contexts.
Our Chrome extension auto-captures diagnostic info and creates bug reports that link to relevant stories, keeping everything connected.
This story-centric design has practical benefits. Lex, one of our senior engineers, noticed the difference immediately:
"In every other tool I've used, the story body becomes a fossil. In Atono, it stays alive. I actually go back and update stories as we work. That never happened before."
For us, this ongoing evolution of the story object is crucial. Decision context doesn't get buried in comment threads or scattered Slack messages. Important updates live in the story itself, where everyone can find them.
By keeping stories at the center of our workflow, we've created a system where information stays connected, teams stay aligned, and critical context is never lost as features evolve.
The measurable impact on our workflow
We've always tracked story point velocity to keep a pulse on our pace.
Since moving to Atono, the trend has been clear: we're shipping more, with fewer blockers.
We cut the clutter, ditched the distractions, and focused on the features we actually need to build and ship. No noise, no bloat—just the essentials that help us move fast and stay focused.
Atono's cycle time tracking and staleness indicators gave us visibility into our workflow that we'd never had before. These features translated directly to measurable results: shorter cycle times, fewer handoff errors, and more predictable delivery.
When you can stay in flow, you get more done. It really is that simple.
What the data revealed
We suspected our QA process was creating bottlenecks, but Atono gave us the data to confirm it.
Our cycle time tracking showed items were going stale in the test workflow step due to queuing. Stories would sit waiting for QA attention, inflating our overall delivery time and creating unpredictable delays.
This insight was actionable. We scaled up our QA team and the impact was immediate. Not only did our velocity increase, but we could see in real-time how the bottleneck was resolving.
This is a key value of Atono: it doesn't just track what's happening—it reveals why things are happening, giving you the insights needed to make informed decisions about where to focus your efforts.
When you have visibility into your actual workflow constraints, you can address them strategically rather than guessing where problems might be.
Turning friction into features
One of our biggest early pain points was migrating from Linear.
At the time, we didn't have import tooling.
That made it harder to switch. We felt that pain ourselves, and we knew our customers would too.
So we're building building better import tools. Right now. Check out our roadmap here.
But that was just the first example of what has become a key factor in our roadmap prioritization.
Now we’re users of our own product, the real-time feedback loop helps us focus on the features that matter most. We've created a dedicated #champagne channel (we prefer that to "dogfooding"—after all, who wants to eat dog food?) where our team actively shares feedback on Atono.
That's become a pattern. We feel the friction, then we fix it. Because we're not just building for others. We're building for ourselves too.
If this sounds familiar
We didn't set out to double our velocity. We just wanted our tools to get out of the way.
But in doing that, we unlocked something powerful: a way of working that actually helps us move faster, with less noise and more clarity.
If you've ever felt like your current tools are slowing you down, maybe it's time to try something new.
We'd love to hear what you think of Atono.