The 9 questions for each problem in the modified Kanban Approach

June 22, 2021

In continuation to the blog, the 3 colored modified Kanban approach, here are the “famous” 9 questions, that we (me & my team) ask ourselves every day.

Whenever you have active problems in the application, it becomes imperative to track each problem down to closure. To do that, you must ask certain questions about the problem, so that you get a clear picture of each and every issue. Over the course of two and a half years; we have managed to formulate and fine-tune these questions, and the current set that we use is listed below. I will go through each one of them in detail.

These questions can be maintained in an Excel file, or put on a wiki page or in your notebook, or simply wherever you want to have them handy. Heck, they can even be added to each of the issues listed on your JIRA board.

Before answering the 9 questions, there are three points to note.

1. The “Current Status” and the “Next Action” are the two equally important items. The answers to these two points should be a maximum of one or two lines.

2. Answer to each question can be only “Yes“, “No” or “TBD” (short for “To Be Decided”)

3. Follow the order sequentially from top to bottom. Each preceding question or status acts as an input for the next question or status.

The most “famous” 9 questions are listed below:

So, here it goes. Let me explain what each of the points means.

Current status – This point will highlight the exact status of the problem. To note here, it should NOT be very descriptive. Keep it limited to one or a maximum of two sentences.

Is the case being actively worked on?

Why should you answer this question? – Team members may be working on multiple issues at the same time and this question will immediately tell you if they have this as an active case or if they are working on something else. This will also tell you if they are focussing on something else rather than the most important items.

Is this a defect?

Why should you answer this question? – If you have read the Business Requirements Specifications thoroughly, and if you know your application correctly, then you should probably know the answer to this question right away. If this is NOT a defect, then this could be a data problem or a user understanding issue. If this is a defect, then you know that you need to fix something.

Have we identified the root cause?

Why should you answer this question? – Irrespective of whether the problem is a defect or something else, the member working the case; should be aware of the exact root cause of the problem. If the answer is “Yes”, then cool, you know what to fix. If the answer is “No”, then you know that your team members are still working on this problem.

Do we have a fix identified if this is a defect?

Why should you answer this question? – This question is driven by the question above it. If the member has done the complete Root Cause Analysis, then he or she probably knows the fix for the problem. This question is answered only if there is a defect identified.

Is the fix/development complete?

Why should you answer this question? – This will give you an immediate picture of the status of the fix or the development. If the answer is “No”, then you can start asking questions to the team member to understand the current status of the fix.

Has unit testing been done on the fix?

Why should you answer this question? – This question is driven by the two questions above it. If you have a defect identified AND if the fix/development is completed, then has your developer/team member completed the unit testing on his local machine and in the Dev environment? This question will also let you know if the team members are doing their Unit Testing or not.

What is the target build date for assigning to the QA team?

Why should you answer this question? – Planning of deliverables is done for every sprint. This question will instantly let you know when the fix has been planned for QA testing and subsequent release. If the TBD is too much in the future, then you should start asking questions to your team member who is working on the problem.

Has QA testing been completed?

Why should you answer this question? – This question will let you know if the QA team has certified the fix or if they are still working on the fix. Once the QA testing is done, then you can verify in which sprint is the fix will go for production. Again, if the date from the preceding question is too much back in the past and the answer to this question is “No”, then you need to start asking the QA team for updates.

Are there any dependencies on anyone?

Why should you answer this question? – Many times, while team members are working on fixes, their next steps could be decided by someone else working in the team. This could be another system, a BA in the team, peers, a Technical Architect, or even the Business Team. If the fix is not progressing further, then this question will show you if your team members are waiting for inputs on someone/something else.

Next action – Finally, at the very end, we have the “Next Action”. This is again one or two lines long at the most and should tell you a clear picture of what needs to happen next or with whom the next action lies.

That’s it. In my day-to-day work, I have found these 9 questions to be incredibly useful to track problems to closure. The simplicity of these 9 questions and their (only) 3 answers will bring consistency in the statuses that you receive from your team members.

What is the beauty of these 9 questions? Being non-technical questions, absolutely anyone in the organizational hierarchy can just glance through each of the answers and understand whether the problem at hand is a real problem or just a case of “User Understanding”.

About the Author:

This blog has been written by Ketan Gaydhani, Technical Project Manager at IVL Global. With 14+ years of working experience in Application Support, he is actively involved in solving functional and technical problems for the customers so that they can have a seamless experience with the application.

His area of interest includes interacting with customers to understand their business so that their user experience about the application can be delightful and their business challenges can be solved to increase their revenue stream.