The document discusses measuring team performance on software development projects. It notes that projects can vary in people, specifications, languages, complexity and processes, making comparisons difficult. It proposes using size as a normalization factor to measure productivity. Size can be represented by requirements, story points, lines of code and other metrics. Key metrics discussed are duration, effort, productivity and defects. Reducing flow time and batch size are also recommended to improve quality. Normalizing for complexity factors would allow better comparison of team performance across different projects.

1. Measuring Team Performance
Jim Payne
Product Manager, CPM, CSPO

2. The Problem
 Software Development Projects with
Differences
 Different People
 Different Specifications
 Different Languages
 Different Levels of Complexity
 Different Processes
 How Do We Compare Teams?
 How Do We Measure Projects?

3. Lean Software Development
A system of values and principles [1]
 Values
 Accept the human
condition
 Accept that complexity &
uncertainty are natural to
knowledge work
 Work towards a better
Economic Outcome
 While enabling a better
Sociological Outcome
 Seek, embrace & question
ideas from a wide range of
disciplines
 A values-based community
enhances the speed &
depth of positive change
 Principles
 Follow a Systems Thinking
& Design Approach
 Emergent Outcomes can
be Influenced by
Architecting the Context of
a Complex Adaptive
System
 Respect People
 Use the Scientific Method
(to drive improvements)
 Encourage Leadership
 Generate Visibility
 Reduce Flow Time
 Reduce Waste

4. Reduce Flow Time [3]
 Traditional focus is on time spent to
develop
 Evidence suggests that that it might be
more useful to measure the actual
elapsed calendar time, referred to as
Cycle Time
 Longer cycle times correlate with a non-
linear growth in bug rates
 Hence shorter cycle times lead to higher
quality

5. Batch Size
 Traditional Western management
science has taught that efficiency can be
improved by increasing the batch size of
work – "economies of scale"
 Knowledge work problems
 Coordination costs tend to rise non-linearly
with batch size
 Transaction costs can often exhibit a linear
growth

6. Four Core Metrics:
From Project History [3]
 Duration
 Effort
 Productivity (Size / (Effort1/3 * Time4/3))
 Discovered Defects

7. What is Sizing? [3]
 Converting information from system
development and project planning to
calculate an expected system size/scope
 Sizing is not the same as estimating – it is
an input into it
 Sizing is easily the most significant
determinant of effort, cost, and schedule
 Scope-based estimation
 People in Roles – Perform Tasks and Activities –
To Produce Products

8. Size can be represented by
a number of metrics:
 Front end:
 Unit of Need - Based on
characteristics of the
statement of needs
 Requirements
 Function Points/Object Points
 Input/Output (IO) Counts
 States/Events/Actions
 Use Cases
 Stories/Story Points
 Objects/Classes
 Components
 Design Pages
 Web Pages
 Back end:
 Unit of Work - Based on the
characteristics of the system
when built
 Lines of Code
 Statements
 Actions
 Modules
 Subsystems
 GUI Components
 Logic Components
 Logic Gates
 Tables

9. What was the Problem?
 How do we apply this to measuring
teams?
 With a method for sizing projects and
calculating productivity
 A set of normalization factors for
complexity
 We have a method for comparing teams

10. What About Your Metrics?
 What do you measure?
 What would you like to measure?
 What’s your experience?

11. References
 [1] David J. Anderson, (November 2011), Lean Software
Development
http://msdn.microsoft.com/en-us/library/hh533841.aspx
 [2] Michael Mah, Mike Lunt, (August 31, 2008), How Agile
Projects Measure Up, and What This Means to You
https://www.cutter.com/article/how-agile-projects-measure-and-
what-means-you-425606
 [3] Quantitative Software Management, (2014), Software Sizing
and Productivity, http://www.qsm.com/resources/overview
 [4] Gencel, C., Demirors, O., & Yuceer, E. (2005, August 1). A
Case Study on Using Functional Size Measurement Methods
for Real Time Systems. Retrieved November 7, 2015, from
https://www.researchgate.net/publication/258242391_A_Case_
Study_on_Using_Functional_Size_Measurement_Methods_for
_Real_Time_Systems

12. Is This a Subject That Interests
You?
 Jim Payne
 james.m.payne @comcast.net
 linkedin.com/in/jamesmatthewpayne/
 @jamesmpayne