Ask HN: What's your most useful Kanban system for small software teams?
These are the concepts I associate with Kanban:<p>- <i>Sprints&#x2F;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&#x2F;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&#x27;t have a work-in-progress limit, you aren&#x27;t really doing Kanban (maybe you&#x27;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 &quot;point velocity&quot; 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&#x2F;GitLab it&#x27;s the main issues list; in JIRA it&#x27;s wherever you set up your board to &quot;pull&quot; 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&#x2F;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&#x27;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&#x2F;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&#x2F;Rejected
  -- Blocked (ideally, with a link to the blocker)
  -- Needs design
  -- Bug vs Feature
  -- Story points&#x2F;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&#x2F;Kanban process looks like. You could keep using it or take some of the lessons back to Trello, Asana, JIRA, etc.