Kanban teams aren’t “chaotic” by nature. But without a good intake process, they can feel like a support line with no hold music—just a bunch of interruptions and mystery tickets.
Here’s how we handle it in real life.
Designate a Gatekeeper—We Use Our On-Call Person
On our team, the designated intake person is whoever’s on call that week. They monitor our shared Slack channels, look for questions or requests, and follow a lightweight mental checklist to figure out if there’s actual work involved.
If there is? They just ask the person to create a JIRA ticket. Simple. No form yet (though I’ve thought about it), but we’ve done this enough that people know what to include.
Fast Triage, Smart Escalation (And Smart Knockouts)
If the request looks like it’ll take less than 2 hours, the on-call person takes a moment to make sure all the most important info is in the JIRA ticket—what’s needed, why, any context or links—and then drops it into our Ready for Work column.
Depending on urgency, it might get done next, by the end of the day, or sometime later in the week.
I’ve found it’s critical to get small requests from other teams in quickly. Why?
Because most of the time it’s “oh no rush, you can do it tomorrow”… right up until the moment their team hits a blocker mid-sprint and suddenly now it’s urgent. Getting ahead of that builds trust.
And honestly, there’s huge value in just knocking out the easy stuff fast. It shows that your team is reliable, responsive, and a good partner to work with. That goodwill stacks up.
Now—if the work looks like it’ll take more than 2 hours, the on-call immediately escalates to me or our director. That’s when we kick off a real intake conversation. No “medium priority” black holes.
We pull the requester into a 15-minute meeting and ask the real questions:
- What does success look like?
- What exactly do you need from our team?
- What’s blocking you?
- Who owns the outcome?
- What’s the timeline?
If the request looks like it’ll take more than 2 hours, the on-call person immediately escalates to me or our director. That’s the cue for a real conversation. No hand-wavy “medium” priority labels. We get someone in a room for 15 minutes and ask the real questions:
- What exactly do you need from our team?
- What’s blocking you?
- Who will own the outcome?
- What’s the timeline?
- How does success look?
We have a doc in Confluence that we’ve been iterating on to improve the intake questions. The goal is simple: every time we go through this process, we make it a little better and more repeatable.
We’ve tried winging it before—and while it kinda works, the results are inconsistent. The structured approach just wins. It gets us clarity faster, reduces misfires, and builds a process we can trust.
That 15-Minute Meeting? Game-Changer.
It sounds small, but asking someone to explain the work out loud makes all the difference.
Suddenly, the vague Jira comment becomes a real conversation. They have to think through what they’re asking. You get to ask clarifying questions. Priorities come into focus. Ownership becomes clear. And you avoid the classic “IT team can just handle it” mindset, where every ask is casually tossed over the fence with no follow-up.
Part of the goal of this meeting is to make it clear: we will 100% do the work for you. Our job is to support internal teams. But if you need a larger bit of work from us, then we need you to put in some effort and tell us exactly what you need. It’s shocking how often a vague, messy ticket that looks like it might take days ends up boiling down to something simple—“we need a new VM” or “can your team get access to X in dev?”—once we actually talk through it.
We’ve tested a dozen different ways to handle intake—Google Forms, Jira templates, async Slack threads, even automated bots. Some of those tools help. But none of them replace what happens when two humans sit down and talk about the work.
You don’t need an hour. You don’t need a full project kickoff. You just need 15 focused minutes where someone walks you through what they need, and you walk them through how your team works. That small touchpoint saves hours of follow-up questions, task rewrites, scope misfires, and mismatched expectations.
It also sets the tone: we’re not just blindly taking orders—we’re partners. We care about doing the work well, and that means we care about doing the right work in the first place.
You can still be kind. You can still move fast. But you need that moment where expectations are made explicit. It’s the difference between being a task factory and being a high-trust engineering team.
Even Kanban Still Needs Some Sort of Organization
Even without sprints, you still need structure. Once a week, we do a simple intake and prioritization review:
- Close out stale tickets
- Rerank and clarify in-progress work
- Revisit anything blocked or missing info
- Confirm: “Are we actually the right team for this?”
You don’t need sprint rituals, but you do need hygiene. Without it, Kanban turns into a graveyard of half-baked ideas, miscategorized work, and forgotten requests.
For my team, I keep a “Next Up” column at the bottom of our Jira board—unassigned, but ranked. It’s our running queue of upcoming tasks, ordered by importance, with the most urgent or impactful items at the top.
I try to check and update it daily, but realistically I touch it Monday, Wednesday, and Friday—our team sync days. That’s when I clean up the board, assign out work, and make sure everyone has clarity heading into their next task.
The goal is simple: everyone who’s not on-call should be able to work heads-down, uninterrupted. The on-call person handles triage, I manage prioritization, and the rest of the team gets to focus. That split of responsibility has made a huge difference in our flow.
Kanban doesn’t mean chaos. With the right cadence and roles, it can be calm, focused, and effective.
💡Liked this post?
Get real-world solutions like this in your inbox—join the newsletter.