Sometimes unseen work hides in the form of forgotten features. Sometimes it hides in the form of forgotten tasks. Decomposing a project via an activity-based work breakdown structure (WBS) helps you avoid forgetting tasks. It also helps fine-tune thinking about whether the project you're estimating is bigger or smaller than similar past projects. Comparing the new project to the old project in each WBS category can sharpen your assessment of which parts are bigger and which are smaller.
Table 10-3 shows a generic, activity-based WBS for a small-to-medium-sized software project. The left column lists the category of activities such as Planning, Requirements, Coding, and so on. The other columns list the kinds of work within each categories, such as Creating, Planning, Reviewing, and so on.
Category | Create/Do | Plan | Manage | Review | Rework | Report Defects |
---|---|---|---|---|---|---|
General management | • | • | • | • | ||
Planning | • | • | • | • | ||
Corporate activities (meetings, vacation, holidays, and so on) | • | |||||
Hardware setup/Software setup/Maintenance | • | • | • | • | • | • |
Staff preparation | • | • | • | • | ||
Technical Processes/Practices | • | • | • | • | • | • |
Requirements work | • | • | • | • | • | • |
Coordinate with other projects | • | • | • | • | ||
Change management | • | • | • | • | • | • |
User-interface prototyping | • | • | • | • | • | • |
Architecture work | • | • | • | • | • | • |
Detailed designing | • | • | • | • | • | • |
Coding | • | • | • | • | • | • |
Component acquisition | • | • | • | • | • | • |
Automated build | • | • | • | • | • | • |
Integration | • | • | • | • | • | • |
Manual system tests | • | • | • | • | • | • |
Automated system tests | • | • | • | • | • | • |
Software release (interim, alpha, beta, and final releases) | • | • | • | • | • | • |
Documents (user docs, technical docs) | • | • | • | • | • | • |
To use the generic WBS, you combine the column descriptions with the categories—for example, Create/Do Planning, Manage Planning, Review Planning, Create/Do Requirements Work, Manage Requirements Work, Review Requirements Work, Create/Do Coding, Manage Coding, Review Coding, and so on. The dots in the table represent the most common combinations.
This WBS presents an extensive list of the kinds of activities that you might consider when creating an estimate. You will probably need to extend the list to include at least a few additional entries related to specifics of your organization's software-development approach. You might also decide to exclude some of this WBS's categories, which will be fine as long as that's a conscious decision.
Tip #48 | Use a generic software-project work breakdown structure (WBS) to avoid omitting common activities. |