sleds and Jira: keep the board, add the part before and after
Most teams keep Jira. What sleds adds around it, how the two stay in step, and what it looks like if you ever want to run on sleds alone.
Nobody has to leave Jira to use sleds. Jira is where a lot of teams already keep their projects, their history and a hundred habits that work, and sleds is built to sit next to it. What it adds is the part a tracker cannot see: what a request was before it became a ticket, and what it cost after it became a PR.
This post covers how the two work together, which is how most teams run, and, for the teams that ask, what it looks like to run on sleds alone. Either is fine. You pick, and you can take as long as you like.
What sleds adds around Jira
- Intake from people who never open Jira. Product and support say what they want to Claude or in Slack. The request arrives with the why, the done line, the worth and the files, and becomes a Jira ticket without anyone typing one.
- A band before the work. Cost and time from your own history, with a confidence, written into a Jira field so the people who live in Jira see it there.
- Seats and routes. The work runs on an engineer's own machine, a coworker's headroom, or a managed agent in the cloud. A request too big for one session becomes a route the engine runs in waves.
- The actual after. Every PR lands with the time and cost it took, against its band. The ticket gets the receipt, and the requester is told where they asked.
How the two stay in step
Connect Jira and pick the projects. sleds imports them, open and closed, with comments and attachments, and keeps them in step both ways. A ticket edited in Jira changes the row; a row sized in sleds writes its band into Jira. Engineers who like their Jira board keep it. Nobody has to change where they look.
| in Jira | in sleds | how they meet |
|---|---|---|
| Project | Workspace | Same shape. A workspace maps to repos and to the people who sled on it. |
| Epic | A request with a route under it | The route's nodes show on the epic as they run. |
| Story, task, bug | A request | One row per ticket, linked both ways, each key beside the other. |
| Story points | A band | Points stay in Jira if you use them. The band sits beside them, measured after. |
| Assignee | Seat | The person stays the assignee. The seat says where the work actually runs. |
| Status workflow | Stage | Running, at PR and landed move the Jira status for you. |
| Priority | Worth | Said by the person who knows, in their words, with a number when there is one. |
| Comments | The thread, decisions | Comments flow both ways. A decision made mid-build lands on the ticket with a name and a time. |
What changes in the first weeks
The fastest change is on the business side. Product and support stop writing tickets and start saying what they want, and the tickets that arrive in Jira have a done line, a worth and a band on them. That is usually the week the grooming meeting gets shorter. The bands calibrate against your closed history in the first few days, so the first new request already has a real one.
If you ever want to run on sleds alone
Some teams find, after a while, that nobody has opened the Jira tab in days. If that happens, switch the mirror to read-only: Jira keeps everything it had, links to old tickets still resolve, and each row keeps its Jira key for the rest of its life. If it does not happen, nothing needs to. Both ways are supported, and you can switch back.
A few things are worth knowing if you do. Custom workflows become six stages, and the states where a person decided something become decisions on the row. Jira dashboards and automation rules do not move across; the board's roll-ups cover the common ones and the webhooks carry every event to wherever you build the rest.