Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
In an answer on how to make time estimates it is said to write down all your assumptions you made when estimating a project. Seems like a good plan.
Problem is, by assuming I already made an ass out of myself without realizing it. Assumptions are those evil things that like to stay hidden, things I took for granted.
So when reviewing my estimate, what techniques can I apply to discover the assumptions I based my time estimate on?
A real example: My boss asked me how long it would take me to deploy the software on a new piece of hardware and run through the manual acceptance test procedure. I'd done the test procedure on other systems before, so I knew the whole thing took about 2 hours. I also know that deployment, installation, and configuration takes about 30 minutes. There are other factors, but let's just take these. I could very well say that it will take me 3 hours to do everything that was asked...assuming that the system was on the network. My assumption was that IT had done their configuration of the machine to put it on the network, and I could just log on and deploy the software. If they hadn't, my estimate would be blown already, since I couldn't do anything until that happened.
Assumptions aren't "evil things that like to stay hidden". They are things that you are counting on to have happened that are out of your control. You can present your estimate with these assumptions that these other things have happened, and outline what exactly you assumed would happen.
By enumerating and making your assumptions known, you didn't make an ass out of yourself. In fact, everyone's now on the same page. If you get into the situation and something didn't happen, you can point to the assumptions that you based your estimate on and then reestimate based on your newly found knowledge that the original assumptions were wrong.
You won't be able to account for everything. Some things will be overlooked. The only thing that you can do is keep track, learn from your mistakes, and get better next time. That's why you (especially at a project level) reestimate frequently - NASA's Software Engineering Laboratory estimates once at the start of the project...and then again 5 times throughout the project, revising based on clarifications, information learned, risk analysis, and assumptions made.
Problem is, by assuming I already made an ass out of myself without realizing it. Assumptions are those evil things that like to stay hidden, things I took for granted.
Not true. You need to make assumptions to make any form of estimate, if you knew everything fully beforehand it wouldn't be an estimate. You need to make lots of reasonable assumptions to be an effective programmer.
So when reviewing my estimate, what techniques can I apply to discover the assumptions
I based my time estimate on?
If you made the estimate you should have a good idea of the conditions you need for that estimate to be appropriate. Think through all the dependencies of your project and if they could ever change. For example one assumption could be All my users are using a modern web browser, I don't need to support IE6*. Or My supplier's webservice will have all the order reporting detail i need in one call, I wont need to do any extra data processing
-* That one has got me before. IE6 is widly used in some organisations and its an absolute #### to code for
IE6 is widly used in some organisations and its an absolute #### to code for Please tell me which ones because trying to make a webapp compatible for IE6 as well sometimes takes more man hours than designing and implementing a ballistic missle satellite that can be used to decimate all IE6 using organizations from orbit. It is even further a great idea that you would rid the world of IE6 for good.
The answer did mention
Make them sit down, read, and agree to your assumptions (or, if you're lucky, get them to give in and give you real requirements).
So this isn't something which should just stay in your head, making assumptions should be a process of taking nothing for granted and continually asking for acceptance of the assumptions, in order to see everyone is on the same page.
Only then you can be sure you have a reasonable time estimate.
