1 of 20

Is there really a need for an agile program cost estimate?

Arlene Minkiewicz, Richard Mabe - Unison Cost Engineering

11/10/2022

— 1 —

2 of 20

Agenda

Background: What is the Issue
Comparing Program Types and Roles
Summary: Focus on the Role of the Estimator

— 2 —

3 of 20

Background

— 3 —

4 of 20

The Issue

— 4 —

Traditional Software Engineer/Programmer

Defines requirements, then develops, tests and delivers code meeting the requirements
May provide estimates of expected effort, but does not provide detailed budgets and supporting cost estimates

Traditional Cost Estimator/Analyst

Provides PMs with detailed life cycle costs used to develop detailed budgets and affordability assessments
May have learned programming, but is not primarily responsible for developing, testing or delivering code to meet the requirements for software

But, in an agile managed program:

The SW team defines the scope of work to be delivered in each development increment, based on steady-state velocities and known team resource costs
So, is there still a need to have a cost estimate, given the “agile” (flexible) nature of sizing metrics and the always changing scope (dynamics) of what to accomplish in each iteration?

5 of 20

Explanation

Easy to envision a coordinated cost and budget for a Traditional Development program – Hut…2…3…4 march to a schedule; fixed scope by iteration (Frequently adjust cost to account for growth and schedule delays)

Harder to envision – or even estimate – a cost in the Agile (flexible/dynamic) program world - How do you estimate a variable “Hey-Ho-Go-With-The-Flow” dynamic (Regularly adjust scope to meet fixed intervals and budgets)

— 5 —

Are the SW Team size and labor rates all that we need now to determine Cost and Budget?

6 of 20

The Solution

Successful program management still requires working SW capabilities to be delivered on time and within a budget, so yes – a cost estimate is still a good idea for the program manager and program management
The separate roles for the individual SW Teams and Cost Teams in the traditional world help to define their cooperative roles in a highly collaborative Agile Team world

Key SW program characteristics can be applied to an estimate to ensure SW Teams succeed within a defined Budget and Schedule
Similar characteristics ensure the scope of the Budget and Schedule can be validated and maintained with a flexible, responsive (agile) cost estimate

— 6 —

7 of 20

Comparing Program Types and Roles

— 7 —

SW Team, Cost Team

8 of 20

Common Program Characteristics to Consider

The Delivered Product
Size and Complexity of the SW items
Development Approach
Scope and Flexibility of the Development Schedule

— 8 —

9 of 20

Product

Traditional Software Team

Define Complete Product: CPEI and all subcomponents
Based on Standard 881 or Corporate WBS
Team focus is on End Product configuration and quality

Traditional Cost Team

Define Cost WBS: End Item (Product) and Sub-Components
Identify Activities: Design, Develop, Code, Unit Test, System Test, Deliver
Team focus is on predictive estimates of Labor, Materials and ODCs over time (Waterfall, Spirals)

— 9 —

Agile Software Team (Hey-Ho-Go-With-The-Flow)

Describe a roadmap of Minimum Viable Products (MVP)
Develop Capability (MVC) and Feature Stories
Create and maintain a Backlog of User Stories
Decompose User Stories into doable Tasks

Agile Cost Team (Yes … a Cost Team can be Agile)

Provide estimates of increasing fidelity from the overall “Grand” roadmap to the “Granular” Backlog tasks
Collaborate regularly with the SW Team to understand changes at each level (Capability, Feature, Task) as they are identified (costs emerge as changes occur)
Track back to initial “Grand” estimate and provide feedback metrics on changing (dynamic) velocity, defect rates and delivered capability

10 of 20

Size

Traditional Software Team

Estimate size in SLOC, Function Points, etc.
Size is Code based
Generally informed by analogies and experience

Traditional Cost Team

Depends on Software Team for Size Estimate
Develops Cost Estimating Relationships (CERs)

Apply statistical analysis techniques to code-based sizing data
Based on historical data collected from similar systems

— 10 —

Agile Software Team

Assign Tasks to complete based on Story Descriptions and priority
Team collaborates to “size” the effort for Tasks based on Relative Size measures

Story Points, T-Shirt sizes, Fibonacci Series, etc
Size Measures have meaning to the team but are not standard

Agile Cost Team

Collaborate with Software Team to understand their Sizing approach (measures)
And understand Agile Practices employed and Team Skills (velocity, complexity)
Calibrate a velocity consistent with a team’s Size Measure

Normalize velocity based on Language or Code Type
Remain flexible (expect change)

11 of 20

Approach

Traditional Software Team

March to Schedule
Walled off team for Development and Test (throw it over the wall)
Phases are Sequential (Requirements, Design, Implementation, Test)
Prone to Delays, Rework, Design Mods

Traditional Cost Team

Estimate Activities and Resources by Phase
Align Estimates to schedule, apply economics based on schedule (rates, inflation)
“Cost” growth occurs, but generally not a metric impacting the Software Team
Sometimes struggle to sync with the Software Team and with Program Changes

— 11 —

Agile Software Team

Focus on Current Iteration (sprint, release)
Working software delivered regularly as project progresses (CI/CD)
Shorter, faster cycles with automation, concurrent actions, and “real time” feedback
Significant “customer” input and collaboration

Agile Cost Team

Assume SW Team is Still Writing Code and Building a Product, but estimate by task and increment
Hours are driven by skill of the team (velocity)
Estimate/Measure/Adjust – by increment leading to steady-state model
Collaborate real time with SW Team to understand changing scope, velocity and sprint dynamics (cost emerges)

12 of 20

Schedule

Traditional Software Team

Rigid schedule drives development activities
Based on end product requirements
May try to mange with defined Spirals and/or Increments
But schedule growth is always a factor

Traditional Cost Team

Challenge to keep up with Software Team Changes and Mods
Cost/Schedule/Budget Risk high due to

Limited interactions with the Software Team
Lack of Cost Growth Feedback to the Software Team

Cost position with risk goes to the Program Manager, not the Software Team

— 12 —

Agile Software Team

Workload is scaled for the immediate increment
Detailed effort is not considered until work is scheduled (release map is not a schedule)
Progress generally follows the release map, but teams are flexible
But length of releases/sprints generally fixed

Agile Cost Team

Initial Grand Estimate - possible number of Releases and Sprint
Cost Factors/CERs adjusted when forecasting future increments to account for prior increments
Feedback used to manage cost/schedule/budget
Estimator becomes active part of the agile team to monitor/incorporate dynamics of the program

13 of 20

Summary: The Role of the Estimator

— 13 —

In a Highly Collaborative Process

14 of 20

Agile Product

What’s the Same?

A cost WBS needs to be created, but not all at once
A cost WBS emerges from the process

What’s New?

WBS creation requires Cost Team to collaborate with Software Team

To understand the roadmap
To understand the Minimum Viable Product (MVP)/Capabilities (MVC)
To accommodate emergent or changing requirements

Process requires regular interaction and feedback between Cost Team and Software Team

Who Brings what to the Cost Estimation Team?

Cost Team brings knowledge of WBS Creation and estimating process to the table
Software Team brings Product Knowledge and understanding of the agile process to the table

— 14 —

15 of 20

Agile Sizing

What’s the Same?

Cost is still a Function of Effort
Effort is still a Function of Size, Complexity and Capability
Cost Team depends on Software Team for Size Estimate

What’s New?

Cost Team must collaborate closely with Software team to understand their Relative Size Units
Define a velocity required to turn relative size into Tractable Size (Effort Hours per Relative Size Unit)
Account for changes with each sprint/iteration

Who Brings what to the Cost Estimation Team?

Cost Team brings knowledge of calibration and understanding of the importance of Size to the table
Software Team brings relative size measures of backlog tasks and knowledge of velocity to the table

— 15 —

16 of 20

Agile Approach

What’s New?

Cost Team must collaborate with Software Team to facilitate an understanding of near real time changes in

Scope
Velocity
Program Dynamics

Cost factors are not Fixed, rather the Estimate/Measure/Adjust cycle leads to steady state measures

Who Brings What to the Cost Estimation Team?

Cost Team brings the ability to assess how size, complexity and capability leads to a program cost/effort estimate
Software Team brings real time knowledge updates as the requirements emerge and change

— 16 —

What’s the Same?

Cost team recognizes that Code is still developed and a Product will (eventually) be delivered (MVP)
Budget must still represent the full “cost” of the Program (All Releases, MVP)

17 of 20

Agile Schedule

What’s the Same?

There needs to be a schedule for business planning/budgeting

What’s New?

Schedule Not driven by Scope, Scope is allocated by Schedule
Software Team works to deliver features per iteration rather than rushing to meet a proscribed schedule
Cost Team works with Software Team to manage Cost Changes associated with optimizing Scope delivered within a Schedule

Who Brings what to the Cost Estimation Team?

Cost Team validates the Schedule in the Context of Changing Requirements and Costs (does this scope fit in this sprint)
Software Team continuously re-prioritizes features and stories to optimize the Scope delivered within the schedule

— 17 —

18 of 20

Some Final Thoughts

YES - A cost estimate supporting a budget is still a good idea (useful tool for the PM, and for the SW Engineering team)
A cost estimate is more than a resource loaded schedule; also Includes probability of success and viability of a schedule
But:

In a dynamic agile environment, cost needs to be as flexible as the choice of backlog to adequately estimate cost and risk for the PM and SW engineers
Requires a focused estimator; not an extension of SW engineering

So: must be a collaborative effort - cost estimator is part of the agile team, not an isolated effort searching for old input

— 18 —

19 of 20

Questions?�CostEngineeringSupport@unisonglobal.com

— 19 —

20 of 20

Back-up: The Engineering V for Agile

— 20 —