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 projectand 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.