How to Embed Cloud Cost into Your Definition of Done — And Why the FinOps Foundation Just Made It Urgent
The FinOps Foundation just formally named Shift Left in their 2026 Framework. Here is the practitioner's guide to embedding cloud cost governance into your Definition of Done — from someone doing it inside live client engagements right now.
I am not writing this from the sidelines. Right now, as FinOps & Cloud Cost Optimisation Consultant at Lean Icon Technology, I am implementing this framework with clients — and in active conversation about reshaping how organisations govern technology value from the ground up.
Something significant happened in the FinOps world recently that most delivery managers have not noticed yet.
The FinOps Foundation updated its Framework for 2026 and formally named "Shift Left" as a core capability — embedding financial context earlier in the engineering lifecycle, at the point of design and architecture, before commitments are made.
Pre-deployment architecture costing is now the second most-requested missing tool capability in the entire global FinOps community. Practitioners describe it as the discipline's most important unsolved challenge. And yet the commercial tooling has not caught up.
Which means the solution right now is not a platform. It is a process.
And the most powerful process available to a delivery team for embedding new accountability at the point of creation is one that Agile practitioners have been using for decades: the Definition of Done.
This article is the practitioner's guide to doing it. Not the theory. What I am actually implementing right now — with clients in my FinOps advisory practice and inside live delivery programmes — step by step.
Why this problem exists and why it keeps getting worse
Let me start with an uncomfortable truth.
The reason cloud cost governance fails inside most delivery programmes is not because engineers do not care about cost. It is because the system they work within gives them no reason to care.
Think about the incentive structure of a typical sprint. A developer is measured on features shipped, velocity achieved, bugs resolved and stories closed. Nobody puts "cloud cost of this feature" on the sprint board. Nobody celebrates the engineer whose architecture decision saved £40,000 a year in inference costs. Nobody flags — at the point of coding — that the AI model being called on every user request has a cost structure that will make the feature economically unviable at scale.
The cost conversation happens later. Much later. Usually when someone in finance notices an anomaly on a billing dashboard — or when I am brought in as a FinOps consultant and open IBM Apptio Cloudability or AWS Cost Explorer to find untagged resources, ungoverned AI service subscriptions and spend patterns nobody on the delivery team can explain.
By that point the architectural decision is embedded in production, the team has moved on to the next sprint, and unwinding it costs more than the original saving would have justified.
The FinOps Foundation's 2026 report confirms this pattern is universal. Practitioners report diminishing returns on traditional optimisation — having hit the "big rocks" of waste, they now face smaller opportunities that require more effort to capture. The easy wins are gone. What is left requires catching the problem earlier.
This is precisely what Shift Left means. And it requires a change in process, not just a change in tooling.
What the Definition of Done actually does
I have been writing and refining Definitions of Done since my early days as a Scrum Master — training fifteen project managers a week at The Knowledge Academy, coaching teams at HMRC across the Alcohol Duty Reform and Pensions Administrator programmes, and now as a FinOps and Cloud Cost Optimisation Consultant building governance frameworks for clients using AWS Cost Explorer, tagging strategies and showback/chargeback models.
The most powerful thing a Definition of Done does is not describe what done looks like. It defines what the team is collectively accountable for — at the moment the work is produced, not the moment the bill arrives.
That accountability mechanism is what shift-left cost governance is missing in most organisations. And it is remarkably straightforward to add.
I am not proposing a new framework. I am not asking teams to become financial analysts. I am proposing three additional acceptance criteria — specific, lightweight, and embedded directly into the workflow teams already run every sprint.
The three criteria
In my FinOps advisory work, the average delivery team is using between four and eight AI and cloud services at any given moment — and fewer than half appear on any formal procurement record. Sanctioning the service at the point of the story creates a record, forces a conversation about pricing before it becomes a surprise, and gives the organisation a complete map of its AI and cloud footprint — the prerequisite for everything else in a FinOps programme including tagging governance and spend visibility dashboards.
At HMRC, working across the Pensions Administrator Reform, I introduced quarterly infrastructure costing as part of PI Planning. Before the team committed to a quarter's worth of features, we estimated the infrastructure cost of each one. The same discipline applied at feature level changes the conversation entirely. A product owner choosing between two approaches to an AI feature needs to know the cost difference to make an informed prioritisation decision. Without a cost estimate, they are making an architectural decision in the dark.
The estimate does not need to be right. It needs to be made. The discipline of producing one — even roughly — changes how engineers think about the choices they are making.
On cost ownership by lifecycle stage — the most important and most debated part of this framework:
That last line — no handover, no go-live — is the right line to hold. Without a formal handover, cost ownership evaporates the moment the delivery team moves to the next programme. I have seen this happen in almost every organisation I have worked with. The cost stays. The owner disappears.
The behaviour change problem — and how to solve it
Here is the honest challenge with everything above. Adding three criteria to a Definition of Done takes twenty minutes. Getting engineers to care about them takes months.
"Once you fix it, it's gone — how do we give developers credit for shift-left activities?"
— State of FinOps 2026 Report — named as the discipline's most important unsolved challengeWhen a developer catches a cost problem at the architecture stage, nothing shows up on a billing dashboard. There is no "before" and "after" cloud bill to point at. The saving is real, but invisible. And invisible savings do not get celebrated, rewarded or repeated.
This is not a tooling problem. It is a culture problem. My answer comes from twenty years of Agile coaching — not from a FinOps playbook.
Make it visible. Put cost estimates on the sprint board alongside the burndown chart. Show them in the daily standup. Not as a warning — as information.
Make it celebrated. When a team's cost estimate comes in accurate — or better, when a team catches a cost problem before it ships — name it in the sprint review. Humans repeat behaviour that is recognised.
Make it part of the team's identity. Not a compliance checkbox. A quality criterion. The same cultural shift that turned "we don't ship without tests" into an engineering norm needs to happen for cost awareness.
At The Knowledge Academy I improved candidate pass rates from 80% to 85% not by adding more content but by changing how practitioners thought about delivery accountability. The same principle applies here. The Definition of Done is the mechanism. Culture is the goal.
What the FinOps Foundation's Framework 2026 just confirmed
The FinOps Foundation has now formally named and structured this approach. The 2026 Framework introduces two movements that define mature FinOps:
Shift Left — embedding FinOps earlier in the delivery lifecycle, in design, architecture and procurement, before financial commitments are made.
Shift Up — elevating FinOps to the strategic level through a new formal capability called Executive Strategy Alignment, connecting FinOps directly to executive decision-making.
Both are, at their core, delivery problems — not tooling problems. They require process change, culture change and governance change inside the programmes where technology is being built. That is where delivery managers and FinOps practitioners operate. And that is precisely why the intersection of Agile delivery experience and FinOps discipline is the most valuable combination in the market right now.
Starting this week — three practical steps
The bigger picture
The 2026 State of FinOps report contains one finding I keep returning to. Many FinOps teams are being asked to self-fund AI investments through efficiency gains elsewhere in the technology portfolio. FinOps savings are being used to create the financial headroom for the most strategically important technology investments organisations are making.
That is only possible if the governance is embedded early enough — in the sprint, in the Definition of Done, in the architectural decision — to generate real, attributable savings. Dashboards cannot do this. Culture change can.
In my current FinOps advisory work — building tagging governance frameworks, showback models and spend visibility dashboards for clients using IBM Apptio Cloudability and AWS Cost Explorer — the most consistent finding is this: the organisations that govern cost at the point of creation consistently outperform those that govern it retrospectively. Not by a small margin. By an order of magnitude.
The three criteria in this article are a starting point. They are not the final destination. But they are the lever that shifts cost governance from a finance team activity into an engineering norm.
And engineering norms — once established — compound.
What does your current Definition of Done say about cloud and AI cost? Drop it in the comments — I am building a practitioner resource on shift-left cost governance and real delivery experiences are far more useful than any survey data.
Further reading: State of FinOps 2026 report · FinOps Framework 2026 update · FinOps X 2026 — San Diego, June 8–11
