One agile methodology is to use fibonacci numbers, I think its called planning poker out of scrum. Then you assign the numbers to tasks/tickets with the bounds

One agile methodology is to use fibonacci numbers, I think its called planning poker out of scrum. Then you assign the numbers to tasks/tickets with the bounds being: * 1 being easy, doable in a day * 13 being too many unknowns, have no idea how long This works for estimating the size/scope of work, but does not really work for estimating time. Estimating time is mostly pointless as there are unknowns that come up, even on small tasks, especially dealing with existing systems. What this does provide if you use the numbers consistently is a team velocity for planning purposes. After completion of work you (as PM) can go back and look at two or four week averages of point velocity. Then future work point estimates can be grouped and rough completion timeframe estimated based on past velocity. If you want to get better at estimating your own tasks, like if a PM is asking "pacifika, how long to do $X?" the best way is to just do more development work and you'll be more confident with your estimates. Working at a place that expects unknowns and doesn't berate people for "missing a date" is a good thing. A way around lots of planning/estimating time is to do Continuous Delivery. Breaking up work into smaller tasks and putting them into production when they are ready. Even if this means temporary work just to put something in production ahead of other parts. Its super simple to delete temporary things later. Having the confidence to run tests and deploy small changes to production whenever you want to alleviates a lot of waste, from a lean perspective, in the planning cycle. No meetings to coordinate lots of moving parts, no 3 releases per year with a weekend long release that people have a 50/50 confidence factor in. A simple deploy when ready.