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
-
Have you considered actually getting a dart bord, hang it up and the next the fuckers ask for an estimate tell them to come to your place, gatter all the devs there too and just ask them to throw the fucking darts themself, as you devs are getting to good and only aim for the 20 points slice... (Every dev has to be in it of course and acct, like they do it all the time... (Sure you might get fired, but probably it will be wort the laught ;))
-
T-shirt size estimates only work if you are basing those on collected examples. Best way I found so far was taking tasks that are done and write down with the team what was done in the task. Than I search one smaller and one greater task and do the same. Afterwards I name them S M L.
Really important is here to never tell the team the time it really took because those numbers will stick and they stay always with wild guesses.
Every two sprints with 2 weeks (if you do sprints) take some new tasks and do the same again.
Estimations should then be only done by comparing the task to estimate with the 3 samples. And let the team discuss where they see the task. Is it smaller than S? Like S? more than M? but less than L?
When you don't tell the team the numbers behind the sizes you get a pretty good estimation most of the time.
Related Rants
Also this
My teams current process is:
1) Asked by product to create “T-Shirt size” estimates, also known as a WAG (wild ass guess). The process is the mental equivalent of throwing darts while blindfolded, after being spun around in a circle and pointed in the wrong direction.
2) Product make firm commitments to upper management based off these. Ensuring them that all these features will make it out in Q2.
3) 4 days before Q2 starts, product ask engineering to figure out the real estimates based off no concrete information what so ever.
4) 4 Weeks into Q2, product provide the missing information.
5) Engineering inform product that the estimates are out by a factor of 1.5 - 3 times the original estimates.
6) Product sends angry email to upper management that through not fault of product, engineering are unable to meet the deadlines.
7) Everyone shout and complain until 1 week before Q3, then see point 1.
Following this process, you and your team can be just as delightful as me.
That’s the practiseSafeHex guarantee!
rant
wk147