Let's say I'm working on task 1. I found bug and created new task for that. Let's say task 2. Does it make sense if I impede task 1 under my name?
The concept of you impeding a task doesn't make sense, conceptually. An impediment is "a hindrance or obstruction in doing something". I highly doubt that you are obstructing yourself from completing the planned task. However, the bug that you found can be a hindrance or obstruction. I would refer to the existence of the bug as the impediment. If the bug must be resolved in order to complete the planned work, then I would say that the bug (task 2) blocks the planned work (task 1).
Then, in the context of the Scrum framework, I would raise this impediment at the Daily Scrum.
Does it make sense if I impede task 1 under my name?
Yes. No. Maybe. It depends.
In general, Kanban is about flow. If your unit of work is a task, rather than a user story that represents a vertical slice, then it's certainly possible for a task to be blocked for any number of reasons. However, a task isn't inherently "blocked" simply because another task is taking up a slot; in practice, this is usually a normal function of a Kanban in response to work-in-progress (WIP) limits.
Newly-discovered work should be prioritized using your project's agreed-upon methodology. Enqueued work is then marked, moved, and sorted as needed to visualize the work on the board. This may involve blocking, but can also involve moving work forward or backward in queues, reshuffling queued work, or other adjustments that optimize for flow.
Talk to your team. Ask whether you should tie up a work-in-progress slot until the task and its new dependencies are complete, or whether the work should be moved back to a previous column to be replanned and reprioritized. There is no right or wrong answer to that; it depends on your team's operating agreements.
Handling Blocked Tasks
Unless you have a column or board of your own within your Kanban system implementation, it doesn't make sense to "block" your own work. What you're probably trying to do is describe dependencies, and handle over-limit work in a sensible way. Here's one common approach.
| Backlog | Ready (WIP: 5) | In-Progress (WIP: 2) | Done | |---------|----------------|----------------------|--------| | task 9 | task 4 | task 2 | task 1 | | task 10 | task 5 | task 3 | | | task 11 | task 6 | | | | task 12 | task 7 | | | | task 13 | task 8 | | | | task 14 | | | |
Let's say you're working on task 3, and discover some unexpected dependencies on the task. If your work units are at the task level, you would:
- Identify the dependencies (e.g. tasks 15 and 16) and put them on the backlog.
- Color-code, notate, or otherwise mark task 3 as blocked.
- Move task 3 out of WIP, because you can't work on it before working the dependencies.
- Move task 3 down into a blocked status within the "In-Progress" column if this work unit takes priority over other work items in the backlog or ready columns.
- Move task 3 back to "Ready" or "Backlog" if it should be re-prioritized along with its dependencies.
- Move tasks around within and between columns as needed to visualize the work and respect WIP limits.
- Re-prioritize the dependencies as needed for your process by re-ordering your queues.
- Pull new work from the appropriate queue if and only if a free WIP slot is available in the following queue.
New Kanban State, with Dependencies
For example, if task 3 is still a priority, your new board configuration might look like this after visualizing the dependencies and blocked tasks:
| Backlog | Ready (WIP: 5) | In-Progress (WIP: 2) | Done | | -------------------- | ---------------- | ---------------------- | -------- | | task 16 ->(15), <(3) | task 15 <(16, 3) | task 2 | task 1 | | task 4 | task 5 | | | | task 9 | task 6 | | | | task 10 | task 7 | | | | task 11 | task 8 | | | | task 12 | | | | | task 13 | | | | | task 14 | | | | | -------------------- | ---------------- | ---------------------- | -------- | | | | task 3 ->(15, 16) | |
This configuration basically says:
- Task 3 remains a top priority. We can't do additional work until task 3 and its dependencies are completed, unless it's de-prioritized and moved back into a preceding queue.
- We have to finish task 2 to free up an "In-Progress" slot for task 15.
- Task 16 is waiting for 15 to be pulled from Ready -> In-Progress to free up a "Ready" slot.
- We should complete tasks 15, then 16, then 3.
You can certainly handle this in many other ways, so long as your process respects your WIP limits and prioritization agreements. Agreements within the team, and with business stakeholders, will define how new and blocked work should be handled. The less slack in your process, the more likely it is that you'll have to move things around or eject items from your activity columns to accommodate new, higher-priority work. However, that's largely an implementation detail, and the how of it can vary widely between projects.