These are the concepts I associate with Kanban:

- Sprints/Cycles:

A period of time, usually 2 weeks, where the scope of work is fixed.

- In Progress List

A column of things actively being worked on.

- Backlog w/Work-in-Progress Limit:

The backlog is a prioritized list of everything you are going to tackle in the current cycle.

Some people would argue that if you don't have a work-in-progress limit, you aren't really doing Kanban (maybe you'd call it a Scrum board or something else instead). Estimate-aware tools like Pivotal Tracker and JIRA enforce this by having you set a "point velocity" for your team and requiring story point estimates for every feature. The cycle backlog automatically overflows into the next cycle when you exceed the velocity.

- Icebox:

An unprioritized list of features from which you draw to create the backlog at the start of a cycle. Pivotal calls it the Icebox; in GitHub/GitLab it's the main issues list; in JIRA it's wherever you set up your board to "pull" issues. In less-structured tools like Trello you have to decide where to keep this list; you might make a separate board to keep track of things needing validation, needing designs, etc. and pull them into the backlog periodically.

The general idea of Agile is to keep this list short.

- Done/Ready

A place to keep delivered tasks.

--------

From personal experience there a few things that help keep a Kanban system under control:

- Specific, deliverable tasks. Tasks should be deliverable as a chunk. Group subtasks into things that are delivered together (reviewed, tested, deployed). A card should never be resurrected from the Done pile once it's there. Use epics, tags, or labels to keep track of related cards if needed.

- Tasks should have clear acceptance criteria so they can be reviewed swiftly and developers can move onto the next item on the backlog. Fuzzy criteria lead to back-and-forth and context-switching which hurt productivity.

-- Automated testing, code coverage checkers, and linting speed up review.

-- Feature flags make it easy to break up large projects into independently-mergeable chunks, which improves task transparency.

- Track bugs in a separate project/column than your Icebox, but make sure they are added to the in-progress column when addressed. Make it easy for non-devs at your company to add bugs to the list and aggressively dedupe.

- Have some way of indicating task state beyond using columns for everything. Every tool provides tags; some have options more tailored at dev teams. Here are some things that you might want to track:

-- Review wanted
-- Accepted/Rejected
-- Blocked (ideally, with a link to the blocker)
-- Needs design
-- Bug vs Feature
-- Story points/weight
-- Priority (for bugs)

- Prefer tools that let you easily assign tasks right from the board view, especially to yourself. GitHub-based tools are really bad at this for some reason and require lots of clicks to assign people. Asana and Pivotal are good at this.

I suggest at least playing around with Pivotal Tracker to get a sense of what a very opinionated Agile/Kanban process looks like. You could keep using it or take some of the lessons back to Trello, Asana, JIRA, etc.