TLDR
Architecture needs consistently lose to features in planning because they show up without a price. Architecture Pricing is a model that converts these needs into the same unit in four steps:
- Detect (Product)
- Locate (Engineering)
- Price (Product and Engineering)
- Decide (Product)
In an example from a system that I owned, the fix would have paid for itself in about three weeks. Instead, we spent 7.5 person-sprints avoiding the problem.
The Fix That Never Won
In a system I owned, I noticed a concerning pattern in our sprint planning and implementation. Over 12 weeks, one in every four story points went towrads a recurring type of business request. At the peak, those requests took up more than half of a single sprint.
The good news: the engineering team quickly proposed and planned a fix. The bad news: that fix lost to feature work in every single sprint. The result: we spent 7.5 person-sprints avoiding a 2 person-sprint fix... nearly four times the cost.
Why was that fix losing in every sprint? Features came into planning with a value story, while the fix, similar to most architecture needs, came in without one. Architecture cost isn't invisible. It's unpriced.
So, how do we price architecture?
What is Architecture Pricing?
Architecture Pricing is a model for translating architecture needs into the same planning units used to prioritize feature work. It connects symptoms to architecture concepts, then uses the resulting cost of delay to make architecture comparable to features in the existing prioritization processes. This model includes four distinct steps:
- Detect (Product)
- Locate (Engineering)
- Price (Product and Engineering)
- Decide (Product)
Now, the economics behind the price, cost of delay, come from Reinertsen. What I've added is the translation layer: the questions, the concepts, and the inputs that turn an architecture need into a shared language that can be compared to feature work. This model can be used to convert architectural needs into other base units including dollar value (once leadership needs them). In this article, I price in person-sprints: one engineer for one sprint.
This model is meant for the people with boots on the ground; to be used in planning calls, sprint ceremonies, and used between the product and engineering teams in their day to day.
Now that we have an overall understanding of what architecture pricing is, let's take a deep dive into the four steps.
Four Steps
Detect (Product)
This is where architecture cost first shows up; these needs show up as patterns: the same kind of request taking over a sprint, a feature that needs multiple teams to sign off on, an incident that keeps coming back no matter what.
The best thing you can do to unveil these patterns is to ask the right question in your existing meetings and ceremonies. These kinds of questions ask about outcomes, not the implementation. For example:
- "Whose backlog does this fall into, and who else has to be involved before it is shipped?"
- "If two systems disagree about this number, which one needs to win?"
- "When this fails, what does the customer experience? How much of that can we tolerate?"
- "What's the biggest volume we might see in the next two quarters, and how much notice will we get?"
These questions aren't asking how something should be built. They ask who owns it, what's true, what breaks, and what's coming down the pipeline. You don't need to know architecture to ask the right questions. Detect isn't coming up with a solution; Detect is there to name the symptoms early on. In my story, the first question names it exactly: every one of those requests came from the business but couldn't ship without engineering.
Locate (Engineering)
Once a question surfaces a symptom, engineering takes it from there. Locate is where the development team points that symptom at a specific architecture concept, and the concept tells you what needs to follow.
Each question maps to a well-established architecture concept:
- Whose backlog → bounded context and coupling (Evans, DDD; Newman, Building Microservices; Skelton and Pais, Team Topologies). A bounded context is a boundary within which one model and its language stay consistent, ideally owned by one team. Coupling is how much changing one part forces change in another.
- Which system wins → system of record (Kleppmann, DDIA). One authoritative home for each piece of data. Everything else is derived from it.
- What the customer experiences on failure → failure design (Nygard, Release It!; Google SRE). Decide in advance how failure behaves: timeouts, circuit breakers, and bulkheads keep a failure from spreading. An error budget states how much unreliability the business can accept.
- Biggest volume and notice → load parameters (Kleppmann, DDIA). Name the specific numbers that describe your load, such as requests per second, read/write ratio, or records per day. You can't design for scale until you've named the numbers that matter most.
Now, most proposals stop at this step. Engineers come into planning with the gap and the solution, but nothing that enables a comparison to features that arrived with an associated value. This is exactly where my team got stuck. In the example, Locate was easy: one team owned the content and another owned implementation; that connects very clearly to coupling. The fix was clear but the price wasn't. Each concept points to the input you'll use to price it, which is where we go next.
Price (Product and Engineering)
Price is where product and engineering turn the specific architecture need into numbers both can understand (in this case, person-sprints). This step is done in tandem because product knows the value and the core context from the business; while engineering knows the effort and how long a fix takes. This price can't be decided alone.
Four Inputs
Band-aid Spend
This is the capacity used to maintain the current design without improving it. This extends the concept of toil (Google SRE) meaning work with no lasting value. Not only can we view this cost, but we can also look at features that have been displaced by this spend as blocked value. This can be listed beside the price, but not added in. We can measure this by looking back 3-6 sprints and count the points spent on the recurring work.
If we look back at our story, we were spending 1 in 4 points on a team of five; this converts into 1.25 person-sprints per sprint or roughly one full engineer spent on this single task every sprint.
Risk Exposure
Risk exposure is the likelihood of a failure times the impact it would have. This concepts is also called expected-loss (Hubbard, How to Measure Anything). To incorporate this, you put a named value (high, medium, low) based on the context of the impacted system. Back to our example, every handoff between the two teams was a chance for the content to ship wrong. Along with that, important content was delayed by the engineering team as well.
Deferred Upside
This is the value the proposed fix would deliver each sprint once it is live minus the build cost of fix. This is the value side of cost of delay (Reinertsen, The Principles of Product Development Flow). For our example, the business could make its own changes immediately instead of waiting for a sprint.
For deferred upside, we do not count the freed engineering time here since that is already counted in band-aid spend.
Decision Buffer vs. Change Lead Time
Finally, we we take into account how much notice you have on an issue, compared with how long the fix takes. If the fix takes longer than the notice, that is a scheduled crisis. Logistics calls this the lead-time gap (Christopher, Logistics and Supply Chain Management). For us, while we were not scheduling a crisis with this architecture need, we were delaying the work that would have prepared us for the next spike in volume (but that's a story for another time).
What we can do now is look back at our architecture concepts and connect it to an input:
| Concept | What it cost you | Primary input |
|---|---|---|
| Bounded context and coupling | Capacity spent working around the issue | Band-aid spend |
| System of record | The chance and impact of acting on the wrong data | Risk exposure |
| Failure design | The chance and impact of a failure the customer experiences | Risk exposure |
| Load parameters | Whether you can implement a fix before the volume arrives | Decision buffer vs. change lead time |
These inputs give the product and engineering teams the evidence needed to estimate the cost of delaying an architecture need. The output is expressed in the unit the team already uses to prioritize work, allowing the architecture need to live on the same playing field as the other items on the board.
Outputs
Cost of Delay with Trends
Within our example, about 1.25 person-sprints were being lost for every sprint the fix was delayed. This was also trending up, not only did our peak sprint lose more than half of its capacity, the business directly told us the volume of these changes would continue to increase. When it comes to urgency profiles, a flat cost can wait but a rising one can't (Arnold).
Payback Period
2 person-sprints (cost of the fix) / 1.25 person-sprints (saved per sprint) ≈ 1.6 sprints. That gives a clear answer to the priority of this item: in 3 weeks, this fix would pay for itself.
Urgency Flagging
This flag should be triggered when the change lead time is longer than the notice you receive. In this example, the flag stays off.
Finally, we get to make the decision on this work effort.
Decide (Product)
Once we have a priced architecture need, we place this within our existing processes and ceremonies to be prioritized with other items within a sprint.
At the capacity level, this can be shown as a trade: "Two sprints of one engineer's time, to get roughly one engineer back every sprint following". When several priced items compete, cost of delay / duration orders them (Reinertsen). If our example was priced this way from the start, the decision is easy: the fix pays for itself in about three weeks and continuously pays us back from that point on. A real price also includes the risk the fix would create. Self-service without an approval step would mean shipping mistakes, but faster. In our case, the decision should include an approval step.
Choosing not to fix is still a valid decision within this model; if the cost of delay is flat and payback and the payback is long, deferring to other user stories is a good choice. But, the architecture need is still priced and ready for the upcoming sprints.
Start Monday
If you want to implement this model into your team, here are the steps to follow:
- Pick one pain point the team has already noticed or complains about.
- Pull its band-aid spend from your last 3-6 sprints
- Ask the four questions in your next grooming session (or asynchronously)
- Price it in your team's units and put it next to a feature
- Make the decision, write it down, and revisit it.
You can also start rough (high, medium, low values), move to capacity once you have sprint data and metrics, and move to dollars only when leadership needs it.
Architecture pricing creates a playing field where everyone in the room can read the price, meaning architecture stops losing by default. If you take away one thing from this article, it should be this: architecture cost isn't invisible. It's unpriced. And now, you can price it.