Olivier Le Moal - Fotolia

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

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Bottom up or top down -- which work breakdown structure works better in your organization and why?
Breakdown structure is done through a predesigned automated process for each package or big task . Only one qualified worker does the first activity then each other activity is created automatically and when done the next activity is created automatically. All this to the end of the process. Then all these activities are distributed automatically to capable workers to proceed ( worker can be employee or freelancer) . In the same time a flowchart of this workflow is created simultaneously when each activity was created . So big team leader or manager can track and monitor the whole process graphically as per colors. Done activity is blue. Paused is orange. And so on. He can see who is working on each activity , the exact time of production ( starting and finishing time) done automatically. Not by worker. HR manager can then assess all workers knowing who is faster who is doing quality work. ,who needs training , who has to be fired... in case you need more explanations I am always ready
I don't think that the work breakdown can help with requirements gathering. Something else to consider: Exploring Requirements. Fits well both agile and waterfall approaches. https://leanpub.com/exploringrequirementsone
I can see where it would help, but I think it would be more beneficial when thinking about usage scenarios to test.
Nice link, by the way, Albert. Add to my reading list!
@Michael - you're welcome. Gerald Weinberg also had a follow up book: https://leanpub.com/b/requirements
Also in my backlog.
A work breakdown structure (WBS) is a proven technique for identifying tasks needed to accomplish delivering something. The deliverable could be a definition of requirements, design of a product to meet the requirements, creation or acquisition of said product, testing that the product is the right product and that it conforms to the design, supporting the product after implementation, managing relevant processes, and no doubt more.
In my experience with many business analysts, a common initial stumbling block is not having a good handle on what tasks to carry out in order to do effective business analysis.

Despite typical analysis/requirements books and training, analysts often literally don’t know what to do. It’s been a long time since I’ve read Weinberg’s books, and while I’m sure there’s some good stuff in them, I acknowledge that nothing from them stands out to me now; but I’m pretty sure they don’t address what a WBS would be for how to perform business analysis.

A second related stumbling block is accurately estimating time and effort needed to do competent business analysis. A WBS can help with both.
@Robin - maybe, for trivial tasks, like digging a trench, work breakdown may help with "accurate estimation" of time and effort.
But software requirements digging is more like an archeological dig. In other words, any activity where people continuously learn from the ongoing results, make decisions on the go, and need to experiment - any such activity can be time boxed or guesstimated but not estimated accurately.
@Albert, I think you grossly misunderstand how much even very complex work is routinely estimated and accomplished in accordance with those estimates. Yes, venturing in uncharted territory makes some things unknowable, and there are both estimating and management methods to help deal with uncertainty; but much of what’s involved is not unknowable. For example, I doubt anything either of us does approaches NASA’s recent Jupiter probe in complexity or uniqueness, yet it was accomplished largely because of very precise skilled estimates that indeed came true exactly. Let me suggest you look at estimating again from a different perspective and see how many of the claimed reasons for not estimating are rationalizations and self-fulfilling prophecies to excuse poor performance.

@Robin, we're having an interesting debate here, thank you :)

Let me first say that I'm not against estimation and I estimate and plan all the time. I also use the "break down" approach, no problem.

However, let me point out that the Jupiter probe example is
a) survivor fallacy
b) in terms of software ain't that complex.

Regarding "poor performance". SpaceX has stellar performance so far. And yet they follow incremental approach.