Estimate of attributes

Establish Estimates of Work Product and Task Attributes

Once you have written the WBS, the next step consists in estimating the effort required to perform the described tasks. This is often done in two steps since it is not easy to determine directly the effort (or the cost) from the task.  The first step aims defining possible measures that will help in performing estimations during the second step. Typical measures often concern size. In the example initiated in a previous post, the major part of the work is to write a specification from a requirement document. The first measure that comes to mind is the number of pages. This is a possible measure but not enough detailed in our case.

Requirement documents are organized in requirements that have to be well defined, with an equivalent granularity level. Moreover, requirements are interesting because they lead the work. Once all requirements are treated , the work is finished. In consequence, requirements will be our main measure unit of the work to do.

Usually, requirements are easily identifiable since they have an ID compliant to a convention. For example requirements ID can be put between brackets, in this case a simple regexp tool can be used to count them (I’m writing a reminder to work on a post concerning requirement analysis).  This measure is a first level of measurement, it may be sufficient in most of the cases, however, the model can be refined by providing additional information like the complexity level of a requirement (simple, medium or complex). This additional information will permit to estimate more accurately the workload required to treat a requirement. A simple requirement will require less effort than a complex.

For other tasks of the WBS, measures have also to be defined. For all activities requiring meetings, the number of meeting is a good measure. Some activities directly linked to the writing can be deduced from the main task. For example, reviewing a document will be directly linked to the size of the document, itself being linked to the number of requirements. Finally, the cost of some tasks is equal whatever the amount of work produced. This is the case for deliveries. For these tasks, measure is not required if you already know the time it takes to deliver a document.

When defining measure, it is important to write not only the result obtained but the definition of the measure. The definition of the measure will be used as the base of the estimation hypothesis (my estimation is based on the number of requirements) and it will permit to analyze and refine estimations for next works. Establishing measures is an activity described in the Measurement and Analysis (MA) process of CMMI for Development.

Here is the result of a WBS sheet with measure definition:

WBS with measures

The second step of the estimation process (using measures to deduce workload) will be treated in a next post.

WBS tools

To create a WBS, it can be interesting to use a Mind mapping software. Mind maps are diagrams used to represent information in a graphical structure called map. Softwares permit to create these diagrams. Several products exist in this category, like (see here for the full list):

• XMind : Based on the Eclipse platform. This is the tool that has been used to produce diagrams of this post.
• FreeMind: One of the first free mind mapping software (written in Java).

Since the WBS is a hierarchical structure, Mind mapping tools permits to represent and to design it efficiently. In consequence, it will be easy to:

• Expand / Collapse level to show hide WBS detail
• Reorder elements of the WBS (if an activity does not belong to a category, it is easy to move it with a Mind mapping software)
• Add new elements, elements are easily inserted, numbering of existing elements is automatically computed
• Add additional informations (notes, flags, etc.), Mind mapping softwares permit to add graphical elements in order to bring visual information.
• Offer a global view of the project
• Export the structure to a spreadsheet application for further use like estimating the WBS
• And many other things, …

The following screen shots show what can be done in XMind with the example of the WBS presented in a previous post. All the views presented below have been created with the same structure, only the visual representation has been switched.

The standard map clockwise view (note: numbering function has been used in order to identify each activity of the WBS), this view is (most of the time) the default view of Mind mapping softwares:

WBS map view

The tree view, this is the standard view to represent a WBS:

WBS Tree structure

The spreadsheet view:

WBS spreadsheet view

And, my favorite (it is the most funny) the fishbone view:

WBS fishbone

WBS

If you have a work to perform the first thing to do is to create a WBS. A WBS (Work Breakdown Structure) is the complex term for the list of tasks to perform in the frame of a project or a mission. For example, if you have to write a software specification based on a Requirement dossier, you have to define the list of tasks to perform in order to do the job.

Well writing this document will first require to read and understand the input document (the Requirement Dossier), this may require to run one or more workshops with customers to ask questions and acquire enough knowledge to be able to start writing the specifications. Once written, you will have to review yourself the document, perform corrections and finally deliverer it. During this work you will probably have to report the progress of your work to the customers and to your boss. In short, a lot of tasks aside the core task of writing the document.

This is the first benefit of using a WBS, it permits to make you think to the tasks you will have to perform. Without doing this inventory prior to the work start, tasks will be identified too late to have the time and the money to perform them properly.

Let’s write in a spreadsheet application the list of tasks to perform this job:

Initial WBS

It is an interesting first step but, mainly two remarks can be made on this initial WBS:

1. It does not define a hierarchical structure, it is hard to identify tasks since they are not categorized. Elements in this structure are called levels.
2. The core task, “write the specification”, is not enough detailed. Performing this task encompasses a lot of activities. But, these activities are not known at this time. In consequence the WBS will be refined later.

Here is the same WBS with the addition of top level categories.

Hirearchical WBS with 2 levels

Besides the ergonomic enhancement, the categorization will permit to obtain, in the next estimation step, a model of this kind of work. It will permit to visualize, for example, the amount of additional workload required to perform the core task of writing a document. After several iterations, it will be the base of a model definition permitting to estimate accurately, from the workload required to write the document, the total workload required to perform the global process (writing the document + additional tasks).  The following pie chart gives an example of this kind of model:

pie chart of the workload by top level category