This report discusses the tension between organizational need of budgetary data for planned Agile deliverables vs traditional project cost accounting. The report is available for download here: http://ow.ly/XOpSc To access more Trusted Advisor articles, visit: http://www.softwarevalue.com/insights/publications/#trustedadvisor

1. ©2016 DCG Software Value Page 1 of 8 v1
How do I calculate estimates for budget deliverables on Agile projects this year?
January 2016
Scope of this Report
This report discusses the tension between organizational need of budgetary data for planned Agile deliverables
vs traditional project cost accounting. Agile project lean-budgeting best practices at the portfolio level are
highlighted to illuminate the importance of estimating and budgeting as Agile scales in an organization. The
Scaled Agile Framework (SAFe) portfolio and value steam levels, as presented in SAFe 4.0, provide the backdrop
for this discussion.
Budgetary Needs of the Organization at Scale
Small to medium sized businesses with 100 or less developers organized to develop, enhance or maintain a small
group of software products can account for the labor and material needed with straightforward software cost
accounting methods. This is true whether they are using traditional waterfall methods or Agile methods such as
Scrum because, typically, such businesses are small enough to ignore or work around the differences between
the project perspective of waterfall and the product or perspective of Agile.
Larger organizations with hundreds to thousands of developers, organized to develop and maintain a portfolio
of software products, are more challenged in software cost accounting and budgetary planning or estimating
early in the planning cycle for a given year. Estimating and budgeting early presents challenges to Agile
credibility as well as governance.
Software leaders in the trenches deal with day to day change while higher-up executive or management seek
predictability and certainty. This contributes to preliminary rough order of magnitude estimates becoming
memorialized as commitments instead of a work-in-process numbers to drive conversations and decision-
making. This is driven by the financial reporting needs in the executive suite rather than the workflow
optimizing needs of the development activity.
Financial Reporting tensions rise as Agile scales
Public accounting standards guide CPAs and CFOs shaping financial information to quantify business-created
value. That value can be in the form of a hard good, such as a car, or a soft good, such as software or music.
You can consult the Financial Account Standards Board (FASB) repository of standards1
and statements on

2. ©2016 DCG Software Value Page 2 of 8 v1
software cost accounting for the specifics but in general, you can either expense or capitalize your costs when
developing software. Choosing when to do so is left up to the organization (and their reporting needs) as long
as they can defend the decision per the standards and they are below a certain size. Consequently, initial
budgetary estimates are important inputs into the process because they allow for the reporting professionals to
partition or plan the expense vs capitalize decision based on schedule
In the traditional waterfall world of software development, it is conceptually easier to decide when to expense
and when to capitalize as the diagram below illustrates.
Figure 1: Waterfall Project Stages
Software Project Stages
Requirements Design Code Integration Test Maintenance
Expensed Capitalized Expensed
A waterfall software project has a distinct beginning and end with clear ‘phases’ identifying activity versus value
created. Code, integration and test produce actual ‘capital’ value. Requirements, design and maintenance are
‘expenses’ required to produce ‘capital’ value. Also, substantial waterfall projects are longer in term and length
and involve more resources, both labor and material. Longer term this makes it seem “easier” to estimate and
schedule reporting events.
Agile projects, with most using the Scrum method, are inherently different in structure and execution employing
an incremental value creation model as illustrated in Figures 2 and 3 below. This is a cyclical model where short
bursts of activity create immediately available value (shippable product increment). Multiple cycles, iterations
or sprints are crafted together over time to create releases of software product. Estimates can be made as to
how much time will be spent designing, coding, testing, etc, in Agile and the work of people like Even Leybourne
suggests that it is not difficult to deal with the CAPEX/OPEX distinction but auditors like to see timesheet records
to support estimates of the amount of time spent, say, designing versus coding. Splitting time recording like this
for Agile teams within a sprint is hard to the point of being impossible. DCG Clients use approaches similar to
those described by Leybourne to deal with this issue with little friction but only after they have convinced their
auditors.

3. ©2016 DCG Software Value Page 3 of 8 v1
Figure 2: Agile (Scrum) Sprint Cycle
Figure 3: Multiple Sprints to produce a Release
Release
Release
Release
Estimating within an Agile cycle is a real-time small-bore activity focused on small pieces of potential value that
is more often called “planning” in the Agile context. These are not estimates that cover the beginning, middle
and end of an Agile initiative (or project if you prefer that term). These real-time estimates, done with relative
methods and unanchored to any financial or engineering reality are unsuitable for aggregation and turning into
a budget. You cannot aggregate bottom-up estimates to a budget in Agile.

4. ©2016 DCG Software Value Page 4 of 8 v1
However top-down needs persist for Agile budgets and early estimates to support not only prioritization but also
the expense vs capitalize allocation process. As Agile scales, so do the reporting demands. Furthermore these
early estimates or budget must be as reliable and consistent as possible, be based on a repeatable, verifiable
process to increase confidence and accurately represent the value creation activity. If you cannot bottom-up
aggregate Agile estimates, what about top-down?
Epics, Story points and Releases
Epics are the large, high-level stories that can usually be broken down into many smaller stories. Epics drive
Agile development, from the top, to create business value in the form of shippable product. Epics form the
contents of portfolio and product backlogs rather than sprint backlogs and as such they are the level of stories
most familiar to executive and technical leadership. Despite being high-level, they are brief, concise and
unelaborated just like normal stories and, hence, almost impervious to early estimation due to the relative lack
of information.
The Agile method, at the team level, is designed to decompose Epics into smaller units such as user stories.
These user stories are estimated using relative methods such as story point, t-shirt sizing and other techniques.
The Agile team continuously elaborate these user stories, in each sprint or iteration, leveraging end-user
involvement and team dynamics to create incremental value. Discovery of requirements is an intimate process
conducted by the team and not the organization.
At some endpoint in the Agile development a Release is designated ready and complete for shipment to the
marketplace. This all costs money so how does the organization decide to fund one or more Agile teams when
initial Epics are hard to estimate?
Portfolio Level Value Creation and Reporting
The term portfolio is common in financial and investment conversation while programs is a term common in
planning and organization. For example, Federal contractors, building large military systems, use the term
programs to cover the planned series of events, projects and other activities, such as in the F-22 Raptor Stealth
Fighter Program. When the methodologists at Scaled Agile, Inc. (SAI) constructed their Scaled Agile Framework
(SAFe) approach, they recognized that “Program” is a valid term to organize multiple subordinate activities
(within multiple Agile teams) and applied it to their lexicon2
. While there are several different established
approaches to scaling Agile, the SAI methodologists seem to have paid the most attention to high-level budget
challenges so we will spend some time on their approach in the report.
Using “Portfolios” to group multiple Programs seemed a common sense next step because of the financial
implications rising from larger scale activity in an Enterprise. Agile is driven at the team level to produce
software that has value but the Enterprise is driven by financial considerations to fund, extract that value and
report accurately along the way.

5. ©2016 DCG Software Value Page 5 of 8 v1
In the SAFe 4.0 Big Picture3
, which illustrates the SAFe framework, the Portfolio level is well articulated and
includes Strategic Themes and the constructs of Value Streams that are budgeted or funded. Epics are
represented as children of Strategic Themes that guide Value Streams toward the larger aims of the Portfolio.
Consequently early budget estimates, good ones at that, are important to the Enterprise in order to decide on
funding priorities and trigger strategic and tactical initiatives. But if Epics at the top are not suitable for early
estimation and you cannot bottom-up aggregate, how do you estimate or budget at all?
Estimating Early means uncertainty
Let’s assume an existing organization, say a large healthcare insurer, has recently acquired a smaller,
complementary company. Both company’s systems have to work together in the first few years to give the
combined company time to either consolidate, merge or sunset the systems. Both companies employ Agile
methods so it is decided to launch a strategic Agile initiative to create application program interfaces (APIs) that
will make the two systems function as one. This has great value for the organization.
Let’s assume for our example that an integration working group made up of representatives of the two
companies presents a high-level design outlining the, say, thirteen API’s presumed needed. Executive
managements then asks for budget estimates (hardware and software) and a more specific schedule to begin
the approval process.
If the organization, through their annual planning process, has already allocated or budgeted a total overall IT
spend with some software component then the question is how much to set aside for this particular initiative
with little information and lots of uncertainty?
Funding Value Streams not Projects
The 13 APIs, when delivered by the Agile teams, will provide real value to the organization. The total spend to
cover all of the teams for the time period needed will be governed by the organization’s fiduciary authorities.
Depending on the size and scope of the functionality needed, you could conceivable have 13 separate Agile
teams each working on an API. Traditional project cost accounting is challenged by this model.
In the SAFe® 4.0 framework, strategies of Lean-Agile Budgeting5
are described to address these challenges and
the tensions discussed above. The takeaway from the strategies are simple, continue the fiduciary authorities’
traditional role of overall budgeting and spend reporting while empowering the Agile Teams to own content
creation using the organizing construct of one or more Value Streams.
The Agile Teams, and implicitly the Agile method, are trusted to build the right things on a day-to-day, week-to-
week basis within an overall approved budget. The traditional project cost-accounting methods, that seek
command and control assurance, are replaced by a dynamic budgeting5
approach within the Value Stream.

6. ©2016 DCG Software Value Page 6 of 8 v1
Going back to our example, the 13 APIs could have a natural affinity or grouping and drive the association of 3
separate Value Streams as illustrated in Figure 4
Figure 4: Value Stream Example
Each of these Value Streams would be funded from the annual allocated software spend, by the fiduciary
authorities but how big do you make the allocation for API Group 2?
Anchoring reality to functionality
At this point the Integration workgroup has only two choices: Estimate by experience or estimate by
functionality.
Estimating by experience can work if the right set of circumstances occur. The estimators involved are experts in
the proposed work, there is a rich history of prior work where analogy analysis could be made, re-estimation is
done by the same group and the technology is familiar and stable. When these factors do not exist, risk rises as
to the quality and goodness of the estimate and future estimates.
Estimating by functionality means quantifying the proposed work using industry standard sizing methods and
leveraging parametric or model based estimating4
. This approach leverages historical repositories of industry-
similar analogous projects to create estimates that include success vs failure probabilities (risk) profiles. The
organization is borrowing the past experience of others to help them predict their future. When this method is
used it increases confidence because of the statistical and mathematical nature of the process. The process is
suitable for internal adoption as a repeatable and tunable method. Management overhead costs do increase
when this method is adopted.
Whatever method an organization chooses, it should always be considered a starting point and a work-in
process number and not memorialized.

7. ©2016 DCG Software Value Page 7 of 8 v1
Budgeting for Value
The answer to the question, “How do I calculate estimates for Agile budget deliverables this year?” is to define
the value (stream) desired and estimate using your method of choice to define the portion of the overall
software spend required.
As the budget is spent, within this API Group 2 Value Stream’s allocation, multiple deliverables (Releases) would
be created and their individual allocations dynamically adjusted, as needed, by the team as content (Epics and
derived user stories) are elaborated, understood and converted into working software.
Figure 5: Fund Value Streams not Projects or Releases
One or more Releases will be created and shipped supporting the expense or capitalize decision and the
dynamic budget changes within each release activity updates the overall budget, governed by the fiduciary
authorities.
Conclusion
This lean-Agile budgeting approach relieves the organization from using traditional, command and control
project cost accounting methods, which are challenged by the Agile method. This approach allows the fiduciary
authorities to own what they should, the overall software spend, divided by value streams at the same time the
content authorities, the Agile teams, own the day-to-day, week-to-week spending. This is a big step away from
the past for many organizations but a good step forward to a more Agile organization.

8. ©2016 DCG Software Value Page 8 of 8 v1
Sources
1. FASB http://www.fasb.org/summary/stsum86.shtml ;
http://www.gasb.org/cs/ContentServer?c=Document_C&pagename=FASB%2FDocument_C%2FDocume
ntPage&cid=1176156442651;
2. Scaled Agile Framework, http://scaledAgileframework.com/glossary/#P
3. SAFe 4.0 Big Picture, http://scaledAgileframework.com/
4. International Society of Parametric Analysts, Parametric Estimating Handbook,
http://www.galorath.com/images/uploads/ISPA_PEH_4th_ed_Final.pdf
5. SAFe® 4.0 Lean-Agile Budgeting, http://scaledAgileframework.com/budgets/