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
-
Sales employee Bob wants a clickable blue button.
Bob tells product owner Karen about his unstoppable desire for clickable blue buttons.
Karen assigns points for potential and impact (how much does a blue button improve Bob's life, how many people like Bob desire blue buttons)
Karen asks the button team how hard it is to build a button. The button team compares the request to a reference button they've built before, and gives an ease score, with higher score being easier (inverse of scrum points).
These three scores are combined to give a priority score. The global buttonbacklog is sorted by priority.
Once every two weeks (a "sprint") the button team convenes, uses the ease scores to assign scrum points. Difficult tasks are broken up into smaller tasks, because there is a scrum point upper limit. They use the average of the last 5 sprints to calculate each developer's "velocity".
The sprint is filled with tasks, from the top of the global button backlog, up to the team's capacity as determined by velocity. Approximate due dates are assigned, Bob is a happy Bob.
What if boss Peter runs into the office screaming "OUR IMPORTANT CLIENT WANTS A FUCKING PINK BUTTON WHICH MAKES HEARTS APPEAR"?
Devs tell boss to shut the fuck up and talk to Karen. Karen has a carefully curated list of button building tasks sorted by priority, can sedate boss with valium so he calms the fuck down until he can make a case for the impact and potential of his pink button.
Karen might agree that Peter's pink button gets a higher priority than Bob's blue button.
But devs are nocturnal creatures, easily disturbed when approached by humans, their natural rhythms thrown out of balance.
So the sprint is "locked", and Peter's pink button appears at the top of the global backlog, from where it flows into the next sprint.
On rare occasions a sprint is broken open, for example when Karen realizes that all of the end users will commit suicide if they don't have a pink heart-spawning button.
In such an event, Peter must make Bob happy (because Bob is crying that his blue button is delayed). And Peter must make the button team of devs happy.
This usually leads to a ritual involving chocolate or even hardware gift certificates to restore balance to the dev ecosystem.23 -
Client: I want to go to the moon!
Me: Sure thing! I will build you a rocket.
Client: But I want you to build me a car.
Me: A car can not take you to the moon.
Client: Build me a car.
Me: OK.11 -
A guide to estimations.
1) don’t give an immediate answer. The first “timeframe” you give will be held against you and will result in overtime and working weekends.
2) think of a relevant piece of work and the time that took.
2.1) if it’s something you haven’t done before, add some adequate research time.
3) allow half a day of testing for every day of development.
4) add a day as buffer - this is good for on the fly bug fixes
5) calculate time
6) now give an educated estimate.
7) this should take you 5 seconds to get through mentally.
8) if scope creep occurs: goto:15 -
Manager: "How long will this take?"
Me: "Er... it depends."
Manager: "Depends on what?"
Me: "Well, if the reactive hyperflux core's external dampeners are--"
Manager: "Yeah, yeah, whatever just get it done."
Me: "You got it boss."2 -
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!4 -
In our company the estimation is done by customer / PO. Usually, the deadline is set to the day before yesterday after the issue arrived. Always highest prio.
Oh, almost forgot: when a developer does his estimations, the resulting number gets divided by 7 by the PMs. Buffers? Who needs that. QA? Pfff. We are EFFICIENT.
Deadline not met? Bugs in the release? The developer must be bad.
8 -
Boss: I need you guys to give me an estimate on how long this project will take.
Team: We've put a lot of thought into this, and we think we can get it done in 2 months.
Boss: I need it next week.2 -
-Boss instructs me to always set high estimates
-Asks in how many days will i finish X
-I think 3, but adding 1 extra day for each random problem i tell him one week
-He says thats way too long, make it 3 days
-Shit happens and i can barely finish it in one week
-My boss:
1 -
I hate doing estimates, but I had to adapt. Since I work remotely and under contract, I'm used to track my time and estimate by hours.
I did a lot of mistakes before, which means I worked for free to wrap up fixed price projects.
Today, the method that is working best for me is:
1) positive estimate
2) most likely estimate
3) worst case estimate
Sum up and divide by 3.
I do this for every task.
Also, for Web projects, I like to divide tasks in categories like: HTML / CSS, UX, programming, testing.4 -
The best estimations are the team based estimations. Do a planning poker, but don't agree on the average or median, just sum up all the estimations! 😉1
-
wk147
Estimating development duration.
Whatever number that first came up on your mind... multiply it with 2.5.1 -
Not mine, saw this one somewhere on the internets [prolly in one of commitstrip's comments]
- make an initial estimate [4 hours]
- double the number [8 hours]
- incr units [8 days]2 -
As if my head couldn’t get any bigger... today we had the guys from the static analysis tool come in to show us how to use the tool and all that... the guys tell us don’t be alarmed, everyone who runs the tool for the first time has thousands and thousands of errors... my co worker did his as a “demo” and had 44 thousand MISRA errors. And a McCabe Complexity score of 700 in main().. I laughed ... and he and the guys from the tool laughed and said well fine then let’s see yours... so they set mine up to run, the room was silent, as I just smiled... only 2 MISRA mandatory errors.. and a few dozen required MISRA errors. My main McCabe score was 13.... understand both software project are working, and do very similar functions, only difference is different generation of product and who programmed it...
My boss walked in the room ... and says sooo how bad was Chris’ code as a joke... and the static analysis tool guys (who literally check people’s code for a living!) says ugh no sir, you have a very talented software engineer on your hands... we’ve never seen someone run the tool and have that few of issues... my co worker was very jealous to say the least... -
Two weeks is just enough time for the person who asked for the thing to forget when they asked for the estimate.
-
I never thought I was a highly opinionated person (read: elitist) until I realized it bothered me that my coworker prefers low-profile rubber dome keyboards to mechanical ones. I'm going on a journey for personal growth this week.6
-
First I write a list of all the features that the client wants on their website, then I break down the features into tasks, then I estimate the number of hours required for each task, then I sum all the hours and multiply the final number by 3.1
-
Each sprint lasts for 2 weeks. But I get the basic info to start working on my stories only when 3/4th of the sprint is completed....
So yeah....no one gives shit about estimation at least in my case.6 -
Here's how it usually goes:
1) I estimate the different aspects of the assignment to the best of my abillities, based on customer criteria and information. I come up with an realistic estimate for development and testing.
2) My PM runs the numbers through an algorithm. It adds time for other stuff, but its all still very fair and in tune.
Now to the fucked up part.
3) My ceo and cto looks at the estimate, and he will just turn on every possible button and twist the estimate into what he thinks he can get the customer to pay🤢🤮
This ends in the customer saying - no thank you.
He comes back to us and does not understand why they declined.
Idiot! -
I estimate by guessing how long it will take me to code then multiply it by 3 and round up to the whole unit.
10-30min work = 1 day
2 day work = 1wk
1wk work = 2-3wks
1month = 3 months
If only I didn't have to deal with other people that take forever....
That and I feel lately whenever my boss ask me for a "quick" change or feature... I literally have to go "down boy down, stop thinking your in a candy store" like he's a little kid.1 -
- have a look at the project
- brake it down into smaller stories
- estimate the time
- multipy it with 1.5
- add 1-3 days of testing
- add 15% project management
- add a 2 days buffer
= be happy with being done in 2 weeks, present it in 4 -
#noestimates
I fucking hate doing estimates. It stresses me out. I just did it, for a requirement about migration. I'm on my way to a fight now with the PO, because "the estimated time is too long". There was an agreement that deliverables were not to have extensive documentation and unit testing will only cover 30% of each use case (I know, stfu), but that's gone so I have to do the whole thing. I estimated 160 hours coding time, 40% of that for docs and 50 for testing. I'm standing by it.
All that stuff aside, what bothers me the most about estimates is that there's lazy motherfuckers who say shit like "I can have their RESTful ws in 2 days, but I said a month, because fuck it" and generate a win-win situation for them and their company, because the client - practically everytime - will just argue for the task to be completed in barely 10% less of the estimated time, accept the proposal and be happy waiting, the developer will fucking dawdle and the company will be paid for more hours than it deserves. Ugh.
Fuck estimates.2 -
T(x, y)=x*(1+y/100)+√-1
x = hours estimated from Boss. if the boss
y = sum of the features with the following weight:
Multiplatform = 10
Web = 5
social * = 100
blockchain = 100
HTML-email = 10
Every other bullshit bingo term = 20
everything else = 1
Terms that appear multiple times count multiple times.
If the boss didnt give his estimate triple the feature-value and use 100 as x-value3 -
Doesn’t everybody use Fibonacci story dev points to estimate stories?
Doesn’t.. everybody..? 😞
😭😭😭😭😭😭😭6 -
Step 1. Estimate a time based on previous experience working as a professional and qualified developer.
Step 2. Wrong -
First, realize that trying to accurately estimate how much time something is going to take is akin to accurately predicting the future and that people who ask you to do it are stupid. Then realize that sales-oriented deadlines are the source of all that is evil. Then shift away from sales oriented software. Instead focus on selling existing features and new features on the roadmap have no deadlines, they're done when they're done. Then realize almost no workplace will let you truly do that because chasing the sale is all that matters despite the latest buzz word rhetoric. Then estimate enough buffer to give you a reasonable time to complete it without calling your abilities into question. Then finish it faster so you score points with management, but not every time because then they'll begin to expect it. Now you have leveled up in mind games, an unfortunate but necessary tool in the tool belt. Then hate on sales oriented software some more, rinse and repeat.
-
Split everything into small tasks, no longer than two days of work
Use Fibonacci numbers, 1-2-3-5-8-13
A highly effective developer will produce about 80% of a work day. If you think a task is done within a day add 25% and your estimate is ten. Remember that we use Fibonacci and round up to 13.1 -
Joel Spolsky wrote a great article about estimating the time it will take for dev work: https://joelonsoftware.com/2007/10/...1
-
Estimate how long it will take you then double it. After that split the project into milestones and add the days you give a client to accept the milestone. If you have a good client you will get done early and refund them the difference. Otherwise you get paid well for dealing with a dumbass.
-
I'm told when to finish. I flip a coin, if it's heads I honestly tell it's impossible and point out a realistic - unacceptable - deadline. If it's tails I take the blame. It doesn't matter really, we're running more than a year late now and the workforce is a single senior who was given a team of 3 relatively intelligent but already overworked high school students (including me) who try to help as much as we can.
-
Estimations of dev work? I don’t do such stuff. But if you ask: Time it takes normally times a very very big number 😅
-
Break it down into stages- elaborating on requirements, frontend/backend work, testing, etc. Then pull the numbers out of my arse.
-
I let my monkey brain come up with a reasonable estimate after evaluating what is required. Then i just add in some random amount of time (If my estimate is around 3 days i just randomly say it'll take me 3 days, 3 hours, 21 minutes and 50 seconds). It usually cracks up people during meetings and ends up getting me more time because they like to round it up xD3
-
Newton's first law integrated into work estimation:
For every simple task there is a complex solution which devs will choose and it will take an infinite amount of time, unless acted upon by an unbalanced force.
where "unbalanced_force" belongs to the set union of ["managers", "POs"] and "anyone else who doesn't even work on that project".1 -
Depends on the project:
If it’s just me on the project 1.5x actual estimate which is based on whether or not I can figure it out from looking at the code.
If others are on it 3.5x to include things like getting others up to speed, discussions, design talks etc. -
My process for estimating dev work?
3 hours a day of uninterrupted dev time, 4 days a week (~12 hours a week).
So when I say the project will take 24 hours, it is about two weeks worth of work.2 -
I’d like to estimate I’d finish a project about after a week, or two if I’m accounting for major debugging.
-
$estimationTime = Experience::get($work)->timeSpent() || "Sorry, can't tell, will do as fast as I can";2
-
It's something that comes with practice, but in general it's much better to overestimate than underestimate.
- Always take your time. Don't be rushed into plucking a number out of thin air.
- Break the task down into really small, atomic chunks.
- Each of those chunks will take at least twice as long as you think it does - nothing goes to plan 100% the first time!
- Make sure you add contingency at the end. -
I usually try to break down what they are asking for into smaller parts. The tricky part is scoping them without granular details of how it will actually get done and thinking only about complexity. Then add up time and give the total a bucket size. 1-5 hrs 6-15, 16-30, 30+ etc. Turn around time is another matter but that's never predictable. By the time clients approve the quote availability is totally different.
-
Experience, intuition and 50-200% risk premium.
For me it is important to not put too much effort in it, as the developer estimation is usually mangled through sales and management anyway and doesn't have much to do with the final price.
And as nobody really bases internal budget and schedule on it as well, it's kind of pointless in most cases. -
How I estimate work: Deep dive into the existing code, consider refactors and related modifications that may need to be done, look for alternatives, assess the scope, and then add 20% to whatever amount of time I come up with.
How every company I've ever worked for estimates work: "It's just adding a button. My nephew builds websites and he says buttons are easy. We need it in production by tomorrow."1 -
At my current internship it depends on how often the customers mind does change about the design of the moment. Ending up with an average time of "i dont know, lets just do what he asks"
-
1) Guess how many beans (hours) are in the jar (sprint).
2) Pad my estimate with 12 beans.
3) Be high and have to have meetings in which I explain bean counting is not an exact science and insist that meetings about how we count beans will only put us behind further and will never ever make us better bean counters.
or
3b) Be under, have extra time in the sprint, only to have product management fill the jar with more beans until I'm wrong again. -
In the first place I dont do it that often in private projects because the estimation is always wrong.
At work i just think about best and worst case scenario and the average time it could take. If the the worst case scenario is really time intensive and there are a lot of factors that could go wrong in contrast to the best case, I significantly increase the estimated time for the task. Otherwise its 1/6 best case; 1/6 worst case; 4/6 average time2
Top Tags
Weekly Rant
View