In an earlier article, I described why a WBS is so important. But in order to be a usefull tool, you shall respect some best practices. I will discribe bellow some of those.
- Use a top-dow approach. Begin at the project goal level and
break the work successively to lower levels of definition.
- Create it with the input from domain experts and team
members.
- Do not include any work which is not part of the project.
- Cover the entire scope of the project at least at the upper
level of the WBS (In a iterative development aproach, the WBS is
developed iteratively, thus the entire scope will be only at the end
of the project available). But in early phases, the entire scope of
the project can be covered in the in the high level WBS components.
- Each component of the WBS, excepting the highest one, is a
part of the parent WBS component.
- The lowest level of the WBS shall have the following
properties:
- It is possible to estimate its need for ressources, duration and
costs. Aggregating this information for each lowest level work
package you can calculate the ressources, duration and costs for
the entire project.
- The start and the end of the execution can be clearly defined.
- It's realization can be outsourced. That is true mainly for
work packages to an upper level in a WBS. The outsourcer can
further decompose that work package.
- It has a deliverable or a clear part of it. The deliverable is a prove that the
work package is complete.
- It can be completed within reasonable time limits. There is no universally accepted rule regarding the length of an work package. However, it shall not exceed 1-2 weeks to complete.
- Specific to the software development projects, it can be executed by a single developer.
