Wideband Delphi

Witten by Kunyi Yang，February 2022

Abstract

The Wideband Delphi estimation method is a technique for estimating workload based on participant consensus. It is based on the Delphi method, famously developed by the RAND Corporation in the 1950s-1960s as a forecasting tool. The classic Delphi method is a method in which companies form a specialized forecasting organization, which includes several experts and corporate forecasting organizers, and follow a prescribed procedure to solicit experts' opinions or judgments about future markets back to back and then make forecasts. In the 1970s, Barry Boehm and John A. Farquhar proposed a broadband variant of the Delphi method. The term "broadband" is used because the broadband Delphi technique involves more interaction and more communication between participants than the Delphi method. It has since been adapted in many industries to estimate a wide range of tasks, from statistical data collection results to sales and marketing forecasts. This paper will describe the main steps of Wideband Delphi and analyze its application in different areas, such as software development projects, presenting the role and advantages it plays in project management. This paper will also give practical examples with diagrams to help understand the process of its use. In addition, the paper will discuss what improvements can be made to Wideband Delphi within the existing framework and how it can be integrated with SCRUM (in Planning Poker).

Big idea

Introduction

Delphi method is a feedback anonymous correspondence method in essence. It originated from the prediction project conducted by Rand Corporation at the request of the US military during the Cold War. It assumes that the judgment of a group is more effective than that of an individual (usually an expert). The general process is to collect, summarize, and make statistics on the problems to be predicted after obtaining the opinions of experts, and then feedback anonymously to the experts. Opinions are solicited again, and then centralized again, and then feedback again until unanimous opinions are reached. Wideband Delphi was first proposed by Barry Boehm and John A. Farquhar in the 1970s and promoted by Boehm in his book Software Engineering Economics (1981).Unlike the traditional Delphi method, it encourages discussion among participants. When Boehm(1981) applied it to cost estimation, he found that facilitating discussion and wider channels of communication could produce more accurate results and contribute to experience sharing and team building. Compared with the Rand Delphi method of narrowband communication, this improved method is called the broadband Delphi method. Recent research in software project evaluation shows that evaluations that benefit from group discussions tend to be more accurate (Hoest & Wohlin 1988; Mol ø kken & J ø rgensen 2004; Cohen, 2005).

The original Wideband Delphi steps were:
1.The Coordinator provides each expert with a specification and an estimate sheet.
2.The coordinator convenes group meetings where experts discuss estimation issues with the coordinator and with each other.
3.Experts fill out forms anonymously.
4.The coordinator prepares and distributes summaries of estimates
5.The coordinator convenes group meetings with a particular focus on getting the experts to discuss points where their estimates vary widely
6.The expert filled out the form anonymously again and repeated steps 4 through 6 as needed.

It was later improved by Neil Potter and Mary Sakry of The Process Group to better embed The project management framework.

Steps of Wideband Delphi

Figure 1: Steps of Wideband Delphi

Planning/Selection

- Selecting qualified teams is an important part of producing accurate estimates.

- Team members must be willing to assess each task honestly and should be willing to work with the rest of the team.

- Have an understanding of the organization's needs and past engineering projects. Knowledge of engineering projects in order to make educated estimates.

- The team should include representatives from all areas of the developer team: managers, developers, designers, architects, QA, analysts, technical writers, contributors, etc

- Facilitators should be familiar with the Delphi process, but should not have anything to do with the Delphi results.

Kickoff Meeting

Provide vision, scope, and other documentation to members.

- The statement of objectives for the estimation meeting should be agreed upon by the project Manager and the facilitator and distributed to the team prior to the meeting.

- It should be no more than a few sentences describing the scope of work to be estimated.

- For example: generate estimates for phase 1 programming and testing of project A.

- Moderator Presides over a meeting

- The conference includes these activities

- The facilitator explains the broadband Delphi method to any new evaluator.

- If any TM has not read the vision and scope and supporting documentation, the facilitator will review it with the team.

The host reviews it with the team.

- The moderator reviews the objectives of the evaluation meeting with the team and checks

The reviewer reviews the goals of the evaluation meeting with the team and checks if TM has the knowledge to contribute.

- Discuss products under development and brainstorm hypotheses.

- Generate a task list of 10-20 main tasks. These tasks

Represents the highest level of the work breakdown structure.

- Agreed units of estimate (days, weeks, pages)

Individual Preparation

After initiating the meeting, the facilitator writes down the assumptions and tasks generated by the team and distributes them. TM independently generates a set of preparation results, including

Figure 2: Example Wideband Delphi estimation form

- Estimates for each task

- Any additional tasks that should be included in WBS

- Tasks the team missed in the launch meeting.

- Any assumptions made by TM when creating the estimate.

- Any work related to project expenses (status meetings, reports, vacations, etc.) should not be taken into account. Should be added to the "Project Overhead Task" section.

- Potential delays should not be considered (e.g., some tasks can't start until after a certain date). Should be added to the "Calendar Wait time" section.

- Every estimate should be based on effort, not calendar time.

Estimation Session

- The moderator collects all estimates. Draw the estimated total on a line on the whiteboard and tabulate it.

- The estimator reads out clarifications and revisions to the list of tasks written on the estimator. Propose new or changed tasks, discovered hypotheses, or questions. No specific estimated time is discussed. - The team resolved problems or disagreements. Since specific estimated times are not discussed, these disagreements are usually about the task itself and are often resolved by adding assumptions.

- Estimators modify their personal estimates by filling in the "Delta "column on the form.

Assemble Tasks

- The project manager works with the facilitator to gather all the results from the individual preparation and estimation meeting.

Figure 3: Typical Delphi task assembly form

- The project manager removes excess content and resolves remaining estimate differences to produce a final to-do list, as well as estimates of effort - assumptions are summarized and added to the list. Update assumptions in Visio files and other files.

- The PM should create spreadsheets listing the final estimates that everyone comes up with. A spreadsheet should indicate best and worst cases,

- Any tasks that differ significantly should be flagged for further discussion. - The final task list should be in the same format as the individual preparation results.

Review Results

- Once the results are ready, the project manager holds a final meeting to review the estimates with the team.

- The objective of the meeting was to determine whether the results of the meeting were sufficient for further planning. The team should determine if the estimate makes sense and if the range is acceptable. They should also check the final to-do list to verify that it is complete.

- There may be one area that needs improvement: - For example, a task may need to be broken down into sub-tasks. In this case, the team might agree to hold another estimation session to break down the tasks into their respective sub-tasks and estimate each sub-task.

- This is also a good way to handle any task where there is a big difference between the best and worst scenarios.

Annotated bibliography

Boehm BW (1981) Software engineering economics. Prentice-Hall, Englewood Cliffs, NJ Farquhar JA (1970) A preliminary inquiry into the software estimation process. The Rand Corporation, Santa Monica, CA, Technical Report RM-6271-PR