OK, let the flaming begin! Now keep in mind that research shows that developers estimates are off by 30%. Moral, know your developers!!!
Truism
Guesstimating is a fact of life. So embrace it as a technique and become better at it. The goal is to start providing estimates with all project team members. With that said, guesstimates should be proportionate to the knowledge at hand! For example, if you know the code then you should definitely be able to provide a fairly accurate estimate. If you don't know the code then you're DOA - well at least you can start learning the code by doing the analysis!
Definition
A very rough estimate, based on guesswork.
Allwords.com, Guesstimating
At the initial planning stage the main objective is to get a realistic estimate of the time involved in the project. You must establish this not only to assist higher management with their planning, but also to protect your team from being expected to do the impossible. The most important technique for achieving this is known as: guesstimation.
Guesstimating schedules is notoriously difficult but it is helped by two approaches:
- make your guesstimates of the simple tasks at the bottom of the work break down structure and look for the longest path through the sequence diagram
- use the experience from previous projects to improve your guesstimating skills
The corollary to this is that you should keep records in an easily accessible form of all projects as you do them. Part of your final project review should be to update your personal data base of how long various activities take. Managing this planning phase is vital to your success as a manager.
Skill, Knowledge and Experience
Have you ever wondered why some people can provide estimates for units of work while others can't. Well, it's simple.
People who are skilled and experienced have the knowledge to provide educated guesstimates which are pretty accurate.
The other distinguishing factor is that these individuals ask the right questions.
Remember there's a difference between aggressive and stupid. You can be aggressive if you have committed and skilled team members who are bought in.
Play Fair
You have to allow developers to adjust their guesstimates when details become more concrete.
If you hold developers to their guesstimates then you might as well join the rigidity of function points estimation and wait until next year to get the project launched.
The long-term negative effect is that developers will no longer want to provide guesstimates and ask for the finalized requirements. Been there done that. You won't catch me performing function points analysis as word is bond!
Agile Estimating
Let's assume that software development is the capacity constrained resource in our organization. It often is! Even if it isn't we wouldn't want to waste slack capacity which might otherwise be used to absorb variation elsewhere in our system. When we spend time estimating something, and we use the capacity constrained resources to do the estimating, we effectively lower our capacity. We lower the capacity on an activity which isn't client valued. The customer doesn't care how long your estimate for a task was. Doing the estimate often takes a significant chunk of the time compared to the time it would take to do the work. Doing the estimate even a few days but more likely a few weeks or months and in some cases years before the work is done means anything learned from the estimating process is lost. It gets worse. Often we estimate work which gets cut or doesn't get done at all because the estimate is too large. Calculating a time on task estimate doesn't create customer valued knowledge.
Estimating is on-value added. Estimating is muda!
On the other hand, I thoroughly embrace the idea that we analyze and partition our problem space. In FDD, we analyze the work into a domain model and later partition those into components. We further analyze the work into Features and group them into Feature Sets and Subject Areas. All of this analysis work gives us a work breakdown structure which is entirely value added. All the work done analyzing the Feature Plan is value added. It creates knowledge which is used to deliver the customer valued functionality. We then estimate based on feature velocity. An agile estimating technique that takes almost no effort to calculate. Agile estimating based on analysis minimizes waste of capacity in the capacity constrained knowledge worker resources.
Just one more reason why agile methods deliver better economic returns than traditional software engineering and project management methods.
David J. Anderson, Why Estimates are Muda - March 17, 2005
Food for Thought
Why Software Cost Estimating is Difficult:
- Projects are frequently required to satisfy conflicting goals.
- Estimates are required before the product is well defined.
- Estimates are highly dependent upon software development processes.
- Software development processes are constantly changing.
Moral, staying real and making sure your PM controls the scope!
|
Previous
