You exported the kanban board to a spreadsheet just to sort it

Someone asks which issues are due before the fifteenth.

You open the board and scroll sideways, because due dates live on cards and cards live in columns. Around the third column you give up, export to CSV and sort by date in a spreadsheet. Forty seconds, and you have it.

Nothing about that is a scandal. Notice what happened, though. You left the tracker to answer a question about the tracker's own data, because you cannot sort and filter a kanban board into a due-date list. And the file you made is a second copy of the truth, wrong the moment anybody moves a card.

Why you cannot sort and filter a kanban board

A kanban board is not a general-purpose way of looking at work. It is one visualisation with one job. The Kanban Guide, May 2025 edition, defines Kanban as "a strategy for optimizing the flow of value through a process" and the board as its picture: "The visualization of a DoW is a Kanban board", a DoW being the team's Definition of Workflow (kanbanguides.org).

Flow. What is in progress, where it is piling up, how much of it there is. On that question a board beats everything else. The other questions a small team asks weekly, it answers badly. What is due this month. Who is carrying eleven things. What has not moved since March. The reason is structural: both axes are spent, horizontal on status and vertical on the order somebody dragged the cards into. Everything else is inside a card: fine for one card, useless for fifty.

Which then gets filed as a process failure

Almost everything written about boards going wrong is about behaviour. Pawel Brodzinski's "When Kanban Fails", from October 2011, runs through boards nobody keeps updated, boards drawn to show an imagined process rather than the real one, boards over-engineered until the important information is buried, and WIP limits nobody treats seriously (brodzinski.com). All four are real. None is about the shape of the board as a reading surface.

The stronger sceptical position says the tool is not the variable at all. A commenter who had used Jira, GitHub Projects, Trello, Linear and Google's internal tracker, on teams of four to thirty, concluded that "the tool doesn't matter. The team does" (news.ycombinator.com). For most of what gets blamed on a tracker, that is correct.

Neither covers the case above. Nobody's process was wrong, the board was current, the team was five. The question was not one a board can be read for.

Four signs it is a presentation problem

• You have scrolled a board sideways looking for a date. Dates want an axis, and kanban has spent both of its own.
• You have counted cards to see who is overloaded. Counting by hand is what a group-by is for.
• You have opened a card to check one field. Ten times for the same field means it wanted to be a column, and you are paginating a table.
• You have exported. The tell is not the export. It is doing the work there.

The export is the expensive part

The forty seconds are free. The fork is not.

A spreadsheet pulled out of a tracker is stale immediately, belongs to nobody, and gets shared. Now two documents describe the same work, and the one with the sort somebody needed wins the meeting. Not the spreadsheet's fault; spreadsheets are good at things trackers are bad at, which is an argument we have made at length. The problem is two records.

Under a 2022 Show HN for a two-way Jira-to-spreadsheet sync, a commenter put it better than any vendor has: spreadsheets give you "the ability to easily access and manipulate data to create new kinds of output without requiring a 6 month dashboard building project", and "if they made the data easier to work with in-product, the export would be unnecessary" (news.ycombinator.com).

The export exists because the tool has one reading surface.

One set of issues, several ways of reading it

Sort, filter and grouping belong to the view, not to the data. Accept that and the board stops being the tracker and becomes one of its readings: the same fifty issues are a board when the question is flow, a table when it is "sort by due date", a list when you want to scan, a calendar when it is dates.

The failure mode is treating the view as a configuration project. In a September 2025 thread about a terminal client for Jira, a commenter wanting one UI across ticketing systems ended with "Just give me a kanban board". The reply: "Get your Jira admin to configure it as Kanban" (news.ycombinator.com). A view you file a request for is not a view, and on a five-person team the person configuring it is working an unpaid second job.

What we built, and what we left out

We make an issue tracker, so read this as the pitch it is.

Every Kevta board carries four views over the same filtered set of issues — board, list, table and calendar — switched with number keys 1 to 4. Grouping, filters and a multi-level sort belong to the view, and a saved view keeps the arrangement as a named tab the whole board can use. See the boards docs.

The absences matter more. No reporting layer, no charts, no burndown, no Gantt, no time tracking. And no export — the import and export screen says on its own face that nothing there moves data yet. Unfinished work rather than a principle.

None of which is a reason to switch tools. But the next time someone exports, ask what question they were answering — often the tracker could have answered it in another shape, and nobody tried.

Kevta is in beta. If this describes your Thursday, join the waitlist — an early invite, a founding-member price at launch, and a direct line to shape what we build next.