I Don’t Want to Build Another Jira

Task management, sprint planning, retrospectives, progress tracking, collaboration channels, agile metrics.

Sound familiar? If you’re thinking of Jira, you’re not alone. But here’s the thing: I don’t want to build a Jira clone. Jira excels at being Jira. Trying to compete with that directly would be missing the point. Instead, I see an opportunity to address an essential gap in how teams use tools like Jira and how they collaborate to build meaningful products.

Let me explain. Here are some of my observations about where Jira, despite all its capabilities, falls short in helping teams build the right thing.

The Trouble with User Stories and Rigid Scrum in Jira

When teams first start using Jira, they often approach it as if they’re required to use Scrum, complete with user stories, task boards, and sprints. But here’s where it goes wrong: teams can end up forcing tasks into “user stories,” even if the context or problem isn’t yet fully understood. This practice leads to a pattern where developers feel they’re doing work “for the sake of project management” instead of contributing directly to meaningful outcomes. Suddenly, team members aren’t just doing Agile—they’re performing Agile.

The result? Frustration with Scrum, Jira, and the work itself. I’ve seen this happen too often, and it raises an important question: what if this forced structure is more of a hindrance than a help?

Knowledge Gaps and the “Done” Column Dilemma

In Jira, user stories get tracked, assigned, and moved across the board until they eventually hit “done.” But what happens to all the knowledge accumulated along the way? Too often, that valuable information is lost when a story is completed, buried under piles of “done” tickets. When new team members join, they’re left with out-of-date Confluence pages (if anything was documented at all) and are forced to rely on “tribal knowledge” from the team—an increasingly scarce resource as team members inevitably come and go.

This workflow turns knowledge into an ephemeral resource, disappearing as soon as the sprint ends. Critical insights and understanding that could help the next team member or the next project vanish, leading to inefficiency, redundancy, and ultimately, frustration.

The Estimation Trap

Then there’s the problem of estimation. Because estimating work in Jira depends on having well-defined user stories, teams often end up rushing to define them even when no one fully understands the purpose. Estimation meetings turn into a numbers game with people throwing out Fibonacci sequence numbers or t-shirt sizes. The real problem—understanding what we’re building and why—takes a back seat to arbitrary estimates.

So what happens when the important problem and design discussions are sidelined? We end up with a process that feels mechanical, where we lose sight of the purpose behind the work. And the result is an environment that, rather than energizing the team, often ends up draining motivation and reducing clarity.

Rethinking What Teams Need

This accumulation of ineffective practices, industry pressure, and reliance on rigid tools has created development environments that too often sap energy from the work itself. Results vary widely, and in many cases, the quality suffers. How this impacts the bottom line of businesses using Jira and Scrum is unclear, but it’s hard to imagine that there isn’t a cost to this lack of clarity and genuine engagement.

My Vision: Long-Lived Stories That Matter

Rather than recreating a tool that manages tasks or tracks progress, I want to build something different. My vision is a tool that helps teams create long-lived, documented stories of the problems they’re solving. Not just user stories, but narratives of the jobs their products are being hired to do—stories that capture the why and how of their work, not just the what.

Think of it as a mechanism for team thought and design. It’s about creating a space where the team can hold onto valuable insights, share their understanding, and build a foundation that doesn’t disappear at the end of a sprint. This tool will be built not for performance metrics, but for fostering real, lasting knowledge and better decision-making.