Show HN: Two-way Jira sync in a collaborative spreadsheet and Gantt | Hacker News Reader

Show HN: Two-way Jira sync in a collaborative spreadsheet and Gantt

visor.us

116 pointselectric_muse53 comments

Hello HN,

Our startup nearly died 2 years ago. We kept losing customers to spreadsheets. And it made us see a problem right under our nose: everyone just wanted flexibility & speed from a spreadsheet. But they have to stay in sync with {Jira / Salesforce / insert SaaS app}.

When we followed this thread, we discovered how broken the integration experience was for flexible products like Airtable, Smartsheet, Monday, and Google Sheets. Their big problem is that they transform external data into their own format. This makes setup harder, since you have to get the mapping just right. And often you can’t sync back.

We took a different path when building Visor. We essentially made a data lake & ETL tool with a front-end. Visor integrates with your Jira instance, reads its schema, helps you import the right data, and lets you work in a flexible spreadsheet* that syncs both ways. There’s also an interactive Gantt & Timeline view.

*Spreadsheet is a generous term for now. Formulas are still on the roadmap. As are many true “spreadsheet” features. But we’re working towards it.

Our roadmap is public, here: https://support.visor.us/visor-roadmap

And for VueJS devs, we eked out more performance from Vue 2 by modifying the core, documented here: https://www.reddit.com/r/vuejs/comments/u6tzv8/how_we_resolv...

For database geeks, you might enjoy learning about the realtime graph DB we built to power the product: https://blog.visor.us/cloudstore-part-1/

I’ve seen so many great companies start out by launching on HN. It’s quite a special personal moment finally to be sharing with you all.

I’m happy to answer questions, take criticism, and generally hear what you think.

Open articleView on HN

Thanks for making this. Maintaining parity between Google Sheets Gantt charts and JIRA tickets is a real problem I have and one that is underserved by existing tools.

On the other hand this is a cursed development methodology. There's an infinite mine of No True Scotsmans about Agile, but really, when you find yourself putting your Agile stories in a Gantt chart and projecting sprints several months out, you are unambiguously rejecting substantive principle and content of Agile as a methodology. At this point it would be much more productive to admit that you're doing waterfall and put some effort into doing it well, instead of farting around with backlog grooming, sprint planning, etc. where the outcomes are all committed before the meeting in a master schedule.

This is the reality of most mid and large sized organisations, fake Agile with Scrum, which is really better for waterfall anyway

Hey, that means a lot. Thanks.

It does seem there are a lot of methodologies being used with the product. And agilefall does seem to be making a comeback. But a fair number just use it as a faster way to plan the sprints and run standup. (Vs in Jira)

The thing about “spreadsheets” is that they seem to be flexible enough to fit all the idiosyncrasies of how different teams work, regardless of methodology. I hope the product can save you time, frustration, and copy/paste drama.

Very cool but also slightly ironic since Jira set out to replace excel sheets and Gantt charts in the first place :)

Yeah, huh? It's funny how everything in software comes eventually full circle. I heard monorepos and megaliths are making a comeback, too.

I’m patiently waiting for us, the programmers, to discover again server rendered HTML and native desktop GUIs.

The original reasons people used spreadsheets still exist.

The original reasons people needed to move those spreadsheets into tools like Jira still exist.

I'm glad to see a product like this acknowledge that people want both:

a) The flexibility/speed of navigating spreadsheets

b) Centralizing that data for consumption by other people participating in the overall process

Jira and similar products seem to assume people moved away from spreadsheet because spreadsheets suck. This is not the whole story.

It’s not about spreadsheets per se. It’s more how the advent of agile and scrum forced a negative sentiment towards waterfall thinking and large steering committee meetings with lots of Gantts, budgets, and multi year roadmaps. So people turned to Jira to be agile. And here we are, producing good-looking diagrams for executives because Jira is too messy and hard to roll up to something executives can grasp.

I'm one of the Visor engineers, and you've stated perfectly what many of our users are running into. In addition to creating these "good-lucking diagrams for executives" (which is time consuming in itself), people need to keep them up to date. So they waste so much time updating the raw Jira data that feeds their charts. If we could get all of that data, make it "live", and put it in a spreadsheet so you could roll it up in whatever way you want, making those diagrams becomes trivial!

They do it in PowerPoint with Jira screenshots.

Oh I agree with you. I don’t think I articulated this as well as I could, but it’s about what spreadsheets enable that tools like Jira don’t: the ability to easily access and manipulate data to create new kinds of output without requiring a 6 month dashboard building project.

I think this also highlights the major gap in good reporting functionality in these tools. If they made the data easier to work with in-product, the export would be unnecessary. But such a reporting tool would need to be as flexible as Excel.

A very high percentage of Visor users add custom columns to add context. This is data they create in the product that doesn't sync to Jira. So the workflow seems to go beyond unidirectional reporting.

It seems that no reporting tool is ever flexible enough to do that -- add custom columns to annotate, filter, and contextualize the report. Raw data is rarely "clean" enough and explanatory enough to just be exported into something for external consumption -- either via an exec or even externally to a different company (partner, client, etc.)

> So the workflow seems to go beyond unidirectional reporting.

Oh absolutely! That ability to “extend” Jira without the overhead usually associated with doing so is definitely the part that caught my eye.

You both make good points. The issue is that the fitness of your source of truth often depends on the direction of your perspective. If its from top of the organization down then the messy granularity of a single QA testers workflow status snapshot is too much detail. But on the ground where the rubber meets the road it is noisier and team communication requires that flexible approach to detail.

These guys solve the problem where Jira is either positioned facing up (clean) or facing down (messy details) and doing your own translation is usually a complex time consuming and error prone API effort in comparison to live spreadsheet data you can produce (down) or consume (up) any way you like. Similar workflows on Make/Integromat or Zapier also help re-orienting the use case direction if you are allowed to connect them.

This is right on the money.

One emergent use case is that teams who can’t get all the fields they need added to Jira end up going around it to do their work. (The qa team, for example, may not have leverage to get a whole bunch of checkboxes added that reflect their process). Spreadsheets then become a place where their work happens, and Jira becomes the place they keep up to date to “communicate” with others.

This seems like a roundabout way to get more locked into Jira. Switch to Linear, or Height, or Shortcut, or Taiga or anything other than continue your abusive relationship with Atlassian

I've heard great things about some of those tools!

The challenge is that many people working as part of bigger teams can't pick their own tools or really make a change unilaterally. So they need a way to make things work for them as part of a bigger structure.

You’re totally right of course. You’re doing God’s work by making Jira more usable. It’s just an unfortunate state of affairs that this is needed. Bless.

Or, Restya Core as it has Excel-like UI/view. Disclosure: Using it since its private beta

Are there any suitable open source or on premises competitors to Jira that also support service desk functionality?

GitLab has this functionality https://docs.gitlab.com/ee/user/project/service_desk.html

It might be just me - but I don't understand why any company would want to make their roadmap public. I feel like only the company's competitors ever look at it

Well, investors may find it more convincing if you committed publicly to reach some results.

I'd say if your competitors are relying on looking at your roadmap to compete with you, then they're in trouble. Single features are often easy to copy but it's a losing battle if your competitor is way out in front of you and you're trying to copy them feature-by-feature.

Similar argument with open sourcing your product. Couldn't your competitors look at your code? Sure they could, but if that's how they're trying to compete, they're going to lose. Plus, their engineers will probably look at your code and think they can do better anyway ;-)

Why not? If i'm a potential customer and i see some features are missing, having the roadmap to visualise how they plan to evolve is great. Without that, why would i waste time contacting them, bothering with an NDA and what not just to know if they plan on adding X or Y?

Hey, thanks for the (implied?) question.

We are a lot more concerned with making customers feel like part of the company’s growth than worrying about competitors.

Our customers love seeing the roadmap. And we are lucky to have an engineering team that really does deliver what’s promised. So we like to show that (hence the public release notes that connect to items on the roadmap).

This gives customers confidence that we really will deliver what we say we will, and they can plan their adoption of the product around it.

The community also really loves seeing their own suggestions make it into the roadmap. The way I see it, we’re all building this together.

At the end of the day, it’s not the best product that will always win. It comes down to community.

I solve this with ImportJSON.gs and/or Atlassian’s native integration for sheets.

I wouldn’t encourage anyone to buy a tool just to make a single type of chart, even less if it is a for-pay SaaS wedge.

Spreadsheets are over-used and I’m not sure meeting users where they are works in this case. Hasn’t paid off (in my experience) with anything more than additional layers.

How does this play with issue type hierarchies used in advanced roadmaps —- goals / initiatives

The import should respect hierarchies from advanced roadmaps (e.g. initiatives). That was a whole project. It was launched in this release: https://support.visor.us/release-notes/11822-release

Has anyone ever done something similar, but with spreadsheets in Org-mode?

I assume you've taken a look at org-jira?

If you need to use a product like this with JIRA, JIRA isn’t for you.

From what we've seen, it's a control thing. IT or execs want control & reporting. So they force everyone on Jira.

But then the people actually working day-to-day need flexibility. So they end up creating extra spreadsheets off on the side where they work, but those get out-of-date.

During broad pre-build research (even beyond Jira), we found that spreadsheets consistently shadowed the real data in SaaS apps -- ranging from Jira to HR software and everything in between.

It can be the other way round. Our team wanted to use Jira (although it got used mostly like Trello) but the boss wouldn't read it and forced an engineer to manually update a spreadsheet at the same time while running a QA team. This product might have been a godsend during that scenario.

Ugh. Yeah, this is more common than one would hope. I met someone with a Masters in CS who worked at a public database company whose primary role was to keep the spreadsheet up-to-date with Jira data. What a waste of talent!

They would have automated their job and probably working on something else. I've used JIRA's API to spit out reports when people have demanded they fit in their "Agile enterprise project management" Excel templates.

It was a two-directional affair for them. Not just about reporting to a spreadsheet, but also about be able to shift things around during a meeting and then "sync" back at the end of the meeting. So a lot of stuff that's hard to automate, sadly.

This is literally the worst. I came from a background where we used google slides to present roadmaps and they'd get stale within hours. Live data visualization is supremely more efficient; no one wants to build those reports on a daily basis.

Damn. Talk about hitting the nail on the head. This describes so much of life.

It's like taking the concept of materialized views in databases and applying it to all of life's little data pools. The data is what matters, and Jira is a tool for materializing in a certain way. But often, it's just as important to allow to be materialized and managed in a completely different way (spreadsheet views).

I love this and am going to pitch it hard to our product team. Thank you!

Really glad to hear it resonates. I hope it saves your team some time and makes things run smoother. Feedback is very welcome! There's an in-product Feedback button that submits right to our CRM / slack channel.

Jira lacks all sorts of table stakes features, like the ability to view your backlog grouped by epics.

So anything that lets me use the Jira data that I'm forced to create, but in effective ways outside of Jira, is a win.

I appreciate the in-depth look into your architecture in the linked posts. Have you considered open sourcing / selling that database solution by itself?

I can see how it'd speed up dev time for my team, I'd be curious to hear how something like that (reactive no-sql frontend for a SQL DB) would work for others outside of Vue.

That's a great question. We've thought about making CloudStore available sort of like a Supabase. We've been following their progress, and it's inspiring!

We haven't really tried CloudStore + other frameworks. That would be a fun experiment to try next. :)

Definitely something on our radar! We always imagined CloudStore as it's own product, and much of it's infrastructure and code are written with that mindset. Can't wait until we are at a point where we can easily ship that!

Just checked out the site - this is going to bring grooming and planning sessions down from 3-4 hours a week to under an hour

Awesome! Let me know what you think.

We use Visor internally, and it definitely has for us! Prioritizing user stories with other engineering tasks has never been simpler for us -- easily saves our team at least an hour a day.

Following the Visor journey for the past few years has been inspiring to say the least. Excited to see what the future holds!

Thank you! We're very excited to be at this point.

This is great and solves a real problem!

Thanks! Hope it saves your team some headaches and time.

pumped for this, great stuff

Thank you! Hope it helps you and your team.

Reply on news.ycombinator.com