How to Provide Better Issue Analysis?

Often the managers have a serious issue with the developers that they don’t provide good analysis and estimations. And by good, they mean the one they can understand, which doesn’t need them to ask questions to the developer. And they shouldn’t have to improve it before forwarding it to the client or management.

1. Different People Different Needs:- The analysis and estimations need to be different for different stakeholders. E.g. When a tech lead asks a developer for the analysis & estimation for an issue, he can explain that “In the registration adapter, that event is getting misfired due to which it triggered a wrong insertion in the users table“. Correcting the events, fixing the function logic, and doing unit testing with a few data points will take around 4.5 hours. Your lead would be happy to get such a detailed analysis and estimate. But the same won’t work for a client. For him, if you say the issue fixing time is 4.5 hours, he will start expecting the issue to be working in production after 4.5 hours. So understanding the person and his needs, and explaining to them in their language is very important.
2. Point in Time:- The analysis and estimates can differ with passing time. And that’s alright, you just can’t wait until you have all the facts and have done a complete analysis to provide an estimate. When asked about how much time a particular requirement will take to implement or an issue to be fixed, you will rely on your experience as well as your analysis. Your analysis and estimates at hours 1, 8, and 16 could be different and that’s alright. But, it’s important that you are able to provide the analysis and estimates soon based on the information present at that time.
3. Don’t Just Assume:- If you are implementing “Social Media Login” and you have assumed it to be only Facebook and Twitter login and estimated according to that, it’s important to mention and confirm that assumptions. It’s important that assumptions are clearly communicated along with the Analysis and estimates. If during an issue fixed you assumed a functionality to be working fine and later discovered that it isn’t your estimates can drastically change. So, it’s always better to communicate the assumptions and wherever required get a confirmation.
4. Devil is in the Details:- It’s better to be detailed while providing analysis and estimates. It’s good for you as well as the other party. A written set of steps to implement a functionality can serve as an implementation roadmap (more like pseudocode if you detail it enough). It can also make you more confident about your estimates. . Even if you don’t have enough time to provide detailed analysis in the beginning, you can incrementally detail it out when you move from one phase of analysis to another to implementation. This way you will know why and where the deviation occurs. And it will be useful for future analysis and implementations.
5. Templatize It:- Working on a project for a long time or working on multiple projects of a similar kind, makes you aware of how much time a certain type of activity requires. E.g. Social media login, insert queries, changing the banners, payment implementation, etc. At a personal level, it’s good to create a template for standard and routine activities in a project and also standard implementations that you have done across the projects. This template can contain the details of the steps involved to do a task, and time taken for each of those tasks, any assumptions, things to pay attention to. A personal template will help you revert faster for analysis and estimates. Of course not all the activities are standard and not all the codebases are the same, but this will be useful for a great many tasks. For unknown elements in a task, you can add a buffer to your estimates or mention that as an unknown in your analysis and get back to when you know more about it. But templatizing analysis and estimates would definitely help.