Stakeholders who are new to agile are expecting thin slices of value per each release, so when we start new projects they are confused when we need large infrastructure costs.

We minimise the infrastructure costs to those enabling that first customer feature, but in some large enterprise projects, the infrastructure costs are significantly larger than the first feature.

enter image description here

Stakeholders will usually go through the same thought process, along the lines of

  • This is not a thin slice, so its not agile.
  • Can we start with the second feature? (nice try)
  • Can you make it smaller? (let's assume we cannot go smaller, for the sake of this question)

I've read about classifying the infrastructure costs as business value rather than customer value, but this question is more related to the initial (large) cost of the business value and how we can describe that.

Is there an industry agile-friendly term to describe this initial cost?

  • How much time/effort in terms of architecture are we talking?
    – Erik
    Commented Sep 15, 2018 at 9:05
  • @Erik it varies, but an example of a ratio feature:infrastructure of 1:4+ Example 15 days for a feature + 60 for infrastructure. Commented Sep 15, 2018 at 9:13
  • 1
    60 days sounds like a lot of time to set up basic architecture. Do you really need all that architecture, just to deliver the first feature? Are you sure you're not just over-engineering?
    – Erik
    Commented Sep 15, 2018 at 9:19
  • 1
    "Value" isn't just customer-facing value. It's value to the project. This whole question is based on a false premise, which is why your stakeholders are confused and need to be educated.
    – Todd A. Jacobs
    Commented Sep 15, 2018 at 14:59
  • @Erik I think you're making some good points, and think you should expand it into an answer. YAGNI and "the last responsible moment" are often conceptual stumbling blocks for organizations that are new to agile. You're definitely on to something by pointing out the risks of over-engineering, especially early in the product lifecycle.
    – Todd A. Jacobs
    Commented Sep 18, 2018 at 0:24

6 Answers 6



Some frameworks have a distinct name for the type of work you're asking about, but some don't. To understand why, a short preface is in order.

Work is work. While it's sometimes necessary to differentiate different types of work for cost-accounting or political reasons, treat this as an opportunity to educate your organization and your stakeholders that there's no such thing as a free lunch. In agile frameworks, all work should be fully visible as a cost to the project.

There may also be a more fundamental concern than differentiating types of work. The scale of upfront architectural and infrastructure work in your diagram suggests that you may be violating a core agile principle:

Simplicity--the art of maximizing the amount of work not done--is essential.

Your team and your organization should certainly evaluate the minimum amount of planning, infrastructure, and engineering (collectively resources) necessary to carry out the near-term increments. In a successful agile implementation, your infrastructure and design will evolve iteratively along with your product.

Don't Overly Constraint Your Definition of "Value"

In general, effective agile implementations don't separate out user-facing value from work that's valuable (and frequently essential) to the process as a whole. The idea that all "value" must be customer-facing value is not correct.

In the most commonly-used user story format, the who in the story is a consumer of value, but that viewpoint character need not be an end user or customer, and the value may be anything that the Product Owner, sponsor, or stakeholders are willing to spend project resources on.

That said, the goal is to avoid "big, upfront design." So, a logical question to ask during each planning session is: What are the mininum resources or architectural/technical choices necessary to deliver a slice of value this iteration?

SAFe, Architectural Runway, and Enablers

SAFe calls this minimum necessary infrastructure the architectural runway.

The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay....Since the development of new features and capabilities consumes the architectural runway, continual investment must be made to extend it by implementing Enablers.

It further explains Enablers this way:

Enablers support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development...Primarily, enablers are used for exploration, evolving the architecture, Compliance, and to improve the infrastructure.

However, this is not permission to dive into big, upfront design and infrastructure investment. SAFe, like most agile frameworks, is based on principles of emergent design and just-in-time architecture, and delays investment in infrastructure until the last responsible moment. This is sometimes referred to as YAGNI.

But Enablers aren't really a special kind of work, even though SAFe insists on giving it a special name.

[Since Enablers] reflect the real work (and sometimes plenty of it), they cannot remain invisible. Rather, they’re treated like all other value-added development activities—subject to estimating, visibility and tracking, Work in Process (WIP) limits, feedback, and presentation of results.

In short, such tasks are value-added work that should be treated just like any other work necessary to develop the increment during an iteration. SAFe spills a lot of ink unpacking this concept, while other frameworks tuck it away in the notion of "vertical slices" or just-in-time resource planning.

  • I would add that it is important to NOT point architectural runway (AR) work. Stories that are value-add get pointed and contribute to velocity. AR is not direct value-add, so it will reduce velocity as it is being implemented.
    – BryanH
    Commented Sep 21, 2018 at 20:12
  • 1
    @BryanH Source, please. Basic agile principles require that all work be visible, estimated, and counted against capacity. It's always possible that some specific framework recommends an anti-pattern like not estimating work of a particular sort, but I'm pretty confident that neither SAFe nor Scrum recommend any such thing.
    – Todd A. Jacobs
    Commented Sep 21, 2018 at 20:26
  • AR work is not value add? This is where Agile descends into nonsense. If your server goes down because you didn't have a load balancer..do you think your platform customers hosting on that server will consider it non-value add? "Well we really wanted to focus on the UI because that is value add..." Commented Sep 23, 2018 at 18:29

There are a few points to consider on this.

1) Scrum uses PBIs. Product Backlog Items are all the things that make up the product backlog. Any item that you have to do can be an item in the product backlog. You can use user stories and spikes, and all kinds of other special techniques in doing your work, but there is nothing that says "Walk the dog" isn't a perfectly valid PBI (or more realistically, deploy "35 application servers").

2) Minimum Viable Product, Minimum Marketable Feature, Prototyping, User Stories, and about a dozen other techniques commonly used in Agile practices encourage you to wrap this work into other work that either produces customer value or creates validated learning. This idea actually comes from Lean and is mostly about eliminating waste. Let's say I want to deploy an robust infrastructure environment with load balancing, mirrored database servers spread out across the country, multiple domain controllers, etc, etc, etc. Now, I'm just starting development and I have a small customer team who uses the application and maybe I need two servers to support that. Well building and maintaining the rest of those servers is just waste, so by only doing the "back-end" work I have to do in order to deliver on the value, then add in the mirroring, load balancing, and the rest of it as I need it.

3) Ironically, only delivering the back-end work you need is sometimes exactly what creates the need for PBIs that read "deploy the other 14 servers". C'est la vie.

4) Please, let's not make up new terms just to sound more agile. I've seen a lot of this over the past decade (I'm looking at you "Technical User Stories"). There are some practices like User Stories and Spikes where you are doing something distinctly different. Those deserve their own term because it helps indicate that you are using that specific technique. If you are doing the exact same thing as you have in the past, feel free to use the same name you always have. It doesn't make you any less agile.


Agile is all about (sometimes brutal) transparency.

If the initial feature release requires a lot of expense and effort then that is what should be reflected.

The release of Customer Facing Feature 1 has involved a lot of time, effort and cost

A good agile organisation will question this. Perhaps they will ask:

  • Is this really the minimum viable release?
  • Is there anything we can do to reduce setup costs (automation, provisioning, cloud computing, etc)

It may be they conclude that it is worth a large investment to create a rapid infrastructure bootstrap process.


Some of that initial infrastructure can be demo'd to customers at sprint reviews to help educate them on why and how it is delivering things that are of value to them. For example, CI/CD:

  • "Look, my tests will run every time I commit/merge something! And if I commit something wrong... (do so)... look, it tells me right away! This buys us both quality and efficiency in developer time. Wooohoo!"

  • "Look, the entire deployment process is automated. With just one command (or whatever), the whole system rolls off the repository and into production. Woohoo! This will let us do releases quickly and cheaply, and save expensive developer time for adding features."

You get the idea. Basically, break that giant initial infrastructure block into small pieces, and show them off as you do each one.

You don't have to (and probably shouldn't) go into technical detail, but bringing the customer "behind the curtain" with your team as you're doing this initial investment work will help them understand going forward that not all work is visible.

Edited to add: I did not answer your question as posed, but the underlying question seems to be "how do I communicate about the initial infrastructure to my customers so that they won't be confused".


It's worth noting that architecture and requirements emerge throughout a project. Emergence of requirements is a focal point of empiricism. Architecture should be negotiated and designed during planning and refinement based upon what you can build this sprint that will provide value to your stakeholders. If you need all of this in order to meet your sprint goal, then that should be conveyed to stakeholders in a transparent manner. Using your product and sprint backlogs to drive the conversation and convey these dependencies is a good place to start as they are clear visualizations of what you need to meet your goal.

To answer your question: those are simply dependencies your team needs to meet their sprint goal, assuming your sprint goal is to be ready for release 1 by the end of the sprint. If your sprint goal is something other than to be ready for release 1, then it's possible the work can be broken up, thus breaking up the need for all those upfront dependencies until they're needed to meet a sprint goal.


The plain answer to your question is: No, there is no scrum term for initial costs. Those costs are table stakes required regardless of methodology.

Some scrum orgs do this work for the customer (the business) in a Sprint Zero, which sets the table for all future work. Size Sprint Zero investments (time/$/people/etc) as you see fit. Work for additional customers, based on Sprint Zero's output, is delivered starting in Sprint 1.

Maybe framing your situation this way would satisfy your stakeholders?

  • Might want to add that "sprint zero" is an agile anti-pattern. It's even on the Scrum exams, and any answer other than "there is no such thing" is considered a wrong answer.
    – Erik
    Commented Sep 21, 2018 at 4:39
  • @Erik it is a Scrum anti-pattern, not necassarily an anti-pattern anywhere else. Commented Sep 23, 2018 at 18:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.