DEV Community: Luke Jones

Your backlog is a photograph. Time-lapse is the film.

Luke Jones — Mon, 05 Oct 2026 13:20:34 +0000

A Jira backlog shows you one thing: where everything stands right now. What it can't show you is how it got there — which areas caught fire this quarter, where work piled up and sat, which corner quietly went green while you weren't looking.

Teppe already turns a sprawling backlog into a single picture you can take in at a glance. Time-lapse adds the missing dimension: time. Press play, and that picture comes to life — every issue moving through To Do → In Progress → Done, exactly as it really happened.

Watch a year of work in a few seconds

Here's the full Apache Spark project — roughly 5,000 issues — replayed across a year of real history:

The whole project, one year, played back from Jira's own status history.

Each tile is a piece of work; each block of tiles is an area. The colour is the issue's status category, so the whole carpet breathes as the project moves: grey work turns blue as it's picked up, blue turns green as it ships. Watch it once and you can see the rhythm of the project — the steady areas, the late-quarter surges, the parts that stalled.

Nothing here is simulated. Time-lapse is reconstructed from the real status-change history already recorded against your issues — the same timeline you'd piece together by hand from each issue's activity log, except across the entire backlog at once.

Drill into a single area of work

The whole project is the headline, but the story usually lives in one corner of it. Time-lapse is scoped to whatever node you're looking at — so you can drill into one area and replay just that.

Here's the Connect area of Spark on its own:

One area of work, same window — the detail you'd lose in the project-wide view.

This is the view for a retro or a team update: "here's how Connect actually went this quarter," shown rather than asserted.

Pick the window that tells your story

When you open Time-lapse, you choose the window first — before anything is built — so you never have to guess and re-run:

By sprint — pick one sprint or a run of them, and the playback spans exactly that work.
By date — any start and end date, for teams that don't run sprints or want a custom range.

Then it's a simple transport: play / pause, a scrubber to jump to any moment, and a speed control to slow down a busy stretch or skim a quiet one.

Share it, don't describe it

A time-lapse is worth more in a standup than in your own head. Every playback can be exported — as an animated SVG that stays crisp at any size and drops straight into a doc or a stakeholder update, or as a GIF to paste into Slack or a retro board. The colours are baked in at export, so it looks right in light or dark, wherever it lands.

Honest by design

Time-lapse keeps the same promises the rest of Teppe makes:

It never touches Jira. Teppe reads your project; it never creates, edits, or moves a single issue. Time-lapse is a replay of history, not a change to it.
Your data never leaves Atlassian. Teppe runs entirely on the Atlassian platform — no external services, no data egress. The history is read, rendered, and animated in place.
It respects reduced motion. If your system asks for reduced motion, playback starts paused and every frame is legible on its own, so you're never forced into animation you didn't ask for.

Try it

Open any project in Teppe for Jira, click Time-lapse, pick a sprint or a date range, and press play. Start with the whole project, then drill into the one area you actually want to talk about — and export the clip that makes the point for you.

How Teppe for Jira works under the hood

Luke Jones — Wed, 23 Sep 2026 15:16:56 +0000

A few weeks ago I promised a technical write-up. Here it is.

The two questions I get most are: how do you render tens of thousands of Jira issues in under 10ms? And how does the AI figure out how to group things? They're related, and the answer to both starts with the same principle — do less.

The rendering problem

Jira backlogs are large. A mature project might have 50,000 issues. Naively rendering 50,000 nodes in a browser canvas is slow, and no amount of JavaScript optimisation is going to change that.

The insight is that you never need to render all of them.

The Sierpiński carpet is a fractal — it's recursive by definition. At any given moment you're looking at one level of the hierarchy, with the levels above and below rendered at progressively lower fidelity. We cap this at MAX_DEPTH + 2 levels visible at once. The result: no matter how large your backlog, a single view renders at most 584 cells. We measured layout time at ~1.4ms for a 1,000-issue project and ~1.8ms for a 10,000-issue one. It's essentially flat.

Why Rust and WASM

The geometry work — computing where every node goes, what size it should be, what fidelity level it gets — is pure arithmetic with tight loops. It's exactly the kind of work JavaScript is not well suited to, and exactly what Rust is.

We compile the layout core to WebAssembly. It runs in the browser, but it runs at near-native speed. The Rust core produces a flat buffer of RenderedNode structs — position, size, depth, status, fidelity — and the JavaScript layer is a dumb consumer of that buffer. It reads the numbers and draws rectangles. No logic lives in the rendering layer.

The canvas itself is four stacked layers: geometry, state (colours and fill), focus (the working level highlight), and presence (collaborator indicators). Only the layers that need to change repaint. A status update on one issue repaints the state layer. Navigation repaints the focus layer. The geometry layer repaints only on resize.

This separation is what keeps navigation instant. Drilling into a node is a WASM call and a canvas repaint, not a re-fetch or a DOM reconciliation.

How the AI groups your backlog

The AI grouping was the part I was most nervous about — not technically, but economically. LLM calls cost money, and a Jira backlog with 5,000 issues could get expensive fast if you sent every issue to a model.

The answer was deterministic first.

Before we touch an LLM we build as much structure as we can from what Jira already knows: existing parent/child links, epics, components, fix versions, labels, issue type. For most backlogs this resolves the majority of issues at zero inference cost.

Only then do we look at what's left — the overflow buckets where a parent has more than 8 children, and the Unsorted pile of issues that don't fit anywhere. Those go to the model, batched per bucket, not per issue. One call covers an entire overflow group. The model receives the issue keys and summaries, and returns a named partition — at most 8 thematic groups with a one-line rationale for each.

If a returned group still has more than 8 members, we recurse. The constraint is enforced all the way down.

We measured this at around $0.24 per 1,000 LLM-resolved issues, which sounds small and is small — the cost is dominated by the fixed overhead of the prompt and tool schema per call, not by the number of issues. It scales with the number of overflow buckets, not the size of the backlog, which rewards the deterministic-first approach.

One more thing worth knowing: any group you rename, move or adjust is marked as yours. A rebuild will work around your edits, never overwrite them.

The combination — a WASM geometry core that never renders more than it needs to, and an AI layer that only runs where deterministic logic falls short — is what makes Teppe feel fast and cheap to operate at the same time.

If any of this is interesting and you want to go deeper, feel free to reach out.

Email: info@teppe.io

Luke

Jira backlog hierarchy

Luke Jones — Wed, 02 Sep 2026 05:53:21 +0000

The List is dead. Long live the Fractal.

Small lists are great, large lists are not. Why? Because you - the reader - give a small list context and we simply cannot do the same for a 1500 item long list.

Miller's Law tells us humans hold around 7±2 items in working memory at once.

With this in mind I took a snapshot of Apache Spark's public Jira backlog and produced a fractal view of the latest 5000 issues with their statuses mapped to the defaults.

Diving into one section of the fractal view we can see at a glance the great progress the Spark team continues to make - good job Apache!

The beauty of this view is you could be looking at 500 issues or 5 billion - all contained in a simple 3x3 square. Conceptually there is no limit.

Finally, infinity with context.

We can create a Sierpiński carpet we call Teppe (/TEP-uh/), where you can see and navigate through your entire backlog and intuitively see what’s related to what and whether it's been done.

This is all available free on the Atlassian Marketplace. No data leaves Atlassian.

If you would like to see how Teppe for Jira can visualise your backlog please give it a try - it only takes a couple of minutes.

We would really appreciate any feedback to help us improve and inform what direction we take the tool next.

Please do not hesitate to ask any questions.

I will shortly be doing a technical write up of how it's made and how we're able to render and navigate around tens of thousands issues in <10ms.

Thanks for reading.

Email: info@teppe.io

Luke