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
-
mostly from experience. small tasks are easier to estimate tho, so you can break a big one into smaller ones
-
C0D4669023y- Size of task
- Expected impact on codebase and time give or take in days to deal with it.
This can usually be worked out quite simply if you are familiar with the code and business rules in place.
A single IF() would be minuscule - an hour or so with updating tests / writing new ones, but a whole new method and process flow would be substantial.
Otherwise, just say 2 weeks.
I can normally estimate down to the day, even on 12 month projects.
It comes from experience and your absolute knowledge of what it is you are touching and understanding how to turn X into Y while shoving Z down its throat and removing A,B, and C from its ass. -
Hazarth95373yI don't actually know. I just imagine myself doing it, and kinda fast forward through all the planning steps in my head with all the potential problems and roughly imagine how long would that amount of work take me in days. then I add a buffer for potential unseen problems and that's it I guess
-
Smoke, magic, a few cups of coffee, and a random number. In reality all estimates are just comparisons against other previous tasks
-
Root797783yIt depends on a lot of things.
Size, impact, test coverage, complexity of testing, your knowledge of the codebase, clarity of the requirements, number of iterations, who is responsible for signing off and how many additional feature requests they will want, your number of meetings, your mental health, how much you care (or don’t), if you want to slack, etc.
My usual estimating doesn’t work at my current employer. Even the simplest tickets take about eight times longer than they should because everything is so terrible and so slow. -
Crost40753yMy theory is that estimating is not worth the time and is not precise enough anyway as there is always some unexpected stuff when you dig into a code base.
I believe (having read this opinion from a couple big names in the agile community) that it's better to focus that time into breaking down stories. You can just have 1 person quickly make a guesstimate at 0.5, 1 or 2 days for each card then and it will probably be just as accurate, but you have skipped the time consuming meetings of pointing and instead used that time on breakdown.
Related Rants
How do you guys actually estimate any given task..?? What do you consider..?? Or do you just guess it as per experience..??
question
estimation
eta