These are the concepts I associate with Kanban:<p>- <i>Sprints/Cycles</i>:<p>A period of time, usually 2 weeks, where the scope of work is fixed.<p>- <i>In Progress List</i><p>A column of things actively being worked on.<p>- <i>Backlog w/Work-in-Progress Limit</i>:<p>The backlog is a prioritized list of everything you are going to tackle <i>in the current cycle</i>.<p>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.<p>- <i>Icebox</i>:<p>An <i>unprioritized</i> 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.<p>The general idea of Agile is to keep this list short.<p>- <i>Done/Ready</i><p>A place to keep delivered tasks.<p><pre><code> --------
</code></pre>
From personal experience there a few things that help keep a Kanban system under control:<p>- 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.<p>- 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.<p>-- Automated testing, code coverage checkers, and linting speed up review.<p>-- Feature flags make it easy to break up large projects into independently-mergeable chunks, which improves task transparency.<p>- 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.<p>- 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:<p><pre><code> -- Review wanted
-- Accepted/Rejected
-- Blocked (ideally, with a link to the blocker)
-- Needs design
-- Bug vs Feature
-- Story points/weight
-- Priority (for bugs)
</code></pre>
- Prefer tools that let you easily assign tasks right from the board view, especially to <i>yourself</i>. 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.<p>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.