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.

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.

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.