Olivier Le Moal - Fotolia

Q
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How can a work breakdown structure help me with requirements?

Using a WBS can help make a big task like requirements easier. Expert Robin Goldsmith explains how developers and testers can make the most of this process.

A work breakdown structure is a list of the tasks or deliverables that, taken together, will produce some desired result. The activity performing the work breakdown structure tasks typically is thought of as a project, and WBS is an essential part of the Project Management Institute's Project Management Body of Knowledge, or PMBOK.  

A work breakdown structure increases chances of project success by identifying work that needs to be done and estimating tasks' effort and intrinsic durations, which then are coupled with extrinsic factors to form a project plan timeline or schedule. A WBS itself does not indicate sequence, dependencies or schedule of performing its tasks; there is no predefined way to organize the work breakdown structure list, although WBS tasks often are arranged to infer task sequence or reflect product structure.

A top-down estimate allocates a single project estimate among its WBS pieces. While some WBSes consist only of a linear list, most are hierarchical. That is, a task or deliverable can be broken into subtasks or subcomponent deliverables. Bottom-up estimates are made for the lowest-level pieces, called work packets, and then rolled up for work groupings and ultimately for the entire project.

Estimates can be based on work packets of any level of detail. Driving down to lower levels of detail tends to increase accuracy by identifying subsidiary work that otherwise often is overlooked. The benefits of such increased accuracy must be balanced against the effort and knowledge needed to drive work breakdown structure tasks to more fully-identified lower levels. A common guideline is that work packets should be work that can be completed under the control of a single resource in no more than 40 or 80 hours ("80-hour rule").   

Next Steps

Taming the requirements beast

Sometimes you do need to start from the bottom

When requirements meet Agile

Dig Deeper on Topics Archive

SearchCloudComputing
SearchAppArchitecture
SearchITOperations
TheServerSide.com
SearchAWS
Close