Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Quick-Kill Project Management


Work Breakdown Structure: 2 Hours

Before working on the features that will be built, the lead should work with the team to come up with a list of estimates for each feature. Many developers have a lot of trouble with estimation. Luckily, there are a few guidelines that can make the estimation process much more straightforward and reliable.

Estimation is important because it requires that the team members think through every aspect of the project. Most programmers recognize the sinking feeling that comes with the realization that a task they'd assumed would be simple turns out to be much more involved. If other team members are depending on that work, it can throw the entire project into disarray. Good estimation practices help the team avoid that sort of all-too-common disaster. Estimating a project requires the team to figure out in advance the steps required to complete it, and to come up with a number of days (or weeks, months, hours, and so on) that each step requires. The only way to find those numbers is to sit down as a team and think through many of the details that would otherwise be left unaddressed until later in the project.

The first step in generating estimates is to break the project down into a list of tasks that will produce the final product. This list is called a "work breakdown structure" (WBS). There are many ways to break a project down into a WBS; the lead developer should gather the team together for a meeting to brainstorm this list of tasks.

A useful rule of thumb is that any project can be broken down into between 10 and 20 tasks. For large projects (for example, a space shuttle), those tasks will be very large ("Test the guidance system"); for small projects (like writing a simple calculator program), the tasks are small ("Build the arithmetic object that adds, multiplies, or divides two numbers"). It should take less than an hour for the team to brainstorm this list of tasks.

Once the team members have agreed on a WBS, they can begin to discuss each task so they can come up with an estimate for each one. At the outset of the project, team members do not have all of the information they need to produce estimates; nevertheless, they need to come up with numbers. To deal with incomplete information, they must make assumptions about the work to be done. By making assumptions, team members can leave placeholders for information that can be added later, to make the estimate more accurate.

Assumptions are an important key to estimation. If two people disagree on how long a task takes, it's likely that the source of their disagreement is that each person made different assumptions about details of the work product or about the strategy for producing it. In other words, any disagreement is generally about what is required to perform the task itself, not about the effort required to complete it. For example, given the same vision and scope document for a tool that sets the computer clock, two different developers might come up with wildly different estimates. But it might turn out that one developer assumed that the implementation would have a simple command-line interface, while the other assumed that there would be a complete UI that had to integrate tightly with the operating system's control panel.

By helping the other programmers discuss these assumptions and come to a temporary resolution about their differences, the lead can help them agree on a single estimate for the task. The lead should bring up each task one by one, and for each task the team should decide how long it will take. Each time they encounter a disagreement, that means that there are missing assumptions. The lead should work with the rest of the team to figure out exactly what those assumptions are. As these are discovered, they should be written down. As the discussion progresses and more assumptions are written, team members learn more about the project—and they will start to make decisions about how the software will be built. This helps the team converge on estimates for each task.

The final WBS should consist of a list of tasks, an estimate for each task, and a list of assumptions for that task. It should take about an hour for the team to come up with the assumptions and estimates for the 10 to 20 tasks in the WBS. The total time for creating the WBS and then doing the estimate will typically be about two hours. That should be sufficient for a basic estimate for a typical five-person project. However, if the project is large, the team may need to divide it into pieces and run the two-hour estimation session for each piece.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.