We jokingly do retros every couple weeks to clear everything off the Done column and give each other feedback like "I really like how you insulated those pipes, keep it up!" The retros are completely unnecessary (except for fun), but the kanban board is life-changing: we don't have to nag each other anymore, because you can just look at the board to see what's queued up to get done. It completely eliminated a lot of unnecessary friction between us.
A couple specific tips:
* Use a backlog/ideas/to do eventually column to store tasks whose time has not come. It's a great place to brain dump * Make tasks bite-sized with actionable titles. More tasks completed = more dopamine hits = higher adoption = better tracking * Review open tasks with your direct reports regularly. I do 1x/week
* Proposed * ToDo * In Progress * Done
As a developer we mostly care about all but the first (though we drop random stuff in the first). The ToDo is always ordered with respect to priority but is generally irrelevant while one has work in-flight. That allows us to, without having to really notice, always grab the most important thing when we are free again.
As you can imagine the proposed is the ungroomed/vague/random idea list that is roughly ordered toward whatever the PO (or developers for us since we don’t have product) views as a road map - discussed every week or so.
Everything has labels and generally ties to the concept of an epic or bug.
First rule I try to get everyone in the org to follow: all work done by devs has a card. A dev gets approached by a manager who just needs one quick thing done, shouldn't take more than 5 minutes: "That's great. Can you throw it on the Wish Heap or talk to the scrum master?"
So far it’s been really positive when the rotation is 6+ persons, when I drops below that it gets a bit more wearing with on call being a bit heavy feeling.
For the columns on Jira: we have 4 - 5 columns; Backlog - To Do - In Progress - Blocked - Testing(sometimes) - Done. I do believe this is more than plenty, although in some customers I have consulted to might have ~10 columns which some of them reads like code review, test on staging, test on prod.
Ticket scoping is the most important thing if you want to execute a Kanban/Scrum method. It shouldn't be too broad (i.e. fix all the bugs) or it shouldn't be too focused (i.e. write tests for this function). Each story/ticket must be an independent deployable feature or function written with a business level understanding with clear acceptance criteria. Clear acceptance criteria in bullet point form is very important! (repeated for emphasis)
Backlog is prioritized by business value and urgency, and transferred to the To Do column by a business/product owner or a PM to make sure no one is ticket-starved.
Depending on your work or infrastructure capability, you can release each ticket as a separate deployment or you can create weekly or bi-weekly release packages that are well tested on a staging environment. Any code change that has stayed unreleased more than 2 weeks probably needs a fresh look.
Everyone can move his items to "Done" and I get informed or we use the column "need confirmation" to check if the task is all done. And with the Calendar view, a team calendar isn´t a problem anymore.
More Infos about Zenkit: https://zenkit.com
We use it to work out when inventory needs moving and re-ordering...
I know it means 'coloured badge' so I can see why it could describe post-it notes, but since it is so well understood to mean 'when inventory levels get to the (usually virtual) coloured badge, trigger a re-plenishment,' in the Toyota manufacturing method I still (as a multidisciplinary person) find its use in PM really annoying. Especially as the Toyota method is so ubiquitous in inventory control. Two entirely different uses for the same esoteric word.
I use Trello by the way, but I much prefer the real post-it board if your team is in one place. Todo》Doing》Done for me. For certain workflows a QA stage is helpful
We have a board per platform. All boards have the same 5 columns:
Backlog - not in current sprint but can be added if spent complete Current Sprint - can be picked up by anyone if not assigned In progress - someone working on it Testing - Completed issues / pull requests that get assigned to a coworker to review Done - once reviewed moved here
We use it in very minimalistic way:
3 Lists - To Do, Doing, Done.
I manage projects so I add tickets and tag the person who has to do it.
If needed I add due date.
I put a watch on 'Done' list and once something is there I review it out.
In my opinion, kanban tool should have taken off in popular usage, instead of tools like Slack.
If one is in a big org and using tools like Slack, you're most likely looking at yourself as a gigantic mess.
Kanban methodology in potential gives a better canopy style hierarchy to break out big into small chunks. I say potential because ultimately, none of this matters if there's no proper delegation and care at the top (let too many people create slack or groups or whatever, you're looking at chaos down the road).
* Kanban is for task management.
* Wiki pages are for knowledge storage.
* Mind maps are for topic organization.
You pretty much can use any of these tools to do any of the others' jobs, but each one is best at its own kind.