Has something similar been done before?
How long did the previous examples take?
Why do you think this time will be different?
The last question is not to catch you out. Maybe typical splash pages take people a few days but you're really fast at design, or they needed more polish. If I take a week normally to write a blog post and know that this one is longer than usual, maybe I need to add some time. Perhaps you're adding some copy but this time it doesn't need to go through legal. Whatever the difference is, try and start with previous known data and then adjust from there.
You shouldn't predict it'll only take you a day to get this blog post out if it takes you a week every time and you've got to prepare for a talk at the same time.
More detail and an example from Kahneman:
For example I'm building mobile apps and often the time frame depends highly on the people involved.
Often the problem isn't the implementation, but everything around it.
Getting the right stakeholders, not everyone who things they have something to say need to be heard.
Getting the right requirements.
Getting the info architecture right.
Getting the design right.
All this can take months.
Then there are things, that sound similar but are completely different.
Getting 30 screens done sounds like a repetition of 30 times, but some of them are simply messages or splash screens and some have crazy interactions with SVG, or API integrations or whatnot.
The last 2 apps I built were completly different.
One was a video/audio streaming app, with some micro blogging service attached.
One had a PDF editor and encrypted data storage.
So I gave that a go, I'd do my estimates in one column then multiply them by 3 in the next column. At first I thought that those x3 estimates were way too high but 90% of the time they were about right, maybe a little over but it's usually better to be over than under.
After a while I just started landing on those x3 estimates without it being an extra step, I've been not bad on the estimation side of things since doing that little trick.
I just think: based on what I know now, how long would it probably take to write it - optimistic -?
Multiplying this by 3 is justified by the unknown unknows, bugfixing, communication, changing scope and assuming stuff is more simple than it actually is.
Works like a charm for me in most cases.
For problems where the solution is still unknown, I tend to break it up in small cycles, with a best-case estimate. At the end of every cycle we adjust and align, so that the customer can decide for himself whether to proceed, restart or abort.
Why Asking Developers for Time Estimates in Software Projects Is a Terrible Idea and How to Bypass It With Scrum: http://www.romenrg.com/blog/2015/09/28/why-asking-developers...
That might be the problem.
A common scenario I've been through more than once is someone asks me for an estimate for some project idea they have. I ponder it for 30-60 seconds and say 6-8 month. They reply can you break that down. So I start breaking it down and breaking it down and then add up all the little pieces and end up at only 3-4 month. Project manager writes down 3-4 months and tell us to get to work. 6-8 month later we deliver and get yelled at for being late.
Not a chicken -> egg -> not a chicken -> egg -> chicken!
We have a few such cases without needing to use time travel. We often refer to them as ring species, but a single ring species would become multiple species if you had one or two areas of the ring wiped out (based on if it is really an unbroken ring or an arc). That the death of one group of animals turns two other groups of animals from being one species into two shows the underlying problem with our classification system.
My original statement was simplified, maybe "evolution in conjunction with how mankind classifies species" would be more in line with the point I was making. My reasoning behind this is the following: As far as I know, the most accurate way of comparing species is by comparing genetic structure. And the point at which these genetic changes typically happen (maybe there are exceptions) is at reproduction (that's the evolution aspect of my point). This would also be the "earliest" point we could spot a difference.
> "Estimation is neither good or bad. If you can work effectively without estimation, then go ahead and do without it. If you think you need some estimates, then make sure you understand their role in decision making. If they are going to affect significant decisions then go ahead and make the best estimates you can. Above all be wary of anyone who tells you they are always needed, or never needed. Any arguments about use of estimation always defer to the agile principle that you should decide what are the right techniques for your particular context."
My best short advice would be: always try to make an as detailed as possible list of tasks and estimate them independently - this way it is harder to forget about some details and when you estimate the tasks independently you sometimes over-estimate sometimes under-estimate and the errors compensate each other.
Not in my experience. Under-estimate errors are basically always much smaller than over-estimate errors. Unknown factors that can dramatically speed up a projects are much fewer than unknown factors that can dramatically slow down a project.
I mean if nothing else a 4 week task can, at best, be delivered 4 weeks early, but there is no upper limit to how late it can be.
We discovered that for estimates to be accurate overall, most tasks need to be finished early. It's counterintuitive, but it's directly the result of that asymmetric distribution.
In fact, he showed that even breaking down things into tiny details is not much help without historical data to base estimates on, or maybe I'm misremembering.
I'd get good at estimating in a hurry if you flipped the locus of control. Make management generate importance points, give me freedom to choose projects given importance points, and make importance points per engineer-week a Key Performance Indicator.
Of course, I also let product managers know that any change will affect the deadline, and almost never in a good way. I do this every time they have another "really simple idea".
I like to present my estimates using the cone of uncertainty, which demonstrates their fallibility well.
(See also: using Fibonacci numbers for story points.)
Eg. 2 minutes becomes 4 hours. 10 days becomes 20 weeks. 6 months becomes 12 years.
1) At least, once it comes to providing estimates outside of the assignment/team/project and its own internal thinking.