For example, task like filter the bug's report from customer to create a new backlog to be discuss later on Kanban board which should be done everyday. Should I create the new card everyday like "customer support & information xx/xx/xx" or it shouldn't on the board at all since it's like a task not user story. But if I do that, I will not be able to know if someone is currently working on that task and done it yet for today or not. Or maybe it's one card that created only once and can move backward when it's a new day.
Good question. I am a Kanban practitioner - and I don't have a good answer for it. I use Kanban for Marketing - and there are many 'daily' tasks that I'd rather not create new cards for each time we do them, nor really move a single card back and forth between doing and done. Hopefully someone here has a good answer!– Mahesh SinghOct 1, 2015 at 5:00
I'd create a card for these with a week N tag. In Kanban it is important that all the work you do is visible, but it does not require you to over administer the project. If you have a work item (card) that shows that there is this work going on, and you track it weekly, I believe you are going to be fine.
If this work is not visible, you can wrongly assume that your capability is X, but in real life it is way below X.
1This answer is spot-on. I'd like to add though that cards are not the only way you can visualize work. I've seen teams post a daily checklist next to their board that team members initial for very small tasks (like verify backups ran). I don't think this goes against Zsolt's answer because it is still visualizing and tracking, just a different visualization.– DanielMar 7, 2018 at 17:21
If you add another card, you'll end up with an exponential amount of work as you're adding cards to the backlog like 'do the work in the backlog'. Daily overhead to tend the backlog is a normal activity in a Kanban workflow and capacity is reduced accordingly. Mar 13, 2018 at 16:22
I do not track these on the Kanban system, because they are not items of customer value, that travel through the value stream. They are more like meetings or coffee or toilet breaks, or ordering office supplies, or upgrading the software on your computer and stuff like that.
These are not things that are part of the value stream that delivers customer value and do not belong on the Kanban board.
I would suggest 2 approaches that might help
1) Sequester Approach
Here the tasks are listed separately in a sequestered box on a separate personal Kanban whiteboard.
- Create a new personal board space
- The structural representation of the board resembles a table
- Rows - a new row for each recurrent task
- Columns - task name, repetition frequency, last done, next due and current status (whether done or not done)
The personal board also accounts separately for WIP count and could help you visualize the occupancy in recurrent tasks.
2) A custom approach while using any tool to manage your cards (though this might be repetitive process in itself!)
- Create a recurrent task and add a tag or color identification to distinguish between normal and recurring tasks
- Assign a due date for the task
- Follow this cycle on board
- Move recurrent cards to "ToDo" column along with all non-recurrent tasks. This will help you to manage your WIP efficiently
- When you are actually working on the task, move it to "InProgress" column
- Once done with task, move the recurrent card back to backlog with the next due date assigned
Repeat the same cycle every time while planning your work.
I personally have a column titled Daily Actions, which has two sub-columns, "ToDo Today" and "Done Today". Those actions that I do daily have their own cards, and I move them back and forth as part of my daily workflow. For example, let's say I check StackExchange daily. I would have a card that reads "Check StackExchange". Once I have completed that work, I would move it to "Done Today" from "ToDo Today". Then, when I complete my work day, I move it back to "ToDo Today".
I would propose that 'Keep The Lights On' (KLO) work is important in any team, as you would use it to track work as well as work against WIP limits. I personally would choose to track this through a swimlane, two actually: 1 for project type work, the other for KLO. Even though the repeatable KLO work would be recreated or bounced from status to status as the cycles change, I would be able to understand my project vs. KLO throughput as well as keep the team from getting overwhelmed via violating the WIP limits.