Page 137 -

7 - PROJECT COST MANAGEMENT

• Work units. A work unit is a relative measure that is compared to the work needed for similar work
products. Implementation of function points, for example, can be used to determine the relative amount
of work required to implement a software feature, compared to implementing function points for other
similar features. After a team has worked through several iterative cycles together and achieved a
consistent velocity, their work units can be more accurately aligned to units of actual time and effort.
• Story points. Some adaptive methods utilize story points or use case points as a basis of estimation.
A story point is an approximation of the complexity of software functions to be implemented, expressed
in a narrative of user interactions with the system (the user story). Story points are comparisons of the
complexity of a new story to a well-defined base story commonly understood by the team. Story points
are then awarded from a range of values in comparison to the base story. Some teams use a story point
range defined as a modified Fibonacci sequence (i.e., 1, 2, 3, 5, 8, 13, 20, 40, 100) to scale the complexity
of stories. If the base story represents 5 story points, then a 3-point story would take 60% of the base
story’s work to complete. Note that these are relative rather than absolute values, and may differ from
team to team and project to project, limiting their applicability across an organization or across the
software industry.

• Ideal time. This is the time expected for an “ideal” software developer or development team to deliver a
feature or complete a task, without regard to actual time used for distractions, overhead functions, and
lost time for holidays or to recover from disasters such as missing code planned for reuse. Ideal time is
sometimes expressed as full-time equivalent (FTE) days or weeks. Many organizations estimate project
schedules based on 60% to 80% FTE availability of the software developers.

The tools and techniques for estimating project costs in Section 7.2.2 of the PMBOK Guide are applicable
®
to estimating costs of software projects. The following adaptations and extensions (Sections 7.2.2.11 through
7.2.2.15) also apply.

7.2.2.1 Expert Judgment

®
See Section 7.2.2.1 of the PMBOK Guide.

7.2.2.2 Analogous Estimating

A software project team that has worked together to develop software in the past can use their experience to
estimate the number of work units they can deliver in a given amount of time. Some algorithmic approaches use
historical values of productivity to estimate future projects (e.g., function points developed per staff-day). Early
estimates are often based on nominal measures such as simple, average, and difficult complexity.

Software development teams, when using an adaptive approach, develop the ability to estimate their velocity
based on their experience. A team’s velocity (amount of software developed over a given period of time) can be
used to estimate future effort. Velocity becomes a more accurate predictor after a team has completed several
iterations together; it may not be applicable for a team that has not worked together until some performance data
on the current project is collected.

128 ©2013 Project Management Institute. Software Extension to the PMBOK Guide Fifth Edition
®