21.3 Converting Estimated Effort (Ideal Effort) to Planned Effort


21.3 Converting Estimated Effort (Ideal Effort) to Planned Effort

Effort estimates are usually expressed in "staff months," "staff days," or similar terms. Such effort estimates represent ideal effort, in which each effort month corresponds to one calendar month.

Mike Cohn describes the difference between ideal time and planned time as akin to the difference between the minutes on the game clock vs. the minutes on the wall clock in an American football game (Cohen 2006). A normal game of American football lasts 60 minutes on the game clock. On the wall clock, a game can last anywhere from 2 to 4 hours.

Similarly, a software project planner shouldn't assume that one person can perform one staff month's worth of work in one calendar month's time. The "effort month" might be diluted by vacation, holidays, or training; it might be split across multiple projects; or it might be affected by other factors.

In considering how to convert ideal effort to planned effort, you should consider the following factors:

  • What hours are included in the calibration data you used to create the effort estimate? Do they include management effort, requirements, and test, or just development effort? Do they include overtime? Whatever assumptions were baked into the calibration data will flow into the estimated effort.

  • How many projects will the project's staff be spread across? If a programmer is divided between two projects, it can take two or more calendar months to accomplish one focused project-month of effort.

  • Does your calibration data account for vacation, holidays, sick days, training time, trade show support, customer support, supporting systems that are in production, and so on? If not, you'll need to account for those dilutions in the effort as you convert estimated effort to planned effort.

These factors vary significantly from one organization to the next. If you work in an entrepreneurial organization in which the team can focus on a single project, you might be able to assume 40 to 50 hours per week of focused project time. In the companies I've seen achieve this, team members' internal motivation has been exceptionally strong; team sizes have been small; team members have been young with minimal family obligations; the company has offered significant financial incentives; and the work environment has no red-tape or corporate-overhead activities.

If you work in a large, established organization in which you have frequent corporate-overhead meetings and most people work about 40 hours per week, you might need to assume only 20 to 30 hours of project-focused time, and those hours might be spread across 2 or more projects.

Reports of the average time per day that staff are able to focus on a specific project vary. Capers Jones reports that, on average, technical workers apply about 6 hours of focused project time per day to their assigned projects, or 132 hours per month (Jones 1998). The Cocomo II model assumes 152 hours of focused project time per month (Boehm et al 2000). The specific number of hours varies significantly based on organizational specifics, so once again you should develop data based on your organization's track record if at all possible.

The "Additional Resources" section at the end of this chapter provides pointers to additional information on the planning aspects of this topic.




Software Estimation. Demystifying the Black Art
Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))
ISBN: 0735605351
EAN: 2147483647
Year: 2004
Pages: 212

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net