This is a hard and controversial topic. I don’t agree with people saying estimating is worthless.
From my experience on both sides - as a manager as well as the developer, I see many benefits to them. I know this is not the answer to your question but I would like to address that first.
Wrong estimates mean generally one of four things:
Poorly described and scoped User Stories. If US is not separated into clear, actionable tasks with clearly defined scope/deliverabilities than well… There is no sense to estimate how long it will take to prepare a billing module in a banking app, but estimating adding a new modal, with 3 actions (of which 2 are developed) and a content based on the integration is a different story. Of course estimating all tasks does not mean that epic level will be „estimated automatically”. You still need to accomodate the unplanned, time for meetings, people being off, sick etc.
Lack of expertise - sometimes you just don’t have skills and knowledge to provide meaningful estimates. Even worst, you may not have in your org anybody who has - then yes, estimates is closer to guess work which still provides you a lot of important info.
Lack of ownership - well, sometimes people just don’t give a shit about their job or tasks enough to actually provide meaningful estimates.
A lot of technical debt - sometimes it does not matter how much everyone tries, if your code base is terrible quality and making a small change requires a lot of effort then well… you have bigger problems than estimates
Now, as the name suggests „estimates” are „estimates” and nothing more. They state how much we think something will take, not how much it will take. I found that usually 10% variance is a good result. 25% in immature team with good technical and business leadership. Above that it means your team has problems which should be investigated and actioned.
Now when it comes to the tips:
Don’t ever think it terms or User Story, think about actual tasks. Specific things you have to do. If you are not sure what has to be done spend some time figuring it out. If anything is unclear refine as much as needed. Break down US into tasks, still to big? Subtasks. They don’t have to be on the board, they are a tool for you to understand the task
Ask developers of higher or similar level. If there is a step which seems complicated, maybe they have done it before? They did? Well maybe they will help to estimate how much it will take you? Maybe they even have something that can be reused or they can support you to make the process easier and quicker
Look at similar tasks, but done by people of similar skill level or you in the past.
Don’t be afraid to provide inaccurate estimates, if you are doing your best and using all available resources to make them best you can. There will be always things you may not anticipate, if you are not a leader, you shouldn’t be to be prepared perfectly and know most of the things. Well even if you are leader, you cannot know everything.
Remember that 1 MD of a task development is a 1 MD of development. If you spend 2h a day on meetings, 1h on networking, now the due date is in 2 days time
Now the final thought: Estimate, everything, if you don’t want to do it in exact time, do it in Fibonacci (though I still prefer the actual time). Why? It gives you a valid information about the tasks for the future and it should give your leadership a lot of other information - about their team abilities, complexity of the project, technical debt, sometimes even about things like ways of working, too much bureaucracy etc.
This is a hard and controversial topic. I don’t agree with people saying estimating is worthless.
From my experience on both sides - as a manager as well as the developer, I see many benefits to them. I know this is not the answer to your question but I would like to address that first.
Wrong estimates mean generally one of four things:
Poorly described and scoped User Stories. If US is not separated into clear, actionable tasks with clearly defined scope/deliverabilities than well… There is no sense to estimate how long it will take to prepare a billing module in a banking app, but estimating adding a new modal, with 3 actions (of which 2 are developed) and a content based on the integration is a different story. Of course estimating all tasks does not mean that epic level will be „estimated automatically”. You still need to accomodate the unplanned, time for meetings, people being off, sick etc.
Lack of expertise - sometimes you just don’t have skills and knowledge to provide meaningful estimates. Even worst, you may not have in your org anybody who has - then yes, estimates is closer to guess work which still provides you a lot of important info.
Lack of ownership - well, sometimes people just don’t give a shit about their job or tasks enough to actually provide meaningful estimates.
A lot of technical debt - sometimes it does not matter how much everyone tries, if your code base is terrible quality and making a small change requires a lot of effort then well… you have bigger problems than estimates
Now, as the name suggests „estimates” are „estimates” and nothing more. They state how much we think something will take, not how much it will take. I found that usually 10% variance is a good result. 25% in immature team with good technical and business leadership. Above that it means your team has problems which should be investigated and actioned.
Now when it comes to the tips:
Don’t ever think it terms or User Story, think about actual tasks. Specific things you have to do. If you are not sure what has to be done spend some time figuring it out. If anything is unclear refine as much as needed. Break down US into tasks, still to big? Subtasks. They don’t have to be on the board, they are a tool for you to understand the task
Ask developers of higher or similar level. If there is a step which seems complicated, maybe they have done it before? They did? Well maybe they will help to estimate how much it will take you? Maybe they even have something that can be reused or they can support you to make the process easier and quicker
Look at similar tasks, but done by people of similar skill level or you in the past.
Don’t be afraid to provide inaccurate estimates, if you are doing your best and using all available resources to make them best you can. There will be always things you may not anticipate, if you are not a leader, you shouldn’t be to be prepared perfectly and know most of the things. Well even if you are leader, you cannot know everything.
Remember that 1 MD of a task development is a 1 MD of development. If you spend 2h a day on meetings, 1h on networking, now the due date is in 2 days time
Now the final thought: Estimate, everything, if you don’t want to do it in exact time, do it in Fibonacci (though I still prefer the actual time). Why? It gives you a valid information about the tasks for the future and it should give your leadership a lot of other information - about their team abilities, complexity of the project, technical debt, sometimes even about things like ways of working, too much bureaucracy etc.
👌