Localisation 5 August 2026
Agile Localisation: Translation in the Sprint and Scrum Cycle
When software is developed the agile way, translation has to keep the same rhythm. We explain agile localisation, which moves in a sprint and Scrum cycle, and how it differs from the waterfall model.
An application is no longer dragged out for years and then released in one go; it is developed continuously, in small pieces. Once software is produced to that rhythm, translation has to keep the same beat. The approach born of this need is called agile localisation. Agile localisation runs translation not as one long stage but in short periods called sprints, interleaved with development.
Contents
This article looks at what agile localisation is, how it parts company with the classic waterfall model, how the sprint and Scrum cycle plays out in translation, and how it relates to continuous localisation. It also examines which projects the approach suits and which tools and roles it calls for.
What does agile localisation mean?
Agile localisation is agile software development carried over into translation. Agile methods are approaches in which solutions are developed iteratively and incrementally across self-organising, cross-functional teams. Applied to translation, this logic breaks localisation work into small, time-limited periods as well. In each period a set amount of content is translated quickly and folded into the product.
Underlying the approach is the logic of “push and pull”: version control systems record and manage the frequent changes made to code and content. Because development never stops, translation flows alongside it without a break. The work is no longer something that starts once and finishes once; it becomes a cycle that keeps repeating.
The agile approach is also a change of mindset. In classic translation, work begins once a complete source text has been handed over. In an agile setting the source text arrives piece by piece, before it has matured. This requires the linguist to be ready to work with incomplete context and to adapt to frequent changes. Flexibility is not a preference in this model; it is a necessity.
How it differs from the waterfall model
In the waterfall model the stages follow one another in order: project design, development, localisation preparation, translation, integration, testing. One stage does not begin until the one before it has finished. This arrangement is predictable but rigid. When a problem is found at the end of the process, the fix is both expensive and slow, because the developers may already have moved on to something else.
In the agile model, by contrast, the stages overlap. While one section is being translated another is being developed, and testing is going on alongside. This flexibility increases speed but makes coordination harder. Where the waterfall model reproduces the traditional translate-edit-publish flow, the agile model breaks that linear order. The chance of catching problems early goes up, because a fault can be seen at the moment it is created instead of being left to the end of the process. The table below compares the two models on the main axes.
| Criterion | Waterfall | Agile |
|---|---|---|
| Stages | Sequential | Overlapping |
| Delivery | All at once | Small pieces |
| Adapting to change | Hard | Easy |
| Best-suited content | Fixed documents | Frequently updated products |
The sprint and Scrum cycle
At the heart of agile localisation lie the concepts of the sprint and Scrum. A sprint is a working period of fixed length in which the team produces working software or an update. That period may be a week, a day or even a few hours. The translation has to be finished within the same set time. More often than not, that means a considerable amount of text to be translated in a short window.
This tempo changes translation work fundamentally. Where in the classic model the translator sees the whole text at once, in an agile flow the text arrives in small pieces, often cut off from its context. That calls both for quick thinking and for sound decisions made on incomplete information. When the sprint ends the work must have been delivered; a single outstanding piece can hold up a whole release.
A sprint cycle usually runs through the following steps:
- Developers produce new code and content within a short period.
- The content is sent to the repository and prepared for translation.
- The new text is distributed to the linguists and translated within the time available.
- The translation is integrated into the product and the release becomes ready to publish.
This cycle runs over and over. Each sprint adds a small layer on top of the last, and the product stays ready to be updated at any moment.
How it relates to continuous localisation
Agile and continuous localisation are often confused, but they are not the same thing. Continuous localisation is a subset of the agile approach; it rests on the principle of continuous integration and continuous delivery. In a continuous flow, the small code updates that are pushed out constantly are localised. The work never ends; it is made up of small updates that keep repeating.
The basic distinction is this: in the agile model a localisation process follows a period of development; in the continuous model updates are delivered without a break. You may also want to look at the article in which we compare the two approaches in more detail. The point we are underlining here is the sprint-based rhythm of agile localisation.
In practice the two concepts are often used side by side, and a sharp line is hard to draw. A team may adopt agile principles while also using continuous delivery tools. What matters is less the label than whether the way of working matches the rhythm of the product. Whether it is called agile or continuous, the shared aim is the same: to keep translation moving at the same pace as the product, without letting it fall behind development.
Balancing speed and quality
The greatest risk in an agile flow is that time pressure puts quality under strain. Text translated in short sprints can carry errors if it is not reviewed thoroughly enough. This is why translation memory, the termbase and automated quality checks become critical in agile localisation. These tools help to safeguard consistency and accuracy while the pace is kept up.
One way of protecting quality is to adopt the idea of “fit-for-purpose quality”. Not every piece of content is checked with the same rigour; critical sections can be handled more strictly and short-lived updates more loosely. Striking that balance is one of the most important tasks of the localisation manager in an agile setting.
Machine translation is playing an ever larger part in this balance too. In an agile flow, a machine translation suggestion can step in for segments with no match in the translation memory; human correction or automated quality evaluation then follows. The aim of this combination is to raise speed without handing quality over to the machine entirely. Even so, the last word goes to the person who can spot output that is fluent but wrong.
Which projects is it suitable for?
Agile localisation is not the right choice for every job. It is tailor-made for frequently updated applications, software and web content, because those products are already developed the agile way. For a user manual or a contract that is delivered once and rarely changes, on the other hand, the waterfall model is usually both adequate and cheaper.
Choosing the right model starts with understanding the nature of the content. How often does it change, how quickly does it have to be published, how many languages is it carried into? The answers to those questions settle the choice between agile and waterfall. The wrong model creates either needless complexity or a flow that jams.
The two models are sometimes used together even within a single project. The core interface of a piece of software may be prepared once on waterfall logic while the help content, which changes all the time, is updated through an agile flow. This mixed approach makes it possible to give each type of content its own rhythm. What matters is that the chosen model fits the way the team actually works; a model that looks ideal on paper can seize up in practice.
The technology and roles required
Agile localisation does not run on good intentions alone; it demands a particular technical infrastructure. Connectors that pull content out of repositories, translation management systems that notice updates and translation memories that hold consistency together are all parts of that infrastructure. Without these tools, managing by hand the small updates that recur at sprint tempo becomes all but impossible. Automation is indispensable to an agile flow.
The roles are shaped by the same tempo. The localisation manager runs a continuous flow rather than a one-off delivery. Linguists work in small, frequent packages; engineers keep the integration going; testers check each release quickly. How tightly these roles are bound to one another determines whether the agile flow succeeds. If the feedback loop breaks anywhere, the advantage of speed gives way to chaos.
The Türkiye context
Teams developing software and games in Türkiye are working with agile methods more and more. That in turn requires local translation providers to keep up with the sprint tempo. For a small agency it means building a flexible way of working that can handle regular small packages instead of large one-off deliveries. Having the termbase ready from the outset is the key to holding consistency at this pace.
The agglutinative structure of Turkish calls for extra care at sprint tempo. Text expansion in interface strings and the behaviour of placeholders are easily missed in fast translation. Giving the linguist context and screenshots, even in an agile flow, therefore reduces the corrections that surface later. Speed does not require context to be sacrificed.
What does this mean for you?
If your product is updated continuously, your translation provider has to be able to match that rhythm. To get the set-up right, you can do the following:
- Tell your provider how often your content is updated.
- Set up a plan of small, regular deliveries that fits the sprint tempo.
- Have the termbase and the style guide prepared from the outset.
We can help you set up a translation flow that suits the tempo of your project. You can look at our localisation services and get in touch with us about a regular workflow. Our aim is to protect your consistency without slowing you down.
Frequently asked questions
Are agile localisation and continuous localisation the same?
Close, but not the same. Agile localisation carries out translation in timeboxes called sprints. Continuous localisation is a subset of the agile approach and processes small updates without a break.
What does sprint mean?
A sprint is a working period of fixed length in which the team produces working software or an update. It may be a week, a day or even a few hours; the translation has to be finished within that time as well.
Does agile localisation lower quality?
Not of necessity, but time pressure raises the risk. This is why tools such as translation memory, the termbase and automated checks become critical for protecting quality in an agile flow.
Which projects suit agile localisation?
It suits frequently updated applications, software and web content. For documents that are delivered once and rarely change, the waterfall model is usually more than adequate.
Sources
Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge (Chs. 3/4/5/9/12). · Bernal-Merino, M. Á. (2015). Translation and Localisation in Video Games. Routledge.