TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: What's your most useful Kanban system for small software teams?

5 pointsby EduardMeabout 8 years ago
As a small software team we started using Kanban with Trello a while ago using a relatively simple structure. It seems simple enough in the beginning, but we quickly end up abandoning a chaotic ship and falling back to even more chaotic slack chats to solve multiple projects.<p>But I like the idea of kanban in general, I want to check out what kind of systems work best for you (kanban system and workflow).<p>A few pain points: - Where to collect feature ideas and bug reports, without making too much noise? - Where to put stuff, which is not immediately required? - Where to put the burning stuff, which needs attention without rating everything as &quot;important&quot;? - What to do with those cards, which never seem to get done? - How to write a &quot;good&quot; card, easy to scan?<p>One simple example we are using is:<p>Backlog -&gt; Collection of features, may or may not do Buffer -&gt; Planned features, want do Doing -&gt; Currently implementing features Test &amp; Review -&gt; Implemented and needs testing Done -&gt; Implemented and tested Trash -&gt; Not relevant anymore<p>Then once a month or so we archive whatever is left in done and trash another template, which worked for us:<p>Later -&gt; Planned for some time later Soon -&gt; Planned soon, when current tasks are finished Doing Now -&gt; Currently implementing Done -&gt; Implemented and tested Inbox (for Review) -&gt; Feature collection Trash -&gt; not relevant anymore<p>&quot;Inbox&quot; gets every feature suggestion, internally and externally via feedback from users. We then review it once a week and move it to Later, if we decide to do it. But only, if there is not too much in Later already. Then gradually they move from Later -&gt; Soon -&gt; Doing Now. And again whatever is in Done and Trash is archived once a week or month.<p>What systems and workflows work for you?

5 comments

diegojromeroabout 8 years ago
Besides what others have commented, I&#x27;d like to point some more metrics that help you model your board:<p>- Task classes.<p>- Lead time.<p>- Cycle time.<p>- Number of backward movements for any list.<p>- Cumulative card evolution.<p>There are some good books about this subject:<p>- David J. Anderson&#x27;s Kanban (<a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Kanban-Successful-Evolutionary-Technology-Business&#x2F;dp&#x2F;0984521402&#x2F;ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1490549174&amp;sr=1-1&amp;keywords=kanban+david+anderson" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Kanban-Successful-Evolutionary-Techno...</a>)<p>- Actionable Agile Metrics for Predictability: An Introduction (<a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Actionable-Agile-Metrics-Predictability-Introduction&#x2F;dp&#x2F;098643633X" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Actionable-Agile-Metrics-Predictabili...</a>)<p>Shameless plug: checkout my personal project DjangoTrelloStats that measures these metrics for you: <a href="https:&#x2F;&#x2F;github.com&#x2F;diegojromerolopez&#x2F;django-trello-stats" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;diegojromerolopez&#x2F;django-trello-stats</a> (include a somewhat Trello synchronization tool).
评论 #13969106 未加载
olegiousabout 8 years ago
A few things here:<p>1. in Kanban it is very important to have limits for the number of cards you have in every column. I find that a column becomes useless if there is more than 10-12 cards.<p>2. given #1, forget about your &quot;Backlog&quot; column, it shouldn&#x27;t be in the same daily view that covers the validated features you know you will build or things you&#x27;re working on now. You may even want to take the radical step of not keeping feature requests at all- you&#x27;ll find that the important ones come up again and again, and if they don&#x27;t, then they&#x27;re not important.<p>3. I would suggest that your &quot;Buffer&quot; column contain only a prioritized set of features that you know you&#x27;ll actually build because you&#x27;ve already validated them or are lightweight &quot;this is what we&#x27;re building to validate hypothesis&#x2F;idea X&quot; tasks. Once again, don&#x27;t have too many cards here- having too many cards is difficult to prioritize.<p>Let me know if you want any more help, I love working on process problems.
评论 #13957764 未加载
loumfabout 8 years ago
We do pretty much the same on our team with only items for the current and next release on the board. All other items that might be done are on a backlog board with lists for bugs and features by priority. We build a new release from that board.<p>So, left to right on the main board: Inbox, v.nextNext, v.next, In process, Review Requested, In Testing, Done.next, Done.nextNext<p>Done lists get moved to a &quot;Releases&quot; board when the version is released.<p>Inbox is triaged once per week to somewhere on the Backlog board or to a current release only if it&#x27;s urgent or a regression introduced by those releases (like the bug was found in a beta)<p>The key to using Kanban, IMO, is to keep the number of cards pretty low. Use a pull to bring cards on when lists get empty -- do not just keep adding.
评论 #13957801 未加载
评论 #13956906 未加载
elsaszeabout 8 years ago
This is how we manage workflow in our 5-person team:<p>&#x2F;&#x2F; Slack &#x2F;&#x2F; general discussions, brainstorm, clarifying<p>&#x2F;&#x2F; Agora (agora.co) &#x2F;&#x2F; capture ideas on slack using a slash command<p>&#x2F;&#x2F; Gitlab &#x2F;&#x2F; we export ideas from the Agora web interface, using the Board view (similar to Trello&#x2F;kanban)<p>We organize our board on Gitlab based on these columns: Backlog &gt; Sprint (for the week) &gt; Development (in progress) &gt; Pull Request &gt; Merged &gt; Test &gt; Prod &gt; Done<p>Hope that&#x27;s helpful!
amk_about 8 years ago
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.
评论 #13961322 未加载