[afarrell]

> The single best thing you can do for you career is to learn how and when to say no.

The hard part is turning off the voice of "What do you mean you don't know? I just want want a rough estimate! What is your fucking problem?" in your head. There are a lot of people who simply do not understand the concept of someone else not knowing how to find the answer to a question. Sometimes, those people ask for software estimates.

It can be nausea-inducing to do, but if you do not know how to estimate software tasks, there is no healthier option than telling these folks the honest truth.

[throw4238]

This is definitely a problem. I'm also beginning to believe I should pad the estimate and also tell them "I padded it in case something goes wrong".

Another hard thing to say is 20% of my time is meetings, and those aren't all in 1 block, so I have less time and I'm less efficient.

Finally, I'm beginning to believe you should do your own sprint planning as a dev quick before sprint planning with the group. Otherwise you get talked into half-baked stories with no acceptance criteria and a terribly short estimate.

They want you to keep them honest when it's all theoretical... but not when you're actually doing the work.

[presentation]

Late but - often what I do is, if a task is big enough that I don't feel I can really estimate it, I decline scheduling that task in a sprint, and instead schedule a research task to explicitly spend time scoping/speccing out a complex task. During that time I try to make smaller, stepping stone tasks that I think I can reasonably estimate. I intentionally pad those a bit, and also say that I gave some buffer to account for unknown unknowns, which is a reasonable thing to do.

Also, asking other people on your team to talk it through with you is a good idea as well - they can help you see some unknowns you might have missed that would have blown up your estimates, and also give their take on effort required. If you're uncomfortable with saying you want to work with someone because you don't feel confident in designing a solid solution, you can still couch it in other terms, like that you want to bounce ideas off of someone else on the team, parallelize your work by delegating subtasks, or make sure others on your team are familiar with the design and implementation - all legitimate reasons to work with others, but also that deflect a feeling of just "not knowing".