Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
mundo0349796yAssumw you are always busy, stop saying yes to stuff, delegate shit that is not yours.
-
If you are supposed to make reasonable estimates, then you'll need time for those estimates. If somebody wants quick estimate I say: 6 months. If I am allowed a day or two just for estimating, numbers go down.
Estimates by design are dealing with uncertainty. So you will be wrong most of the times. An estimate is just that: a gut feeling that you might achieve something in a certain amount of time, yet it may be incredible easy (there is a library for that) or it may explode in your face (we have to start another project to lay the requirement for the estimated project), that's life.
Don't treat estimates as must-be-achieved-in-that-time. That's how management wants to work. That's not how any creative process works.
Be honest when communicating that you over or and under-estimated a task and try naming reason why you did so. Esp. when you realize you underestimated, escalate early. Give management time to reschedule and reprioritize. Good managers can deal with that. -
I never really underestimate my tasks. It's easy. Analyze the task, assuming no external problems, just plain coding and testing. Then multiply times 2 :D if it feels like it's gonna take 2 days tops I can guarantee you 98% of the time you'll spend full week on it.
-
@k0pernikus I guess this is part of the question of what a story point is, and how to achieve an actual burndown chart, and not create technical debt.
Related Rants
How do you manage best not to over-estimate your working capacity / underestimate tasks?
rant
wk115