Get to the Forefront of
Agile Innovation

As part of our commitment to excellence and innovation, we’re inviting you to join our exclusive 365-day free beta program. This is a unique opportunity to experience firsthand the transformative impact scagile can have on your agile project management processes, at no cost.

Agile Transformation: Goals & Metrics

According to a survey of Deloitte 76% of the respondents say, that agile transformation goals are not measured or made transparent in their organization.

Knowing that not-existing goals and metrics are one of the main reasons for failure of agile transformations, this number seems fatal.

But which goals should organizations define for their agile transformation – and more important: how to measure them?

With this article we want to help you defining your own goals and finding suitable KPI’s.

Agile Transformation Goals Metrics & KPIs | scagile Blog

Contents of this article:

Why are agile Transformation goals so important?

Agile transformations are not usually undertaken for no reason, although unfortunately there are always exceptions. However, the reasons are not always a “burning platform”, i.e., the imminent ruin of the company, to put it in its most dramatic form

Failure means the range from not achieving primary goals to making the situation worse. 

Often, however, it is simply that things have not gotten much better overall. 

In one of my agile coaching projects, I was expected to achieve a fifteen percent improvement, meaning cost savings. I replied that you don’t start an agile transformation for that reason, as just reducing some overhead would be enough Similarly, the effort required for an agile transformation was underestimated and the context of such a transformation was misunderstood.   

And this brings us to the first “agile transformation fail”: 

No clear and reasonable goals.

Agile Transformation Goals Meme | scagile Blog

But in all seriousness, there are two goals that should be formulated for an agile transformation.   

One goal is related to the Business Outcome (NOT output), while the second should be related to the transformation itself.   

Because you cannot say that with the achievement of the first goal, the second is automatically achieved (and vice versa). The second goal is about the sustainability of a completed cultural change, which should ensure a good business outcome in the long run.

In many organizations that have gone into an agile transformation, the goals were often not clearly defined or very often referred only to the output.

The goal statement “we want to improve our delivery capability” is a nice touch, but still far from defining a clear objective.

The output-related objectiveswe would like to deliver our products faster and produce them at a lower cost” also sound very obvious, but they are again still a long way from a clear definition of the objectives of an agile transformation

They express that an agile transformation’s impact on an organization’s entire culture is significantly underestimated. 

The consequence of this is that agile transformation falls far short and is exhausted in the reorganization of work processes, i.e., it ends where it should begin. 

Goals provide clear orientation so that a temporary improvement in output – due to the weather, for example – is not confused with the achievement of transformation goals.   

It is much better to have an ambitious goal and not (quite) achieve it than to do without clear goals and then gloss over even the slightest progress.

Clear goals are unfortunately often confused with classic project management, and it is made to seem that agile cannot or should not make any clear and binding statements at all. Even the introduction of “Agile Transformation Goals” and, consequently, the follow-up of the goals with the definition of an “Agile Transformation Metric” or at least the definition of KPIs for the agile transformation is often disliked and perceived as detrimental to the transformation. This is wrong and probably still stems from the fact that an agile transformation is seen as a grassroots bottom-up evolutionary process. Therefore, agile transformations today are strategically planned and managed top-down.

Agile means proactively adaptive

and thus, on the one hand, the scope of the statements is limited (adaptive) and the possibility is included to regularly review the statements (proactive) and to justifiably (!) adapt them to reality.

“Justified” means that this is not done arbitrarily, but that the environment is already observed very closely, and causes are analyzed. Yes, the potential to lie to oneself in the process cannot be denied. Therefore, it is even more important to have goals and, if possible, to substantiate them with clear and quantifiable KPIs

Not having such goals is equivalent to losing orientation and context.

Organizations then find it difficult to identify where and how they can improve or whether they are on a good path at all. 

The definition of “agile transformation goals” is, therefore, a basic prerequisite for gaining clarity in the organization about what the not-insignificant efforts and costs of an agile transformation should lead to. And of course, the transformation goals also include the setting up of “agile transformation metrics” in order to be able to track the degree to which the goals have been achieved.   

So, now to the two goals themselves. 

Business Outcome Goals

Business outcome goals as opposed to output goals are more strategic and target the company culture.

Or they directly target the generation of business value, which is not so different, because an agile corporate culture should focus exactly on “Business Agility” and “Customer Centricity”.   

Yes, you read correctly, business outcome is a result of a certain corporate culture and not a goal to be achieved somehow, by whatever means. Because a constant and sustainable flow of value can only be achieved if the entire corporate culture is aligned with it. This cannot be delegated to individual departments or to isolated agile teams. A look below at goals for business outcome and their KPIs illustrates this and gives an idea of how complex increasing business outcome can become. 

Examples of business outcome goals:

  • How do we measure customer satisfaction? KPIs for this would be for example 
    1. Customer Satisfaction Score 
    2. Customer Effort Score  
    3. Net Promoter Score 
  • How do we organize permanent customer feedback? 
  • How do we let all parts of the company participate in all this, etc.? 
  • How do we shorten feedback loops between end customers and implementation teams? 
  • We want to implement or improve exactly those features that are most desired or used by customers. KPIs for this would be for example: 
    1. Applicability: Feature X is used by more than Y% of users. 
    2. Utilization: Usage of features per day/week/month 
  • How do we establish a BizDevOps(Sec) culture? 
  • How do we organize agile demand management?  
  • Do we use prioritization methods, such as WSJF (weighted shortest job first) at all program levels?  
  • KPI’s that support time-to-market would be for example: 
    1. Deployment scope and frequency  
    2. Trend of technical Dept  
    3. Cumulative Flow Diagram (CFD)  
    4. Lead Time – the time from definition to delivery of a feature 

It is not at all easy to define suitable KPIs for such strategic business outcome goals. And, of course, the goals must be adjusted or redefined sometimes, e.g., set a focus every business year.  

But imagine if such goals were not even defined in the context of an agile transformation. In SAFe – jargon, you could then say:

"Without such goals, the ART's of today, become the silos of tomorrow."

Or rather, the agile organization degrades itself to a pure output-driven feature factory. 

Prioritization using the WSJF technique [+ Excel Template]

With the WSJF technique, prioritization and PI Plannings become damn easy, highly effective and even fun! Step-by-step guide and free WSJF Excel template

Goals of the agile transformation itself

Goals for the agile transformation itself should ensure that the whole endeavor is sustainable.   

Agile transformations take time, often years. Over time, there is a significant risk of losing focus. Again, clear goals along a defined Roadmap provide the necessary guidance.

If the business outcome does not really want to materialize, then a look at the goals of the agile transformation itself often helps to recognize what may be going wrong. 

Defining goals for an agile transformation is quite simple but expressing them in KPIs and then measuring them is extraordinarily complex. 

This is one of the reasons why many organizations refrain from doing so. Nevertheless, it is worth the effort, or rather, without such goals, agile transformation – if only because of their duration – often drifts into a certain arbitrariness after a few months and gets stuck on a formal level – namely the establishment of roles, events, and artifacts 

Examples of agile transformation goals:

For this, we have described 7 factors (vision, domain knowledge, cross-functionality, hard skills, soft skills, empowerment, acceptance). Article coming soon.

KPI for this would be for example:

  • At a team level, sprint accuracy should be >90%. 
  • At a (SAFe) ART level, PI Objective Accuracy should be >80%. 

A hot topic 

  • How many business-relevant decisions are made e.g., in ART (SAFe) itself? 
  • How many hierarchy levels/instances are involved in the decision/approval process?

KPIs for this would be for example: 

  • Frequency of retrospective or inspect and adapt sessions on a team or (SAFe) ART level. 
  • How many of the action items defined there are implemented? 
  • Do you regularly make time for improvements to the infrastructure, architecture, or product in general? 
  • Ration from improvement enabler to business feature. 
  • Do you have an Innovation and Planning Sprint in each iteration? 

KPIs for this goal would be, for example: 

  • Frequency of scope changes during an iteration 
  • How often do iteration goals become obsolete during an iteration (e.g., sprint)? 
  • Sprint Accuracy should be >90%. 
  • Employee turnover should be <5%. 

So Agile Transformation has its own challenges, in addition to what it is supposed to do: Supporting the business outcome goals. Nevertheless, Agile Transformation remains the tool and is not itself the purpose. Only the pairing of the business goals with the possibilities of the Agile Transformation tool, which requires proper handling, brings the company to its goal. Since mastering this tool or craft is anything but trivial, we have dedicated another article to this topic.


Goals are not meant to increase pressure but to give context and create orientation.   

Especially in agile transformations, which can take quite a long time as a cultural change, we need a continuous learning culture and it is good for it to be oriented towards clear goals with quantifiable KPIs. The introduction of “agile transformation goals” and the provision of an “agile transformation metricwith clear KPIs for an agile transformation is therefore not a contradiction to the agile mindset, but a means of promoting it through clarity, determination, and transparency. Measuring the success of an agile transformation is no less important than measuring the success of the enterprise. 

If there are no such goals and metrics, an agile transformation threatens to quickly sink into satisfaction at a low level with a few improved outputs.

The app for scaled agile teams is here!

Click here, to show articles of the same topic:

Klaus Riedel
As an agile coach, Klaus Riedel, together with his team, supports the digital transformation and the introduction of Scrum and SAFe in large organizations such as Deutsche Bank, Conrad Electronics, Volkswagen, PWC and others.

All his gained practical experiences in more than 15 years of agile transformation have been incorporated into the articles of his blog.

In Scagile Academy he trains young Agile Experts and since 2016 he teaches agile project management at the German Faculty of TU Sofia.

More interesting articles for you: