Some development tasks are very complex and none of a development team can propose a solution. Instead we have to find a solution and, of course, nobody knows how soon the solution will be found.
What should we do with such research tasks in Kanban? If I create a task and assign it to some developer then this task will be staying in the "In Progress" column for an indefinite period of time.
R&D tasks have a higher degree of uncertainty and are generally not a good fit for a WIP limited Kanban board. It can end up creating a bottleneck and blocking other work.
R&D tasks can often be handled as part of designing and planning specific scope. For example, there's a big, thorny problem. Spend time designing and working through it. Then, once there's a handle on it (a higher degree of certainty) start chunking it into smaller stories. Those can be threaded through a Kanban board. If they get stuck in a column (push up against a WIP limit) it can suggest its not well enough understood or small enough a story.
There are R&D tasks which are too big for the above mentioned approach. Those with a really high amount of uncertainty. Those are best done in a separate, non-Agile, workstream. Do track and timebox the effort as well as expectations of where the effort should be at a certain time. For example, after two weeks we expect to have a design document. Then check in to see where that milestone has been met. Whether it has or hasn't provides information on the level of uncertainty around the task and can help decide next steps.
Were the team to have a relatively large number of high uncertainty tasks, compared to work that can reasonably flow through a Kanban board, it may be time to recheck alignment between stakeholder expectations on scope and the team's capabilities.
All work should be tracked. If you hide the things that don't conveniently work in your system, you eliminate the benefit of kanban.
If you put a large open-ended research task into progress, it will take one spot in your WIP as you describe. This will encourage the team to break down the task, which will in turn force them to think critically about the work they are doing. Even bleeding edge research has small steps. There may be a particular option you are researching, or a variable you are attempting to eliminate. Breaking down research makes you a better researcher the same was breaking down development forces you to think critically about the code and become a better developer.
Even research tasks should be planned and tracked.
1) dev team should determine steps they are about to perform with expected outcomes 2) estimate these steps. The best way is to breakdown to tasks no longer then 1 day of execution 3) sync on your future steps right after performing tasks with unknown outcomes
In case you are taking "big" research task in progress it means dev team has no idea on how will they reach the result.
One approach you might consider would be to add a time-boxed task that is an investigation of how you would go about doing the research. The goal would be at the end of this time-boxed task you would know more about the research and so would be in a better position to:
As an example, consider some research in to a new way of organising your companies data. You add a task to your Kanban board for a one-week time-boxed analysis of the problem. At the end of the week the developer assigned the task reports back that they see three possible areas of investigation. They then create three new time-boxed tasks to analyse each solution. Once those tasks have been completed the developer suggests that there is a prime candidate for a solution, but to be sure they need to do some more research. They work with the team to create a list of tasks that will cover this.
This process of discovery, then leveraging the discovered knowledge to create new tasks can be continually repeated until the work is done. All the time you are getting a clearer picture of how the work will be done and so it becomes less and less of an unknown.
Don't track such activities with Kanban. Instead, set aside developer time (something like 1-2 days per week) for research when the team needs it. You need to ensure that progress is being made even though it's not measurable using Kanban mechanisms, for example by having developers give internal presentations regularly, which has the added advantage that other team members profit from intermediate results.
@Chris If your R&D task stay in In progress status for too long, your Lead Time and Cycle Time will be affected. So, you get bad statistics and for the future you will not get accurate estimates (" when this tasks will be delivered?") for this level of service tasks. The actual benefit of Kanban will be lost: you'll get the board with moving Jira issues on it, but it is not a Kanban as software development approach.
