Jira Shows Tickets, Not Truth

Oskar Reyes — Thu, 30 Jul 2026 04:39:05 +0000

Cross-posted from the Kahoona blog.

Ask any engineering lead two questions:

What does your project board say is in progress right now?
What did your team actually merge in the last 48 hours?

If those answers match, your team is the exception. For most, the board is a work of historical fiction — updated in standups, polished before reviews, and quietly diverging from the repo the rest of the time.

Why the drift is structural, not personal

Ticket trackers only know what humans type into them. Engineers, correctly, prioritize shipping over bookkeeping. So the card moves when someone remembers — usually right before the meeting where it'll be discussed. Multiply by every task and every day, and the board becomes a lagging indicator of what people reported, not what shipped.

The failure modes are always the same:

"In review" for nine days — the PR merged a week ago; nobody moved the card.
"Almost done" — the card moved; the code is on a branch that hasn't seen a commit since Tuesday.
Done-but-not — ticket closed, CI red, feature flagged off, customer sees nothing.

What the gap costs

Status meetings exist to reconcile it. Most standups and status calls are just diff-checking the board against reality, verbally.
Leads make decisions on stale data. Hiring, deadlines, scope — all priced off a board that's days behind.
Trust erodes in both directions. Engineers feel surveilled; managers feel lied to. Nobody is lying. The system is lying.

The fix: make the repo the source of truth

Code doesn't forget to update its status. A merged PR is done. A failing CI run is not. A branch with no commits in five days is stalled, whatever the card says.

So the habit is simple to state: stop asking people to report status, and start reading status from the artifacts. Put commits, PRs, and CI next to the tasks they belong to, and the board stays honest with zero bookkeeping.

That's exactly what Kahoona does — whiteboard, project board, and live GitHub activity in one workspace. Point it at your repo and your first project builds itself in ~30 seconds. Free to start.

👉 See what your team is actually shipping

(Full disclosure: I'm building Kahoona. More field notes on the Kahoona blog.)

Go deeper: How to run async standups from your GitHub activity · 9 best Jira alternatives for small dev teams

How to Run Async Standups From Your GitHub Activity

Oskar Reyes — Thu, 30 Jul 2026 04:38:57 +0000

Cross-posted from the Kahoona blog, where I write about how small dev teams stay in sync.

The daily standup has a dirty secret: nobody gets useful information from it. Engineers recite what they did (which is already in GitHub), what they'll do (which is already on the board), and blockers (which should have been raised the moment they happened, not 14 hours later at 9:30 AM). Then everyone loses their flow state and doesn't get it back until lunch.

Async standups fix this by moving the update from a meeting to a written artifact. This guide is the exact system — including the part most guides skip, which is that the best async standup writes itself from your GitHub activity.

Why the standup meeting fails

Three structural problems, none fixable by "making standup more disciplined":

It interrupts maker time. A 15-minute meeting at 9:30 destroys the morning's first deep-work block for every attendee. Research on context switching consistently prices this at far more than the meeting itself.
The information is already stale or already known. "Yesterday I worked on the auth refactor" — yes, we can see the commits. "Today I'll continue" — yes, it's the top card on the board.
Blockers wait for the meeting. The one genuinely useful standup output is also the one that least needs a meeting. A blocker raised in Slack at 2 PM gets solved at 2 PM. A blocker saved for standup gets solved tomorrow.

The async standup format that actually works

The good async standup has four properties:

Written, in a durable place — searchable history beats spoken memory.
On the author's schedule — post when you start work, in your timezone.
Anchored to artifacts, not memory — link the PR, the commit, the ticket. Claims age badly; artifacts don't.
Blockers get their own channel with real urgency — not a line item in a daily template.

A minimal template per person, per day:

Shipped: <links to merged PRs / commits>
In flight: <link to current work item + % done if useful>
Blocked on: <nothing | link + what you need and from whom>

That's it. If someone writes more than five lines, something's wrong.

Step-by-step: switching in one week

Day 1 — Pick the channel and the template. One Slack/Discord channel, one pinned template. Announce that Friday's standup is the last live one.

Day 2 — Run both. People post their async update and attend standup. Feels redundant. That's the point — it demonstrates how little the meeting adds.

Day 3 — Lead by example. Whoever runs standup posts their update first thing and reacts to others' posts. Blockers get handled inline, in public, same day.

Day 4 — First fully async day. No meeting. Post by your local 10 AM. The sky will not fall.

Day 5 — Review honestly. What was missing? Usually the answer is "the social bit" — replace it deliberately (a weekly coffee chat) rather than letting it resurrect the daily meeting.

The upgrade: let GitHub write the update for you

Here's the thing most async-standup guides miss: the template above still asks engineers to remember and type. Two of its three sections are just a summary of what GitHub already knows.

Your repo already records:

Shipped → merged PRs and commits since yesterday
In flight → open PRs, recent branch pushes
Stalled → PRs with no activity in N days, failing CI

So instead of asking people to transcribe their activity, put the activity where the standup is. Two ways to do it:

Option A — the DIY route. A scheduled GitHub Action or Slack workflow that posts each person's merged PRs and open PRs into the standup channel every morning. Humans only add blockers and context. Works, costs you an afternoon of YAML, and breaks quietly when tokens expire.

Option B — the Kahoona route. Kahoona streams commits, PRs, and CI directly into your project board, next to the tasks they belong to. The "async standup" becomes: open the board, read what actually happened since yesterday, spend five minutes on the two things that are genuinely stuck. Setup is pointing it at your repo — about 30 seconds — and the first project builds itself from your history.

👉 Try Kahoona free — your standup already exists in your repo

(Full disclosure: I'm building Kahoona, and I write about this stuff on the Kahoona blog.)

Common failure modes (and fixes)

"Nobody reads the updates." Your updates are too long or too vague. Anchor to artifacts — a link to a merged PR is readable; a paragraph about "progress on the refactor" isn't.
"Updates say 'working on X' three days in a row." That's not an async problem, that's a stuck-work problem the meeting was hiding. Good — now it's visible. Swarm it.
"Management wants the meeting back." Give them a dashboard, not a calendar slot. If the board reflects live repo activity, they'll stop asking.
"We lost the team bonding." Real. Replace it on purpose: one weekly social call, and use the time you saved (each person gets back ~4 hours a month) for something that actually bonds.

The bottom line

Async standups work when they're anchored to artifacts instead of memory. Your GitHub activity is the status update — the only question is whether your team reads it there, or pays a daily meeting to have people recite it from memory.

Start with the template in a Slack channel this week. If you want the updates to write themselves, point Kahoona at your repo and read the board instead — free to start, $5 a seat if it sticks.

Related on the Kahoona blog: Jira shows tickets, not truth · 9 best Jira alternatives for small dev teams

DEV Community: Oskar Reyes