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

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.