This is one of my pet frustrations, and I've solved it over the years with a very specific software development workflow, which all issues in my project go through.
The states, which many of you may recognize: ANALYSIS, REQUIREMENTS, SPECIFICATIONS, DESIGN, INTAKE, IMPLEMENTATION, REVIEW, VERIFICATION, RELEASE.
Every issue in my projects is assigned one of these states. If it cannot be pushed forward (the workflow goes from left to right), the reason is that one of the prior states was not done thoroughly enough.
More often than not, an issue will get to INTAKE (where the developer reviews the prior states and makes sure they are complete), and .. gets immediately kicked back to ANALYSIS.
ANALYSIS, when not done properly (identifying the similarities, identities, and differences of the aspects of the issue), always screws with the time estimate problem. When done properly, it solves the estimation problem.
And, more to the point, when an issue has been left->right but then gets bounced back to ANALYSIS, it shows the project manager which issues have not been properly analysed, and therefore are a source of time over-budget.
So many times I have solved the ire of managers by just showing them the kanban, and pointing out the specific progress/delay of their 'pet issues' from left->right, not getting past the two quality control steps ("INTAKE" and "VERIFICATION" are quality stages), and getting bounced to ANALYSIS.
Seriously, don't overlook the importance of systematic analysis. It helps immensely with reducing time budgets. I note with great interest that this washing machine project frequently bounced the issue back to ANALYSIS, multiple times, because it wasn't done properly ..
The states, which many of you may recognize: ANALYSIS, REQUIREMENTS, SPECIFICATIONS, DESIGN, INTAKE, IMPLEMENTATION, REVIEW, VERIFICATION, RELEASE.
Every issue in my projects is assigned one of these states. If it cannot be pushed forward (the workflow goes from left to right), the reason is that one of the prior states was not done thoroughly enough.
More often than not, an issue will get to INTAKE (where the developer reviews the prior states and makes sure they are complete), and .. gets immediately kicked back to ANALYSIS.
ANALYSIS, when not done properly (identifying the similarities, identities, and differences of the aspects of the issue), always screws with the time estimate problem. When done properly, it solves the estimation problem.
And, more to the point, when an issue has been left->right but then gets bounced back to ANALYSIS, it shows the project manager which issues have not been properly analysed, and therefore are a source of time over-budget.
So many times I have solved the ire of managers by just showing them the kanban, and pointing out the specific progress/delay of their 'pet issues' from left->right, not getting past the two quality control steps ("INTAKE" and "VERIFICATION" are quality stages), and getting bounced to ANALYSIS.
Seriously, don't overlook the importance of systematic analysis. It helps immensely with reducing time budgets. I note with great interest that this washing machine project frequently bounced the issue back to ANALYSIS, multiple times, because it wasn't done properly ..