3

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.

1

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.

3

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.

  • Thank you! How should this breaking down be implemented in terms of Jira issues? Should we create sub-tasks? Should we close the original task and start new tasks instead? Doesn't it eliminate the benefit of kanban in some way? – Chris Brettini Jan 4 at 17:11
2

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.

2

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:

  • Break it down in to more manageable sized tasks
  • Estimate how long it will take

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.

  • If the same developer is assigned again and again (this makes sense because this developer better undestands the problem area) then this looks like we are fixing Kanban, like kind of workaround... – Chris Brettini Dec 23 '19 at 16:29
  • I would expect the team to self-organise who did the work. I'm pretty sure most teams would look to spread the work around, to avoid knowledge being locked in one person's head and to increase the eyes on the analysis tasks. – Barnaby Golden Dec 23 '19 at 16:39
  • Thank you! What is the way to implement it in Jira? I don't think we should create many technical tasks instead of one logical task. Maybe we should create sub-tasks of the original task? Is it OK from the Kanban point of view? – Chris Brettini Jan 4 at 17:27
  • I don't think that there is a right and wrong way to do this. Best to try an approach and see how it goes. – Barnaby Golden Jan 4 at 22:05
0

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.

  • Thank you! I'm not very experienced in Kanban, could you please tell me what can go wrong if I just let a research task to stay in "In Progress" column for a long time and, for example, increase WIP by 1? – Chris Brettini Dec 22 '19 at 14:45
  • 1
    I disagree with this answer. I think the suggestion you make about leaving time in the week works very well for things like personal learning and broad research intended to grow general understanding. What I read in the post was that research was required as part of the work to do the task. In those cases, I would argue that this is simply part of the work and therefor must get tracked. – Daniel Dec 22 '19 at 16:17
  • @Daniel that may be true, and your answer recommending breaking down the task into manageable pieces is likely a good way to handle it. – Hans-Martin Mosner Dec 22 '19 at 18:26
-2

@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.

  • Your lead time and cycle time show the actual number of days from when something was asked for to when it is complete or, in the case of the latter, from when you started applying effort to when it was complete. If you remove 5 days from the work because it was "research" you are creating fake data. – Daniel Dec 22 '19 at 16:13
  • Please, read my note carefully - I was talking about the impact of succeeding author's question "what if I just add the task and increase WIP?" Where do you see encouragement to make fake data for Kanban statistics? – Pavel Kudrautsau Dec 22 '19 at 16:42
  • Perhaps I misunderstood. I read your answer to say that he should not put R&D tasks in the board in order to avoid the statistics looking bad. Did I read that wrong? – Daniel Dec 22 '19 at 18:45
  • My initial idea was the consequences: "what if I add this big R&D task on the board and just increase WIP for In Progress column - what will be the consequences". I answered why this is bad idea - to put unusually big tasks and inrcrease WIP limit. – Pavel Kudrautsau Dec 22 '19 at 19:11
  • 1
    HI - although I agree with your point, it does not address the OP question. You're stating an impact of what will happen by doing as stated by the OP... thus it's more of a comment than an answer. Unless you prefer to rephrase it, it'll be converted to comment shortly. – Tiago Cardoso Dec 23 '19 at 8:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.