10

We have had situations where work has been started on an item and then work needs to be stopped for some reason. I am interested in hearing opinions for moving these items back into the backlog or if we shouldn't move them back into the backlog what are some suggestions for handling these situations?

Examples for moving items backwards:

  1. In the middle of development a decision is made to de-scope the work item
  2. Initial triage of a bug is performed but after analysis is completed it is determined that the bug needs to be fixed but its not as high of a priority as other items in development so move it back in the backlog as a lower ranked issue.
  3. Initial triage of a bug is performed but after analysis we can't recreate the issue or identify where the fix is needed. Based on analysis we cant prove the problem happened at all. Our end users wont allow the issue to be closed because it "could" happen again.
12

The main ideas with Kanban is to visualize your work and to limit work in progress. This allows you to maximize flow while at the same time see where you have bottlenecks.

If you started work on something that now needs to stop for whatever reason, you need to remove it from your work in progress. What you do with it depends on what exactly you want to discover about your process.

For example, you might move it to the backlog to just sit there. If new information becomes available you just pull it back in progress when you have the capacity to handle it and it's a priority. Another approach would be to create a new column in your Kanban board named "Blocked" or "Waiting" or whatever and move it from your "In progress" column there. You might also set a WIP limit on this new column if you are, like I mentioned, interested to discover more things about your process. If you find that the new "Blocked"/"Waiting" column often fills up and hits its WIP limit then maybe you should ask yourself why that is. Maybe you find out that many of them are bugs, or that many are just awaiting new information, etc. Then, you might improve the code, improve your process, try to increase collaboration with end user, or whatever conclusion you reach. When you can work on the items again you can pull them back "In progress", or maybe you might move some back to the backlog and replace them with other things that are in the same state but now have a new priority.

There isn't really a hard rule for how to handle such work items. It depends on your process, your priorities, and if you want to discover why they happen and what you can do to fix it. Having work started on things only to then put it on hold because you can't reproduce it, or because people change their minds can cause waste. Think about "what" you want to achieve, then you will figure out "how" to deal with these items.

| improve this answer | |
  • Thank you for your answer. I think our biggest issue is the case where we triage a problem and decide its not high enough to fix or cant recreate it. Since we started analysis on it it could sit for a long time before we can start working on it. We do that initial triage to get an assessment on how bad the bug reported is so that we can give it the right priority. But... each time we do this the clock starts ticking on our throughput so it could delute what our true throughput is once development actually starts – Debbie Jun 5 at 13:50
  • You spend a lot of time to triage bugs? That's basically work you are performing. So, you could for example split your 'in progress' column in two subcolumns 'developing' and 'analyzing'. You might also add an 'in triage' column, or you might use swimlanes to treat triage work just like you treat dev work. Heck, you might even create another kanban board just for the triage, and once you know for sure you need to work on a bug and have all needed data to do so, move the bug in the development board. Like I said, there is not an universal answer to this, it depends on what you want to do – Bogdan Jun 12 at 16:17
1

You mention in the comment under Bogdans answer that the biggest issue is related to triage of bugs. You could choose to create a 'triage' task that moves through your flow. The outcome of the triage could be added (or linked) to the bug so that you always know where to find it. This means that the bug stays on the backlog unless triage shows that it needs to be addressed, then you place it on the board. This way you can also track how many times a triage is needed, which might provide insights on, for example, the quality of work

Another option (but I would not go for this one): The bug goes to the backlog, triage is done but not made visible on the board. If triage says that you need to pick it up, you place it on the board. This option might be suitable if the proces of triage is extremely short

| improve this answer | |

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.