Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
mostly from experience. small tasks are easier to estimate tho, so you can break a big one into smaller ones
C0D4681835d- 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.
ars111655dExperience plus I compare it to other tasks.
Ikaroz4605dTeams are supposed to pick a "golden story" to use as a baseline for estimations. I myself don't care to give out estimations. I would have to spend an hour going through a story, making sure of all the technical details. There are always some curveballs, like an API not supporting something or someone created an existing feature that I'm supposed to use, but it requires refactoring (not changing) to make it work for my use case. That's just waste.
Estimates are for business people, not developers, because they somehow need deadlines. They don't understand that estimates are often wrong and can easily lead to team members playing them up to cover their ass. You can look up Allen Hollub on Youtube to see a more radical view of the same kind of thought.
Hazarth44485dI 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
Root799144dIt 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.
Crost37303dMy 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.