How do you use Kanban? How do you prioritise items on a Kanban board? What is the criteria for items to make it to the board? How do you release finished tickets? How does your Kanban process fit with the team's calendar in terms of frequency of releases, standups, meetings ... etc?
I know this isn't what you're asking, but I want to give a shout-out to personal kanban. My husband and I use a post-it+whiteboard Kanban board at home for household/personal tasks, and it revolutionized our life. We have five categories: Backlog, To do, In progress, Blocked, and Done.
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.
Me and my wife are trying for something like this, but we're using Notion.so instead of post-its since we already use it for a bunch of other stuff. It's lightweight and the Android client is pretty good.
If you use Asana, or are thinking of using it, the Board view allows you to implement Kanban. Asana use was pretty low before I started at my job, but once I introduced Board view + Kanban, adoption increased significantly.
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
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.
We organize our columns in Trello around our scrum process. Our Proposed column is called the Wish Heap. It's where stories go before they're groomed (titled as user story, acceptance criteria defined, sized) and added to the Backlog column (or To Do) ready for work.
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?"
Whilst I agree in general, but depending on your internal clientele, I think it can be useful having someone dealing with those 5 minute jobs - if you can save someone a couple of hours work by writing an SQL query for them, you should. It'll improve your relationship with other teams.
I’ve gone back and forth mentally on the “every bit of work needs a card” concept. Recently we’ve been trialing the on-call person taking those issues if they’re under a time-estimate threshold (30min) and budgeting the time for that person accordingly. Other issues go up the chain, to avoid the issue of the on-call person getting overwhelmed with unrelated feature requests and such (especially by those they relate to better than others).
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.
It totally depends on the team and work. We apply Scrum or Kanban separately. For example Ops team almost exclusively executes Kanban method, yet Dev teams probably use Scrum.
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.
We use Kanban for several departments because our Tool Zenkit is not only a Kanban Board. You can work with multiple data views, for example, a Calendar.
In Marketing, we use it for task management. Prioritization can be used via due dates, the order of the items or by setting labels with "high", "medium" or "low". We add almost everything to the board to have a good overview of the workload or we add checklists to an item where we can see what to do within this task.
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.
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 use Github’s projects AKA kanban. It’s nice to tie in directly to the repository features sure as milestones, labels, pull requests, issues, etc.
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
Our team uses Kanban just as a way to keep track of all the tasks we have and see what anyone of us is working at a given time. It's then up to the project manager to distill that info and distribute it to whoever needs to know. As a developer, I don't do anything but switch what I'm working on
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).
Yes, but what purpose does any work-related communication serve? The communication almost always is (and should be) around the tasks, activities, projects etc. Tools like Slack do not provide hierarchy and organization. Tools like kanban on the other hand, do.
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.