I currently work in a company where the Waterfall model is deeply ingrained. We are pushing Agile principles but it's a long process. Meanwhile, I have to work in a Waterfall world with sequential projects phases.

My question is about the analysis phase. I must provide a list of task and how long they will take. What techniques can I use to improve the accuracy/precision of my estimates, while fulfilling the requirement of having a detailed estimate up front?

One example I know would be to use prototyping to get more knowledge before making the estimate.

  • 6
    +1 for your last statement, in waterfall, prototyping is essential. It's good practice too, think of it less as prototyping the end result and more as "exploring the design space", let yourself try a variety of things just to see how they play together. Be ready to stop any of the concepts you're exploring at any minute and toss it all out as you will find many dead ends when properly exploring a design space. May 15 '13 at 16:55
  • Hide inside a well-padded barrel, like the ones daredevils use to go over Niagara Falls in! :P May 15 '13 at 17:23
  • 5
    So you must work for one of those companies whose customers want to know how much it is going to cost them and what they are going to get up front. Darn those pesky customers that like to be able to make informed decisions BEFORE plunking down cash.
    – Dunk
    May 15 '13 at 17:30
  • I dont think you can I suspect you will end up like the old woman who swallowed a spider. May 15 '13 at 19:28

Gather better, more specific customer requirements.

When you refine the requirements to the point where each requirement can be satisfied with a handful of classes, and you have a pretty good idea what those classes will look like in code, it will become much clearer how long things are going to take, and it will be much easier to declare success on each requirement.

Your requirements should include detailed specifications of all of the interfaces between components, so that it will be clear to each software developer exactly what they need to do, and it will be easier to divvy up the work, or move work from one developer to another.

One thing you might want to push is smaller waterfalls. Breaking up the project into phases will help everyone by providing checkpoints where you can monitor progress and get feedback from stakeholders (much like you would with agile). Agile succeeds where waterfall fails because waterfall often bites off more than you can chew.

  • 1
    I have seen lots of agile projects fail and lots of waterfall projects succeed (and vice versa of course). Waterfall does not alawys fail and doesn't even fail really much more often than agile does (it does fail for different reasons). I can trace pretty much every failure I have ever seen no matter what methodology to bad requirements or inappropriate deadlines (usually based on wishful thinking and bad requirements!)
    – HLGEM
    May 15 '13 at 20:45
  • @HLGEM That's fair enough. Agile was supposed to be the silver bullet for failed waterfall projects, but I suspect that's because Agile gives your greater contact with, and more continuous feedback from, the customer, resulting in better requirements. May 15 '13 at 20:47
  • 1
    Sadly there are many failed agile projects because the reality is the customers often have no idea what they want and the developers don't have the business acumen to help them figure it out. And many so-called "agile" projects really aren't, getting the worst of both worlds.
    – HLGEM
    May 15 '13 at 21:13

In order to get better at providing the list of tasks and the time they will take, you need to practice and record your results. So first make every estimate fairly detailed (don't forget to include communications and meetings, requirements development, designing, tests, qa, deployment, documentation (always needed in waterfall), research and other non-coding tasks. The first thing people do wrong is they estimate only for the actual coding time. You think, "Well that will take me about 2 days so that is the estimate" and 12 hours of meetings later, you haven't even started to develop.

When you give an estimate, store it and the time somewhere and when you do the project, mark down how long each task actually took. Soon you will see a pattern (most people consistently estimate too low). You also will now have the data to say what time things take. It becomes harder to argue with your estimates when they are based on hard numbers of what it took for similar tasks in the past.

In a waterfall project, you can assume there will be last minute changes, so estimate for a percentage of time spent on that too! If a task is new (you have no similar tasks in the history), remember to add a more research and design time because figuring out what to do will probably take the most time.

In a waterfall project, the best thing you can do for yourself and your team is to slip the deadline and increase the estimate every single time they change the requirement after the requirements definition phase. If they get new estmates from you consistently that tell them how much that little change will cost, you will reduce the number of "Oh by the way" changes you get drastically. You need to manage the customer in a large project.

And spend the time up front in requirement development and design. That is the purpose of a waterfall project since it is far cheaper to change things at that point than after you have done the development work. There are types of projects that are more suited to waterfall than agile. So don't automatically think it is bad that you use it. Instead learn to use it well to manage projects. If you learn to manage waterfall well, you are ahead of most devlopers in either waterfall or agile environaments because the truth is most developers are lousy at anything involving management of a project and getting projects ouit the door is the name of the game.

  • +1 Historical metrics are the only way to even begin to give reasonably accurate schedule estimates. This is further compounded because each company is different and even the same developer working at different companies could have vastly different results (timewise) even when building the same exact product. Because processes and other characteristics are different between companies. IOW, your metrics from company A will likely be tossed out the window when you move to your new job at company B. The good news, is that company wide metrics are more consistent than developer specific metrics.
    – Dunk
    May 15 '13 at 21:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.