Food for Thought�An e-newsletter published by Software Quality Consulting, Inc.
September 2007, Vol. 4 No. 7
Estimating and Scheduling for Dummies, Part 1

What topics would you like to see in this newsletter?  Each month, this
newsletter tries to provide you with useful information.  This is a two-way
street and your feedback is important.  Please send your thoughts and comments
to [email protected].

--------------------------------------------------------------------------------

Welcome to Food for Thought(TM), an e-newsletter from Software Quality
Consulting (http://www.swqual.com/index.html?Intro). I've created free
subscriptions for my valued business contacts. If you find this newsletter
informative, I encourage you to continue reading. Feel free to pass this
newsletter along to colleagues by clicking the Forward Email link at the bottom
of this email. If you�ve received this newsletter from a colleague and would
like to subscribe, please click this Enter New Subscription link
(http://www.swqual.com/newsletter/Subscribe.htm?Newsletter). If you don't wish
to receive this newsletter, click the SafeUnSubscribe(TM) link at the bottom of
this newsletter, and you won�t be bothered again.

Your continued feedback on this newsletter is most welcome. Please send 
your comments and suggestions to [email protected].

--------------------------------------------------------------------------------

*** In This Issue ***

In This Months� Topic, I discuss practical techniques to improve 
estimating skills...

Regular features to look for each month are:

- Monthly Morsels
  Hints, tips, techniques and reference info related to this month�s topic 

- Calendar
  Conferences, workshops, and meetings of interest to software engineers, 
  QA engineers and anyone interested in software development 

--------------------------------------------------------------------------------

*** This Month�s Issue ***

Estimating and Scheduling for Dummies
Part I - Estimating 

The For Dummies series started in 1991 with "DOS for Dummies" and quickly 
gained popularity. Now with more than 125,000,000 books in print, the For 
Dummies series caters to everyone�s needs. Some of the bestselling titles 
include "Dating for Dummies", "Shakespeare for Dummies", �Feng Shui For 
Dummies", and yes, �Politics for Dummies� - the book that claims to help 
you sift through all the babble to get to the truth!

If a For Dummies book can help us understand a topic as obscure as 
politics, maybe its time someone wrote a For Dummies book on Estimating 
and Scheduling for Software Projects. Why? Because of all the things we do 
on software projects, by far, estimating and scheduling is the thing we do 
the worst. Every software company has war stories of failures resulting 
from inaccurate estimates and unrealistic schedules. With all of this 
experience to build on, you would think that we would learn from our past 
mistakes. Well, it seems that we haven�t.

The amazing thing about this topic is that it�s not rocket science! People 
have been estimating and scheduling tasks for hundreds, maybe thousands of 
years. Yet, we in the software industry have managed to take something 
that is done well in other industries and screw it up to the point where 
we often just give up in disgust.

Think about this:

- Many estimates for software development projects are derived from 
  hunches, guesswork, and gut instincts.  

- We say things like �that should take about 2 weeks� without any data to 
  support the estimate.  

- We set schedules based on bad estimates without adjusting for past 
  inaccuracies in estimating.  

- We don�t bother to keep track of the actual time it takes to complete a 
  task. Without this key piece of information, our estimates can never 
  improve. 

- Management frequently over-commits and makes unreasonable promises to 
  customers, putting more pressure on the organization to make meaningless 
  estimates and unrealistic schedules. 

This month, we look at ways to improve the accuracy of estimates. Next 
month, we�ll continue this discussion with a look at ways to develop 
realistic schedules.

ESTIMATES, TARGETS, COMMITMENTS, AND SCHEDULES

To begin the discussion on estimating, we need to start with some 
definitions. Steve McConnell says that:

- �A good estimate [...] provides a clear enough view of the project to 
  allow the project leadership to make good decisions about how to control 
  a project in order to hit its targets.� [1] 

If you have good estimates, project managers can make good decisions about 
how to control the project so that you are more likely to meet, or come 
close to meeting, the project�s targets and commitments. (We�ll define 
these new terms in a bit.) Okay, so what is a good estimate?

- An estimate is good if it is within X% of how long it actually takes to 
  do the work. 

You can decide how good the estimate needs to be based on risk to the 
project. Clearly, for some parts of a project, estimates may not need to 
be as �good� as for others.

An important point about estimates that most people don�t understand is 
that:

- Estimates are never negotiable. [1] 

What does this mean? Well, consider this - it takes about 9 months to have 
a baby. This estimate is based on physiological data and a whole bunch of 
personal experience. There�s not much we can do change it. It�s not 
negotiable!

One last point about estimates:

- Good estimates can only come from good requirements ... 

If your projects suffer from poorly written, ambiguous requirements, you 
have no hope of getting better at estimating. Starting with well-written 
requirements is the first step. 

  Read more about writing good requirements...
  (http://www.swqual.com/newsletter/vol3/no3/vol3no3.html)

Steve McConnell [1] defines targets as descriptions of desirable business 
objectives that are determined by making business decisions. Targets are 
internal to the business.

- Unlike estimates, targets are always negotiable. [1] 

Steve McConnell [1] defines commitments as promises to deliver defined 
functionality at a specific level of quality by a specific date. These are 
promises made specifically to customers - be they internal or external.

- Like targets, commitments are always negotiable. [1] 

Steve McConnell [1] defines schedules as a list of a project's terminal 
elements with intended start and finish dates. Terminal elements are items 
that are estimated in terms of resource requirements, budget and duration, 
and are linked by dependencies.

- Like targets and commitments, schedules are always negotiable.[1] 

An important point to remember about schedules: 

- Good schedules can only come from good estimates... 

Learn more about accurate estimating and scheduling techniques...
(http://www.swqual.com/training/yellow.html)

Now that we have defined these terms, let�s discuss some ways to build 
good estimating skills.

BUILDING GOOD ESTIMATING SKILLS

Karl Wiegers said that:

  �There are several ways to become a better estimator. The most basic 
  approach is to record effort, duration or size estimates as well as your 
  estimating processes and assumptions, and then record the actual results 
  from each estimated activity. Comparing actual outcomes to the estimates 
  helps generate more accurate estimates in the future. Estimating 
  procedures and templates that itemize tasks help avoid the common 
  problem of overlooking necessary work.� [2]

Just like anything else, some people are better at estimating than others. 
These folks have mastered a few basic skills that allow them to make good 
estimates. What are these skills? Here are some examples:

- Compare actuals and estimates - 

  The simplest and quickest way to improve your estimating skills is to 
  keep track of the actual time it takes to complete tasks. When a task is 
  completed, compare the actual time with your estimate and reconcile the 
  difference. Ask yourself:

  - Why did it take longer to complete this task? 
  - What did I not know about this task when I made the initial estimate? 

- Use expert judgment - 

  Simply put, this means asking people who have done an activity many 
  times in the past. If you�ve never written a device driver before, you 
  might want to talk to people who have, before committing to an estimate.

- Analogous estimating - 

  Compare the task to be estimated with previously completed tasks of the 
  same or similar type. If you have recently completed a task (say testing 
  a particular part of an application) and someone asks you how long would 
  it take you to test a similar part of another application, you have some 
  analogous experience upon which to base your estimate.

- Parametric estimating - 

  Some tasks are very similar. For these, parametric estimating can be 
  used to estimate the work. Multiply the quantity of work to be performed 
  by your productivity rate.

  For example, if you are developing a bunch of widgets for a GUI and you 
  know from past experience, it takes you x hours to develop a widget, you 
  can use that information to estimate how long it will take to develop 
  all of the widgets.

- Three-Point Estimates - 

  With this method, you create three different estimates � a most likely, 
  optimistic, and pessimistic estimate. Create a final estimate by 
  averaging the three estimates.

  Here�s an example: testing a new build for an application would most 
  likely take you 14 hours. If you don�t find any showstoppers ( 
  optimistic), then testing will take 12 hours. If there are many 
  showstoppers ( pessimistic), testing could take up to 24 hours. So your 
  final estimate is the average of the three or (14+12+24)/3=16.7 hours.

- Consensus-based Estimating - 

  Consensus-based estimating is yet another excellent technique for 
  improving the accuracy of estimates. This technique uses a small group 
  of experienced people to estimate a task that is relatively new. The 
  most popular example of a consensus-based estimating technique is the 
  Wideband Delphi Method. [3] Originally developed by the Rand 
  Corporation, this technique can lead to reasonably good estimates for 
  tasks that are new.

  Here�s how it works:

  - Several experienced people are given the problem statement and 
    separately estimate how long it would take them to complete the task � 
    assuming they could work on the task uninterrupted.

  - When everyone is done, the group comes together with a facilitator and 
    everyone�s estimates are plotted on a simple chart. 

  - The wide variance in the estimates is directly related to differences 
    in assumptions made by each person.

  - The assumptions made by each person are listed and discussed. A list 
    of assumptions is agreed on

  - The same team then goes off on their own for the second round of 
    estimating using the new list of assumptions.

  - The group reconvenes and everyone�s estimates are plotted again. This 
    time it might look like this... 

  - After just two rounds, the estimates start to converge. This process 
    can be repeated until the desired �goodness� (as measured by the 
    variance) of the estimate is achieved. 

SUMMARY 

Bottom line - to get better at estimating, you need to track the actual 
time it takes you to do the work, compare your estimate with the actual 
time and reconcile the difference. Measure the goodness of your estimates 
to see if you are getting better. Remember:

  Good estimates are supported by data not by hunches.
  Good estimates can only come from good requirements.

Only by starting with good estimates can we have a chance at creating 
realistic schedules that we can meet. More on schedules next month...

Till next time...

--------------------------------------------------------------------------------

*** Monthly Morsels ***

Every month in this space you�ll find additional information related to 
this month�s topic.

- References: 

  [1] McConnell, S., Software Estimation � Demystifying the Black Art, 
  Microsoft Press, 2006

  [2] Wiegers, K., �Stop Promising Miracles�, Software Development, Feb 
  2000.

  [3] Boehm, B., Software Engineering Economics, Prentice-Hall, 1981

  [4] Nasir, M.,�A Survey of Software Estimation Techniques and Project 
  Planning Practices,� 7th International Conference on Software 
  Engineering, Artificial Intelligence, Networking, and 
  Parallel/Distributed Computing (http://csdl2.computer.org/persagen/
  DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/snpd-
  sawn/2006/2611/00/2611toc.xml&DOI=10.1109/SNPD-SAWN.2006.11)

- Training in Estimating and Scheduling 

  Building Accurate Schedules from Software Requirements, Boston -Nov 8, 
  2007 (http://www.ieeeboston.org/edu/2007fall/course_building_schedules.htm)

  Software Estimation in Depth, Steve McConnell,
  Oct 1-2, 2007 -Bellevue, WA (http://www.construx.com/Page.aspx?nid=15&id=32)

- On-line Resources: 

  Read more about estimating and scheduling techniques...
  (http://www.swqual.com/newsletter/vol4/no2/vol4no2.html)

  International Function Point Users Group
  (http://www.ifpug.org/)

  COCOMO II
  (http://sunset.usc.edu/research/COCOMOII/)

  Critical Chain Methodology - based on Theory of Constraints
  (http://www.focusedperformance.com/ccfaq.html)

--------------------------------------------------------------------------------

*** Calendar ***

Every month you�ll find news here about local and national events that 
are of interest to the software community...

- Software Quality Calendar 

  There are many organizations that sponsor monthly meetings, workshops, 
  and conferences of interest to software professionals. Find out what�s 
  happening... (http://www.swqual.com/links/upcoming.html)

- Workshops Offered by Software Quality Consulting 

  Software Quality Consulting offers workshops in many topics related to 
  software process improvement. Get more info... (http://www.swqual.com/
  seminars/courses.html)

--------------------------------------------------------------------------------

*** About SQC ***

Software Quality Consulting provides consulting, training, and auditing 
services tailored to meet the specific needs of clients. We help clients 
fine-tune their software development processes and improve the quality of 
their software products. The overall goal is to help clients achieve 
Predictable Software Development(TM) � so that organizations can consistently 
deliver quality software with promised features in the promised timeframe. 

To learn more about how we can help your organization, visit our web site
(http://www.swqual.com/index.html?AboutSQC) or send us an email
([email protected]).

--------------------------------------------------------------------------------

I hope this newsletter has been informative and helpful. Your comments and 
feedback are most welcome. Send me your feedback... ([email protected])

Thanks,

Steve Rakitin
[email protected]

Food for Thought, Predictable Software Development, Act Like a Customer,
and ALAC are trademarks of Software Quality Consulting, Inc.
Copyright 2007. Software Quality Consulting, Inc. All rights reserved.
Graphic design by Sage Studio