9 ms·
Ask HN: What's your most useful Kanban system for small software teams?
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.
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).
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 "important"?
- What to do with those cards, which never seem to get done?
- How to write a "good" card, easy to scan?
One simple example we are using is:
Backlog -> Collection of features, may or may not do
Buffer -> Planned features, want do
Doing -> Currently implementing features
Test & Review -> Implemented and needs testing
Done -> Implemented and tested
Trash -> Not relevant anymore
Then once a month or so we archive whatever is left in done and trash
another template, which worked for us:
Later -> Planned for some time later
Soon -> Planned soon, when current tasks are finished
Doing Now -> Currently implementing
Done -> Implemented and tested
Inbox (for Review) -> Feature collection
Trash -> not relevant anymore
"Inbox" 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 -> Soon -> Doing Now. And again whatever is in Done and Trash is archived once a week or month.
What systems and workflows work for you?
- loumf 10y agoWe 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. So, left to right on the main board: Inbox, v.nextNext, v.next, In process, Review Requested, In Testing, Done.next, Done.nextNext Done lists get moved to a "Releases" board when the version is released. Inbox is triaged once per week to somewhere on the Backlog board or to a current release only if it's urgent or a regression introduced by those releases (like the bug was found in a beta) 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.
- sova 10y agoYeah a low number of cards <10 is ideal. Single digit if possible.
- EduardMe 10y agoYes, this one is one of the small hacks with high impact!
- EduardMe 10y agoThanks! I can see a bit different approach in your workflow, which I like. In our lists, we don't track specific releases, the cards are just continuously moving up the chain. In your approach you are tracking releases separately from the backlog. I think the last part you mention, to keep a card limit, is what broke our system from time to time. And the reviewing is probably very important, so stale cards are not kept around for no reason. Is there a special way you organize your backlog board? Such as sorting it in themes of your application, urgency, etc? And do you keep track, if it was an external user request (and from how many) vs internal request (your own ideas) or other metrics? Do you find attaching estimates help, such as effort + impact?
- loumf 10y ago> Is there a special way you organize your backlog board? One list for each priority/case-type pair, so High-bug, Medium-bug, ... High-Feature, Medium-Feature, etc' > ... external user request If support made the card, they attach the case. No reporting on this though, it's mostly for followup -- when the card is moved to a Done, we can let the customer know what release it will be in. > estimates We do a very high-level estimate bucket. Mostly to size the release.
- EduardMe 10y agoI like the idea of attaching the case. Not only for following up, but also for reading the whole reason why something should be implemented and it shows the developers that there is a real person with a real pain behind it. Furthermore reading the original case sometimes helps in finding more efficient solutions. > high-level estimate bucket How does this bucket look like? Something like: `within 6 months`, `3 months`, `this month` or kind of effort oriented like `high effort` (takes long), `medium effort`, `low effort` (quickly implemented)?
- olegious 10y agoA few things here: 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. 2. given #1, forget about your "Backlog" column, it shouldn't be in the same daily view that covers the validated features you know you will build or things you're working on now. You may even want to take the radical step of not keeping feature requests at all- you'll find that the important ones come up again and again, and if they don't, then they're not important. 3. I would suggest that your "Buffer" column contain only a prioritized set of features that you know you'll actually build because you've already validated them or are lightweight "this is what we're building to validate hypothesis/idea X" tasks. Once again, don't have too many cards here- having too many cards is difficult to prioritize. Let me know if you want any more help, I love working on process problems.
- EduardMe 10y agoThanks for the tips! A card limit is something I just discovered recently and a great suggestion. I also like the idea of having the feature requests in a different view or even different system. I used to collect all features and bugs inside a note-taking app on my mac. This worked well until I hit 100 or so items. It's true, the important things come up again and again, but sometimes it's a small group of very noisy users, which skew the true numbers. Or it comes from people using your trial, who are not your ideal customers. So I would like to track how many and which users are requesting something. Just to avoid biases and loud users with their edge-cases. What's your experience with this? Regarding the kanban columns. You know other column systems and workflows, which are maybe more suitable? Another point we missed out earlier is to review the cards and throw away stale ones.
- olegious 10y agoI think you have to always be focused on whatever top level goal/metric/OKR you're currently focused on and then define and test hypotheses that you think will get you to there in the fastest way possible. Think of it this way, if your current goal is to improve metric X by Y % then you should only be focused on ideas, hypotheses and feedback that can get you there, ignore everything else. In terms of columns, I like simplicity: Backlog -> Development -> Test -> Done Depending on your workflows, between "Test" and "Done" you can have a "To Be Deployed" column. This assumes that all features in the Backlog have been validated. My process there is: OKR (metric) -> Hypothesis (how will I meet this OKR?) -> Assumptions (what risky assumptions am I making in the hypothesis?) -> Experiment design (how can I prove/disprove the assumption?) -> Experiment -> review outcome and either discard the hypothesis or build it out to production level. In this workflow, items make it into the Backlog at the Experiment and "build out" stages. So you come up with an experiment that may require engineering effort, that's a card in your backlog. Your experiment validates your hypothesis, so you want to put more resources into the hypothesis, so that creates more cards to fully build out the feature. edit: I always liked this post by UserVoice because it shows you how far you can take these things, I wouldn't necessarily use their workflow, but it is interesting: https://community.uservoice.com/blog/trello-google-docs-product-management/ https://community.uservoice.com/blog/trello-google-docs-prod...
- amk_ 10y agoThese 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.
- diegojromero 10y agoBesides what others have commented, I'd like to point some more metrics that help you model your board: - Task classes. - Lead time. - Cycle time. - Number of backward movements for any list. - Cumulative card evolution. There are some good books about this subject: - David J. Anderson's Kanban (https://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402/ref=sr_1_1?s=books&ie=UTF8&qid=1490549174&sr=1-1&keywords=kanban+david+anderson https://www.amazon.com/Kanban-Successful-Evolutionary-Techno...) - Actionable Agile Metrics for Predictability: An Introduction (https://www.amazon.com/Actionable-Agile-Metrics-Predictability-Introduction/dp/098643633X https://www.amazon.com/Actionable-Agile-Metrics-Predictabili...) Shameless plug: checkout my personal project DjangoTrelloStats that measures these metrics for you: https://github.com/diegojromerolopez/django-trello-stats https://github.com/diegojromerolopez/django-trello-stats (include a somewhat Trello synchronization tool).
- EduardMe 10y agoWow, never thought of metrics/stats tracking in Trello! Just had a quick look at the GitHub, does it also work under macOS? I saw Linux `sudo apt-get install` setup commands.
- elsasze 10y agoThis is how we manage workflow in our 5-person team: // Slack // general discussions, brainstorm, clarifying // Agora (agora.co) // capture ideas on slack using a slash command // Gitlab // we export ideas from the Agora web interface, using the Board view (similar to Trello/kanban) We organize our board on Gitlab based on these columns: Backlog > Sprint (for the week) > Development (in progress) > Pull Request > Merged > Test > Prod > Done Hope that's helpful!