This presentation investigates the theoretical foundation of the basic concepts used in software effort estimation, productivity measurement and benchmarking. By elaborating on how similar concepts are defined and used in well-established engineering fields, we aim to shed light on some inconsistent and fallacious use of concepts and units of measure, resulting misconceptions and their consequences in project planning. Particularly, we focus on ‘Work’, ‘Team Power’ and ‘Team Loading’, analyzing the way many studies from the ‘70s on faced such issue. Too often projects fail for being late and not always adding new resources allows respecting established milestones as well as the established quality levels. After setting the theoretical layout, we present the results of an empirical investigation we made using the data in the International Software Benchmarking Standards Group (ISBSG) dataset D&E (Development & Enhancement) v13, using both COSMIC and IFPUG data for Business and Real-Time applications. The results indicate that a considerable number of projects might have been poorly planned and utilized human resources inefficiently, and hence paid much higher costs. Hence, we suggest software companies to revisit the productivity data of the past projects as well as evaluating the new ones by measuring Team Power, Team Loading and comparing to Team Size utilized.

1. The Missing Links in Software Estimation:
Work, Team Loading and Team Power
Luigi Buglione
Engineering.IT (Italy)
luigi.buglione@eng.it
Çiğdem Gencel
Free University of Bozen-Bolzano (Italy)
cigdem.gencel@unibz.it
IWSM -MENSURA,5-7October2016,Berlin

2. 2
Software
Estimation
Problem
Fundamental
Concepts:
• Energy & Work
• Team Loading
• Team Power
Implications to
Understanding
and Theory
Development
Empirical
Investigations
Conclusions

3. Software Effort Estimation – State of the Art
3
Effort
Estimation
Methods
Parametric
Empirically
based
Statistical
Analysis
Theory
based
Non-
parametric
Expert
based
Informal
Analogy
Structured
Analogy
Learning
based
Case
Based
Reasoning
Neural
Networks
Fuzzy
Logic
Composite

4. Concepts Revisited: Energy & Work
• In physics, potential energy is defined as ‘the capacity
of something to do work’
• In SE, it can be defined as the team’s cumulative
intellectual work capacity within a development
environment for developing a piece of software during a
period of time.
4

5. Transformation of Energy
5
• The law of the conservation of energy says:
• Energy can be transformed from one form to another

6. Transformation of Energy in Software Development
6
Team Time Scope Quality
Work Input Work Output
Wastes

7. 7
• Wintput is the ‘work capacity of a software team’ that is
input in a project
• WOutput corresponds to ‘valuable work’ that produces a
piece of software with some characteristics:
• Productivity of software development is denoted as:
!!"#$"# = !(!"#$%&'#()&%*, !"#$%&'()*, !"#$%&')
!"#$%&'()('* (!) =
!!"#$"#
!!"#$%
Concepts Revisited: Efficiency (Productivity)

8. • Any waste in development would decrease productivity.
• Many studies investigated the factors affecting Woutput and
hence Productivity:
• Team factors,
• Process factors
• Project related factors
• …
• This presentation instead focuses on clarification of
concepts and laying the foundations
• In particular we investigated TeamPower and Team
Loading concepts
8
Concepts Revisited: Efficiency (Productivity)

9. In physics, Power (P) is defined as “the rate of doing work (or
similarly, rate which energy is transferred)”.
The term “horsepower”
was introduced by James Watt;
famous for his work on
improving the performance
of steam engines
Concepts Revisited: Power

10. • The power of a system may stay constant or change over
time.
• Therefore, power is usually expressed in three ways:
• Instantaneous Power, which is the power measured at a given
instant in time;
• Peak Power, which corresponds to is the maximum value the
instantaneous power can have over a period of time;
• Average Power, which is the amount of work done divided by the
time interval that it took to do the work.
• One way to calculate this is to find the area under the power versus
time curve (which gives the total work done) and divide by the total
time.
10
Concepts Revisited: Power

11. • In software engineering, we can define ‘TeamPower’ for
expressing the rate of doing work (or rate of transferring
their intellectual energy to produce a piece of software).
• This measure is commonly referred to as Speed or
Speed of Delivery in software engineering!
!"#$%&# !"#$ !"#$% =
!!"#!"#
!"#$
Concepts Revisited: Team Power

12. Concepts Revisited: Team Loading
• On the other hand, WInput is dynamic and changes during
the life cycle depending on:
• the project requirements and constraints,
• how management schedules software engineering tasks and
allocates people to these tasks.
• Hence, there is another important concept:
12
!"#$%&# !"#$ !"#$%&' =
!!"!"#
!"#$

13. Transformation of Energy in Software Development
13
WInput / Time
Wastes
WOutput / Time
Team Loading Team Power

14. Concepts Revisited: Terms & Units
Inconsistencies
• In SE, even though a similar term ‘manpower’ has been used, the
inconsistent and sometimes fallacious use of the term resulted in
consequent misconceptions.
• Norden referred to Team Loading as ‘Manpower loading (man-
months/year)’.
• Putnam refers to the term several times but with inconsistent use of
the term as well as the units of measure (e.g. Manpower (people/
year), Manpower (man-months) and Cumulative effort (total people))
• The ISBSG introduced another measure called ‘Manpower delivery
rate (size/time x max team size)’ which is claimed to provide a
measure of Speed but also including the Team size.
14

16. 16
Team Loading during Development

17. • Brooks stated that estimating techniques fallaciously
confuse work effort with progress by hiding the
assumption that men and months are interchangeable.
• He then explained that this is only possible when a task
can be partitioned among many workers with no
communication among them.
• His hypotheses were brilliant, and therefore have
gained considerable attention by the community.
Core concepts revisited Some Important Misconceptions
Fred Brooks: Adding manpower to a late software project makes it later

18. Fred Brooks: Adding manpower to a late software project makes it later
Team Loading was expressed in a unit of number of
people, referring to the number of people working in the
team.

19. 19Steven KareemJim
AThought Experiment

20. The Relationship between Team Loading,
TeamPower and Productivity 20
Productivity
(Woutput/Winput)
α α
• How is it possible to increase the rate of
work: Avg. Team Power?

21. We investigated the nature of the relationship between Avg Team
Loading and Avg. Team Size using the ISBSG dataset
• We prepared the data for analysis as follows:
ü Data Quality Rating (DQR): A or B Rating
ü Business Applications
ü New Development
ü Recording method: Person-hrs
ü Resource Level: 1
ü Ratio of Project Work Effort to Non-Project Activity: projects that have
90-100%
ü Normalized Work Effort (person-hrs) used
ü The project duration is calculated by subtracting project inactive time
from the total duration (1 month = 120 hrs).
Empirical Investigations – ISBSG dataset

22. 22
Empirical Investigation - COSMIC
• Project sizes: 11-966 CFP (most below 300 CFP)
• Avg. Team Loading for some projects are much
higher than Avg. Team Size
• Avg. Team Loading in some cases below 1 person!

23. 23
Empirical Investigation - IFPUG
• Project sizes: 34-4887 IFPUG FP (most below 2000 FP)
• Avg. Team Loading for some projects are much lower than
Avg. Team Size
• Avg. Team Loading in some cases below 1 person

24. • Consistent use of concepts and terms are very
important in knowledge and theory development in SE
• Benchmark datasets should include both Productivity
and Avg Team Power figures in addition to Avg. Team
Size for better understanding and fair comparisons
• The empirical investigations of this study indicate:
• Some theoretical reasons of high variations in productivity
figures
• Reveal poor planning practices
• Research need for best ways to increase Team Loading (e.g.
overtime/time-shifts by distributing work globally etc. )
Conclusions